idnits 2.17.1 draft-ietf-rtgwg-srv6-egress-protection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 28, 2020) is 1366 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CE1' is mentioned on line 265, but not defined == Unused Reference: 'RFC7356' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC8665' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.hegde-spring-node-protection-for-sr-te-paths' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 692, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-06 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-09 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft Huawei 4 Intended status: Standards Track H. Chen 5 Expires: January 29, 2021 Futurewei 6 H. Chen 7 China Telecom 8 P. Wu 9 Huawei 10 M. Toy 11 Verizon 12 C. Cao 13 T. He 14 China Unicom 15 L. Liu 16 Fujitsu 17 X. Liu 18 Volta Networks 19 July 28, 2020 21 SRv6 Path Egress Protection 22 draft-ietf-rtgwg-srv6-egress-protection-01 24 Abstract 26 This document describes protocol extensions for protecting the egress 27 node of a Segment Routing for IPv6 (SRv6) path or tunnel. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 29, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. SR Path Egress Protection . . . . . . . . . . . . . . . . . . 4 71 3.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Extensions to IGP for Egress Protection . . . . . . . . . . . 8 74 4.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 8 75 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The fast protection of a transit node of a Segment Routing (SR) path 89 or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 90 [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] 91 specifies the fast protection of egress node(s) of an MPLS TE LSP 92 tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. 93 However, these documents do not discuss the fast protection of the 94 egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. 96 This document fills that void and presents protocol extensions for 97 the fast protection of the egress node of an SRv6 path or tunnel. 98 Egress node and egress, fast protection and protection as well as 99 SRv6 path and SRv6 tunnel will be used exchangeably below. 101 There are a number of topics related to the egress protection, which 102 include the detection of egress node failure, the relation between 103 egress protection and global repair, and so on. These are discussed 104 in details in [RFC8679]. 106 2. Terminologies 108 The following terminologies are used in this document. 110 SR: Segment Routing 112 SRv6: SR for IPv6 114 SRH: Segment Routing Header 116 SID: Segment Identifier 118 LSA: Link State Advertisement in OSPF 120 LSP: Label Switched Path in MPLS or Link State Protocol PDU in IS-IS 122 PDU: Protocol Data Unit 124 LS: Link Sate, which is LSA in OSPF or LSP in IS-IS 126 TE: Traffic Engineering 128 SA: Source Address 130 DA: Destination Address 132 P2MP: Point-to-MultiPoint 134 P2P: Point-to-Point 136 CE: Customer Edge 138 PE: Provider Edge 140 LFA: Loop-Free Alternate 142 TI-LFA: Topology Independent LFA 143 BFD: Bidirectional Forwarding Detection 145 VPN: Virtual Private Network 147 L3VPN: Layer 3 VPN 149 VRF: Virtual Routing and Forwarding 151 FIB: Forwarding Information Base 153 PLR: Point of Local Repair 155 BGP: Border Gateway Protocol 157 IGP: Interior Gateway Protocol 159 OSPF: Open Shortest Path First 161 IS-IS: Intermediate System to Intermediate System 163 3. SR Path Egress Protection 165 This section describes the mechanism of SR path egress protection and 166 illustrates it through an example. 168 3.1. Mechanism 170 Figure 1 is used to explain the mechanism of SR path egress node 171 protection. 173 ******* ******* SIDa 174 [PE1]-----[P1]-----[PEA]---[CE2] PEA Egress 175 / | |& | \ / PEB Backup Egress 176 / | |& | \ / CEx Customer Edge 177 [CE1] | |& | X Px Non-Provider Edge 178 \ | |& | / \ *** SR Path 179 \ | |& &&&&& | / \ &&& Backup Path 180 [PE2]-----[P2]-----[PEB]---[CE3] 181 Mirror SID 183 Figure 1: PEB Protects Egress PEA of SR Path 185 Where node PEA is the egress of the SR path from PE1 to PEA, and has 186 SIDa which is the active segment in the packet from the SR path at 187 PEA. Node PEB is the backup egress (or say protector) to provide the 188 protection for egress (or say primary egress) PEA. Node P1 is the 189 direct previous hop of egress PEA and acts as PLR to support the 190 protection for PEA. 192 When PEB is selected as a backup egress to protect the egress PEA, a 193 Mirror SID (refer to Section 5.1 of [RFC8402]) is configured on PEB 194 to protect PEA. PEB advertises this information through IGP, which 195 includes the Mirror SID and the egress PEA. The information is 196 represented by , which indicates that PEB 197 protects PEA with Mirror SID. 199 After PEA receives the information , it may 200 send the forwarding behavior of the SIDa at PEA to PEB with the 201 Mirror SID using some protocols such as BGP if PEB can not obtain 202 this behavior from other approaches if PEB wants to protect SIDa of 203 PEA. How to send the forwarding behavior of the SIDa to PEB is out 204 scope of this document. 206 When PEB gets the forwarding behavior of the SIDa of PEA from PEA or 207 other means, it adds a forwarding entry for the SIDa according to the 208 behavior into the forwarding table for node PEA. This table is 209 identified by the Mirror SID, which indicates node PEA's context. 210 Using the forwarding entry for SIDa in this table, a packet with SIDa 211 will be transmitted by PEB to the same destination as it is 212 transmitted by PEA. For example, assume that the packet with SIDa is 213 transmitted by PEA to CE2 through the forwarding behavior of the SIDa 214 in PEA. The packet will be transmitted by PEB to the same CE2 215 through looking up the table identified by the Mirror SID. 217 After P1 as PLR receives the information and 218 knows that PEB wants to protect SIDa of PEA, it computes a shortest 219 path to PEB. A Repair List RL is obtained based on the path. It is 220 one of the followings: 222 o RL = if the path does not go through PEA; or 224 o RL = if the path goes through PEA, where 225 is the TI-LFA Repair List to PEB computed by P1. 227 When PEA fails, P1 as PLR sends the packet with SIDa carried by the 228 SR path to PEB, but encapsulates the packet before sending it by 229 executing H.Encaps with the Repair List RL and a Source Address T. 231 Suppose that the packet received by P1 is represented by Pkt = (S, 232 SIDa)Pkt0, where SA = S and DA = SIDa, and Pkt0 is the rest of the 233 packet. 235 The execution of H.Encaps pushes an IPv6 header to Pkt and sets some 236 fields in the outer and inner IPv6 header to produce an encapsulated 237 packet Pkt'. Pkt' will be one of the followings: 239 o Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL = ; or 240 o Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL 241 = . 243 When PEB receives the re-routed packet, which is (T, Mirror SID) (S, 244 SIDa)Pkt0, it decapsulates the packet and forwards the decapsulated 245 packet using the forwarding table identified by Mirror SID through 246 executing End.DT6. 248 It obtains the Mirror SID in the outer IPv6 header of the packet, 249 removes this outer IPv6 header with all its extension headers, and 250 then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet 251 without the outer IPv6 header). PEB finds the forwarding table for 252 node PEA using the Mirror SID as the context ID, and submits the 253 packet to this forwarding table lookup and transmission to the same 254 destination as PEA does. 256 3.2. Example 258 Figure 2 shows an example of protecting egress PE3 of a SR path, 259 which is from ingress PE1 to egress PE3. 261 ******* ******* VPN SID: A3:1::B100 262 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 263 / | |& | \ / PE4 Backup Egress 264 / | |& | \ / CEx Customer Edge 265 [CE1] | |& | X Px Non-Provider Edge 266 \ | |& | / \ *** SR Path 267 \ | |& &&&&& | / \ &&& Backup Path 268 [PE2]-----[P2]-----[PE4]---[CE3] 269 VPN SID: A4:1::B100 270 Mirror SID: A4:1::3, protect PE3 272 Figure 2: PE4 Protects Egress PE3 of SR Path 274 Where node P1's pre-computed backup path for PE3 is from P1 to PE4 275 via P2. In normal operations, after receiving a packet with 276 destination PE3, P1 forwards the packet to PE3 according to its FIB. 277 When PE3 receives the packet, it sends the packet to CE2. 279 When PE3 fails, P1 as PLR detects the failure through using a failure 280 detection mechanism such as BFD and forwards the packet to PE4 via 281 the backup path. When PE4 receives the packet, it sends the packet 282 to the same CE2. 284 In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has 285 a VPN SID A3:1::B100. PE4 has a VPN SID A4:1::B100. A Mirror SID 286 A4:1::3 is configured on PE4 for protecting PE3. 288 After the configuration, PE4 advertises this information through an 289 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE4's ID, 290 PE3's ID and Mirror SID A4:1::3. Every node in the SR domain will 291 receive this IGP LS, which indicates that PE4 wants to protect PE3 292 with Mirror SID A4:1::3. 294 When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs 295 to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds 296 PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 297 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 298 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are 299 for the same VPN. 301 The forwarding behaviors for these two VPN SIDs are the same from 302 function's point of view. If the behavior for PE3's VPN SID in PE3 303 forwards the packet with it to CE2, then the behavior for PE4's VPN 304 SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 305 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the table 306 (or FIB) identified by Mirror SID A4:1::3 according to the forwarding 307 behavior for PE4's VPN SID A4:1::B100. 309 Node P1's pre-computed backup path for destination PE3 is from P1 to 310 PE4 having mirror SID A4:1::3. When P1 receives a packet destined to 311 PE3's VPN SID A3:1::B100, in normal operations, it forwards the 312 packet with source A1:1:: and destination PE3's VPN SID A3:1::B100 313 according to the FIB using the destination PE3's VPN SID A3:1::B100. 315 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 316 pre-computed. P1 encapsulates the packet using H.Encaps before 317 sending it to PE4. 319 Suppose that the packet received by P1 is represented by Pkt = (SA = 320 A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, 321 and Pkt0 is the rest of the packet. The encapsulated packet Pkt' 322 will be one of the followings: 324 o Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup 325 path not via PE3; or (otherwise) 327 o Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, 328 A3:1::B100)Pkt0. 330 where T is a Source Address, is the TI-LFA Repair List 331 to PE4 computed by P1 when the backup path to PE4 goes through PE3. 333 When PE4 receives the re-routed packet, it decapsulates the packet 334 and forwards the decapsulated packet by End.DT6. The packet received 335 by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 336 A3:1::B100)Pkt0. 338 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 339 packet, removes this outer IPv6 header, and then processes the inner 340 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the forwarding table 341 for PE3 using Mirror SID A4:1::3 as the context ID, gets the 342 forwarding entry for PE3's VPN SID A3:1::B100 from the table, and 343 forwards the packet to CE2 using the entry. 345 4. Extensions to IGP for Egress Protection 347 This section describes extensions to IS-IS and OSPF for advertising 348 the information about SRv6 path egress protection. 350 4.1. Extensions to IS-IS 352 A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It 353 is used in the SRv6 Locator TLV defined in 354 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and 355 the ID of the node to be protected. The SRv6 Mirror SID inherit the 356 topology/algorithm from the parent locator. The format of the sub- 357 TLV is illustrated below. 359 0 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type (TBD1) | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | SID (16 octets) | 365 : : 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | sub-TLVs | 369 : : 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 3: IS-IS SRv6 Mirror SID sub-TLV 374 Type: TBD1 (suggested value 8) is to be assigned by IANA. 376 Length: variable. 378 SID: 16 octets. This field contains the SRv6 Mirror SID to be 379 advertised. 381 Two sub-TLVs are defined. One is the protected node sub-TLV, and the 382 other is the protected SIDs sub-TLV. 384 A protected node sub-TLV is used to carry the ID of the node to be 385 protected by the SRv6 Mirror SID. It has the following format. 387 0 1 2 3 388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type (TBD2) | Length | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 392 | Node-ID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 4: IS-IS Protected Node sub-TLV 397 Type: TBD2 (suggested value 1) is to be assigned by IANA. 399 Length: 1 octet. Its value is 6. 401 Node-ID: 6 octets. It contains a 6-octet ISO Node-ID (ISO system- 402 ID). 404 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 405 the SRv6 Mirror SID. It has the following format. 407 0 1 2 3 408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type (TBD3) | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SID (16 octets) ~ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 : : 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | SID (16 octets) ~ 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: IS-IS Protected SIDs sub-TLV 421 Type: TBD3 (suggested value 2) is to be assigned by IANA. 423 Length: variable. 425 SID: 16 octets. This field encodes an SRv6 SID to be protected. 427 When node B advertises that B wants to protect node A with a Mirror 428 SID through an LSP, the LSP contains an IS-IS SRv6 Mirror SID sub- 429 TLV, which includes the Mirror SID and the node A's ID in an IS-IS 430 Protected Node sub-TLV. If B wants to protect just a specific set of 431 SIDs of node A, the Mirror SID sub-TLV includes these SIDs in an IS- 432 IS Protected SIDs sub-TLV; otherwise (i.e., B wants to protect all 433 the SIDs of A) it does not contain any IS-IS Protected SIDs sub-TLV. 435 Note: the IS-IS extensions for SR MPLS is described in [RFC8667]. It 436 says that the SID/Label Binding TLV may also be used to advertise a 437 Mirror SID. For B to protect egress A of SR MPLS path, B may also 438 use this TLV to advertise the node A's ID and a specific set of SIDs 439 of A to be protected. An IS-IS SR MPLS Mirror SID sub-TLV may be 440 obtained from an IS-IS SRv6 Mirror SID sub-TLV by replacing each SID 441 field in the latter with an SID/Label sub-TLV. B may advertise a 442 SID/Label Binding TLV including this IS-IS SR MPLS Mirror SID sub- 443 TLV. 445 Alternatively, an IS-IS SR MPLS Mirror Supplement sub-TLV is defined 446 from an IS-IS SRv6 Mirror SID sub-TLV by removing the SID field in 447 the top level and replacing each other SID field with an SID/Label 448 sub-TLV. That is that an IS-IS SR MPLS Mirror Supplement sub-TLV 449 just contains a Protected Node sub-TLV and a Protected SIDs sub-TLV, 450 which includes SID/Label sub-TLVs. When the SID/Label Binding TLV 451 contains an SID/Label sub-TLV for the Mirror SID, it includes an IS- 452 IS SR MPLS Mirror Supplement sub-TLV. 454 4.2. Extensions to OSPF 456 Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. 457 It is used to advertise SRv6 Mirror SID and the ID of the node to be 458 protected. Its format is illustrated below. 460 0 1 2 3 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type (TBD4) | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | SID (16 octets) | 466 : : 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | sub-TLVs | 470 : : 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 6: OSPF SRv6 Mirror SID sub-TLV 475 Type: TBD4 (suggested value 8) is to be assigned by IANA. 477 Length: variable. 479 SID: 16 octets. This field contains the SRv6 Mirror SID to be 480 advertised. 482 Two sub-TLVs are defined. One is the protected node sub-TLV, and the 483 other is the protected SIDs sub-TLV. 485 A protected node sub-TLV is used to carry the ID of the node to be 486 protected by the SRv6 Mirror SID. It has the following format. 488 0 1 2 3 489 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type (TBD5) | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Node-ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Figure 7: OSPF Protected Node sub-TLV 498 Type: TBD5 (suggested value 1) is to be assigned by IANA. 500 Length: 2 octets. Its value is 4. 502 Node-ID: 4 octets. It contains the ID of the OSPF node or router to 503 be protected. 505 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 506 the SRv6 Mirror SID. It has the following format. 508 0 1 2 3 509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type (TBD6) | Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | SID (16 octets) ~ 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 : : 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | SID (16 octets) ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 8: OSPF Protected SIDs sub-TLV 522 Type: TBD6 (suggested value 2) is to be assigned by IANA. 524 Length: variable. 526 SID: 16 octets. This field encodes an SRv6 SID to be protected. 528 5. Security Considerations 530 The security about the egress protection is described in in details 531 in [RFC8679]. The extensions to OSPF and IS-IS described in this 532 document for SRv6 path egress protection should not cause extra 533 security issues. 535 6. IANA Considerations 537 6.1. IS-IS 539 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 540 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 541 following new Sub-TLV: 543 +==============+=========================+===============+ 544 | Sub-TLV Type | Sub-TLV Name | Reference | 545 +==============+=========================+===============+ 546 | 8 | SRv6 Mirror SID Sub-TLV | This document | 547 +--------------+-------------------------+---------------+ 549 IANA is requested to create and maintain a new registry for sub-sub- 550 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 552 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 554 Initial values for the registry are given below. The future 555 assignments are to be made through IETF Review [RFC5226]. 557 Value Sub-Sub-TLV Name Definition 558 ----- ----------------------- ------------- 559 0 Reserved 560 1 Protected Node Sub-Sub-TLV This Document 561 2 Protected SIDs Sub-Sub-TLV 562 3-255 Unassigned 564 6.2. OSPFv3 566 Under registry "OSPFv3 Locator LSA Sub-TLVs" 567 [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the 568 following new Sub-TLV: 570 +==============+=========================+===============+ 571 | Sub-TLV Type | Sub-TLV Name | Reference | 572 +==============+=========================+===============+ 573 | 8 | SRv6 Mirror SID Sub-TLV | This document | 574 +--------------+-------------------------+---------------+ 576 IANA is requested to create and maintain a new registry for sub-sub- 577 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 579 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 581 Initial values for the registry are given below. The future 582 assignments are to be made through IETF Review [RFC5226]. 584 Value Sub-Sub-TLV Name Definition 585 ----- ----------------------- ------------- 586 0 Reserved 587 1 Protected Node Sub-Sub-TLV This Document 588 2 Protected SIDs Sub-Sub-TLV 589 3-65535 Unassigned 591 7. Acknowledgements 593 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 594 Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene and Jeff 595 Tantsura for their comments to this work. 597 8. References 599 8.1. Normative References 601 [I-D.ietf-lsr-isis-srv6-extensions] 602 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 603 Z. Hu, "IS-IS Extension to Support Segment Routing over 604 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 605 (work in progress), April 2020. 607 [I-D.li-ospf-ospfv3-srv6-extensions] 608 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 609 "OSPFv3 Extensions for SRv6", draft-li-ospf- 610 ospfv3-srv6-extensions-07 (work in progress), November 611 2019. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 619 Scope Link State PDUs (LSPs)", RFC 7356, 620 DOI 10.17487/RFC7356, September 2014, 621 . 623 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 624 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 625 RFC 7490, DOI 10.17487/RFC7490, April 2015, 626 . 628 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 629 "Extensions to RSVP-TE for Label Switched Path (LSP) 630 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 631 2018, . 633 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 634 Decraene, B., Litkowski, S., and R. Shakir, "Segment 635 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 636 July 2018, . 638 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 639 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 640 Extensions for Segment Routing", RFC 8665, 641 DOI 10.17487/RFC8665, December 2019, 642 . 644 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 645 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 646 Extensions for Segment Routing", RFC 8667, 647 DOI 10.17487/RFC8667, December 2019, 648 . 650 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 651 Michel, C., and H. Chen, "MPLS Egress Protection 652 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 653 . 655 8.2. Informative References 657 [I-D.hegde-spring-node-protection-for-sr-te-paths] 658 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 659 "Node Protection for SR-TE Paths", draft-hegde-spring- 660 node-protection-for-sr-te-paths-06 (work in progress), 661 July 2020. 663 [I-D.hu-spring-segment-routing-proxy-forwarding] 664 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 665 Path Midpoint Protection", draft-hu-spring-segment- 666 routing-proxy-forwarding-09 (work in progress), July 2020. 668 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 669 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 670 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 671 "Topology Independent Fast Reroute using Segment Routing", 672 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 673 progress), March 2020. 675 [I-D.ietf-spring-segment-routing-policy] 676 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 677 P. Mattes, "Segment Routing Policy Architecture", draft- 678 ietf-spring-segment-routing-policy-08 (work in progress), 679 July 2020. 681 [I-D.sivabalan-pce-binding-label-sid] 682 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 683 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 684 in PCE-based Networks.", draft-sivabalan-pce-binding- 685 label-sid-07 (work in progress), July 2019. 687 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 688 IANA Considerations Section in RFCs", RFC 5226, 689 DOI 10.17487/RFC5226, May 2008, 690 . 692 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 693 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 694 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 695 2009, . 697 Authors' Addresses 699 Zhibo Hu 700 Huawei 701 Huawei Bld., No.156 Beiqing Rd. 702 Beijing 100095 703 China 705 Email: huzhibo@huawei.com 707 Huaimo Chen 708 Futurewei 709 Boston, MA 710 USA 712 Email: Huaimo.chen@futurewei.com 713 Huanan Chen 714 China Telecom 715 109, West Zhongshan Road, Tianhe District 716 Guangzhou 510000 717 China 719 Email: chenhuan6@chinatelecom.cn 721 Peng Wu 722 Huawei 723 Huawei Bld., No.156 Beiqing Rd. 724 Beijing 100095 725 China 727 Email: baggio.wupeng@huawei.com 729 Mehmet Toy 730 Verizon 731 USA 733 Email: mehmet.toy@verizon.com 735 Chang Cao 736 China Unicom 737 Beijing China 739 Email: caoc15@chinaunicom.cn 741 Tao He 742 China Unicom 743 Beijing China 745 Email: het21@chinaunicom.cn 747 Lei Liu 748 Fujitsu 749 USA 751 Email: liulei.kddi@gmail.com 752 Xufeng Liu 753 Volta Networks 754 McLean, VA 755 USA 757 Email: xufeng.liu.ietf@gmail.com