idnits 2.17.1 draft-ietf-rtgwg-srv6-egress-protection-03.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 date (May 28, 2021) is 1063 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 268, but not defined == Unused Reference: 'RFC7356' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC8665' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC8667' is defined on line 694, 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 707, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 742, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-14 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-14 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 16 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: November 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 May 28, 2021 21 SRv6 Path Egress Protection 22 draft-ietf-rtgwg-srv6-egress-protection-03 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 November 29, 2021. 51 Copyright Notice 53 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 13 79 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 8.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The fast protection of a transit node of a Segment Routing (SR) path 90 or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 91 [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] 92 specifies the fast protection of egress node(s) of an MPLS TE LSP 93 tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. 94 However, these documents do not discuss the fast protection of the 95 egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. 97 This document fills that void and presents protocol extensions for 98 the fast protection of the egress node of an SRv6 path or tunnel. 99 Egress node and egress, fast protection and protection as well as 100 SRv6 path and SRv6 tunnel will be used exchangeably below. 102 There are a number of topics related to the egress protection, which 103 include the detection of egress node failure, the relation between 104 egress protection and global repair, and so on. These are discussed 105 in details in [RFC8679]. 107 2. Terminologies 109 The following terminologies are used in this document. 111 SR: Segment Routing 113 SRv6: SR for IPv6 115 SRH: Segment Routing Header 117 SID: Segment Identifier 119 LSA: Link State Advertisement in OSPF 121 LSP: Label Switched Path in MPLS or Link State Protocol PDU in IS-IS 123 PDU: Protocol Data Unit 125 LS: Link Sate, which is LSA in OSPF or LSP in IS-IS 127 TE: Traffic Engineering 129 SA: Source Address 131 DA: Destination Address 133 P2MP: Point-to-MultiPoint 135 P2P: Point-to-Point 137 CE: Customer Edge 139 PE: Provider Edge 141 LFA: Loop-Free Alternate 143 TI-LFA: Topology Independent LFA 144 BFD: Bidirectional Forwarding Detection 146 VPN: Virtual Private Network 148 L3VPN: Layer 3 VPN 150 VRF: Virtual Routing and Forwarding 152 FIB: Forwarding Information Base 154 PLR: Point of Local Repair 156 BGP: Border Gateway Protocol 158 IGP: Interior Gateway Protocol 160 OSPF: Open Shortest Path First 162 IS-IS: Intermediate System to Intermediate System 164 3. SR Path Egress Protection 166 This section describes the mechanism of SR path egress protection and 167 illustrates it through an example. 169 3.1. Mechanism 171 Figure 1 is used to explain the mechanism of SR path egress node 172 protection. 174 ******* ******* SIDa 175 [PE1]-----[P1]-----[PEA]---[CE2] PEA Egress 176 / | |& | \ / PEB Backup Egress 177 / | |& | \ / CEx Customer Edge 178 [CE1] | |& | X Px Non-Provider Edge 179 \ | |& | / \ *** SR Path 180 \ | |& &&&&& | / \ &&& Backup Path 181 [PE2]-----[P2]-----[PEB]---[CE3] 182 Mirror SID 184 Figure 1: PEB Protects Egress PEA of SR Path 186 Where node PEA is the egress of the SR path from PE1 to PEA, and has 187 SIDa which is the active segment in the packet from the SR path at 188 PEA. Node PEB is the backup egress (or say protector) to provide the 189 protection for egress (or say primary egress) PEA. Node P1 is the 190 direct previous hop of egress PEA and acts as PLR to support the 191 protection for PEA. 193 When PEB is selected as a backup egress to protect the egress PEA, a 194 Mirror SID (refer to Section 5.1 of [RFC8402]) is configured on PEB 195 to protect PEA. PEB advertises this information through IGP, which 196 includes the Mirror SID and the egress PEA. The information is 197 represented by , which indicates that PEB 198 protects PEA with Mirror SID. 200 After PEA receives the information , it may 201 send the forwarding behavior of the SIDa at PEA to PEB with the 202 Mirror SID using some protocols such as BGP if PEB can not obtain 203 this behavior from other approaches if PEB wants to protect SIDa of 204 PEA. How to send the forwarding behavior of the SIDa to PEB is out 205 scope of this document. 207 When PEB gets the forwarding behavior of the SIDa of PEA from PEA or 208 other means, it adds a forwarding entry for the SIDa according to the 209 behavior into the forwarding table for node PEA. This table is 210 identified by the Mirror SID, which indicates node PEA's context. 211 Using the forwarding entry for SIDa in this table, a packet with SIDa 212 will be transmitted by PEB to the same destination as it is 213 transmitted by PEA. For example, assume that the packet with SIDa is 214 transmitted by PEA to CE2 through the forwarding behavior of the SIDa 215 in PEA. The packet will be transmitted by PEB to the same CE2 216 through looking up the table identified by the Mirror SID. 218 After P1 as PLR receives the information and 219 knows that PEB wants to protect SIDa of PEA, it computes a shortest 220 path to PEB. A Repair List RL is obtained based on the path. It is 221 one of the followings: 223 o RL = if the path does not go through PEA; or 225 o RL = if the path goes through PEA, where 226 is the TI-LFA Repair List to PEB computed by P1. 228 When PEA fails, P1 as PLR sends the packet with SIDa carried by the 229 SR path to PEB, but encapsulates the packet before sending it by 230 executing H.Encaps with the Repair List RL and a Source Address T. 232 Suppose that the packet received by P1 is represented by Pkt = (S, 233 SIDa)Pkt0, where SA = S and DA = SIDa, and Pkt0 is the rest of the 234 packet. 236 The execution of H.Encaps pushes an IPv6 header to Pkt and sets some 237 fields in the outer and inner IPv6 header to produce an encapsulated 238 packet Pkt'. Pkt' will be one of the followings: 240 o Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL = ; or 241 o Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL 242 = . 244 When PEB receives the re-routed packet, which is (T, Mirror SID) (S, 245 SIDa)Pkt0, it decapsulates the packet and forwards the decapsulated 246 packet using the FIB table identified by the Mirror SID as an End.DT6 247 SID instance through executing End.DT6. The Mirror SID is called 248 End.M. 250 It obtains the Mirror SID in the outer IPv6 header of the packet, 251 removes this outer IPv6 header with all its extension headers, and 252 then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet 253 without the outer IPv6 header). PEB finds the FIB table for node PEA 254 using the Mirror SID as the context ID, and submits the packet to 255 this FIB table lookup and transmission to the same destination as PEA 256 does. 258 3.2. Example 260 Figure 2 shows an example of protecting egress PE3 of a SR path, 261 which is from ingress PE1 to egress PE3. 263 Locator: A3:1::/64 264 ******* ******* VPN SID: A3:1::B100 265 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 266 / | |& | \ / PE4 Backup Egress 267 / | |& | \ / CEx Customer Edge 268 [CE1] | |& | X Px Non-Provider Edge 269 \ | |& | / \ *** SR Path 270 \ | |& &&&&& | / \ &&& Backup Path 271 [PE2]-----[P2]-----[PE4]---[CE3] 272 Locator: A4:1::/64 273 VPN SID: A4:1::B100 274 Mirror SID: A4:1::3, protect A3:1::/64 276 Figure 2: PE4 Protects Egress PE3 of SR Path 278 Where node P1's pre-computed backup path for PE3 is from P1 to PE4 279 via P2. In normal operations, after receiving a packet with 280 destination PE3, P1 forwards the packet to PE3 according to its FIB. 281 When PE3 receives the packet, it sends the packet to CE2. 283 When PE3 fails, P1 as PLR detects the failure through using a failure 284 detection mechanism such as BFD and forwards the packet to PE4 via 285 the backup path. When PE4 receives the packet, it sends the packet 286 to the same CE2. 288 In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has 289 a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator 290 A4:1::/64 and VPN SID A4:1::B100. A Mirror SID A4:1::3 is configured 291 on PE4 for protecting PE3 with locator A3:1::/64. 293 After the configuration, PE4 advertises this information through an 294 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's 295 locator and Mirror SID A4:1::3. Every node in the SR domain will 296 receive this IGP LS, which indicates that PE4 wants to protect PE3's 297 locator with Mirror SID A4:1::3. 299 When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs 300 to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds 301 PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 302 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 303 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are 304 for the same VPN. 306 The forwarding behaviors for these two VPN SIDs are the same from 307 function's point of view. If the behavior for PE3's VPN SID in PE3 308 forwards the packet with it to CE2, then the behavior for PE4's VPN 309 SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 310 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB 311 table identified by Mirror SID A4:1::3 according to the forwarding 312 behavior for PE4's VPN SID A4:1::B100. 314 Node P1's pre-computed backup path for destination PE3`s locator is 315 from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet 316 destined to PE3's VPN SID A3:1::B100, in normal operations, it 317 forwards the packet with source A1:1:: and destination PE3's VPN SID 318 A3:1::B100 according to the FIB using the destination PE3's VPN SID 319 A3:1::B100. 321 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 322 pre-computed. P1 encapsulates the packet using H.Encaps before 323 sending it to PE4. 325 Suppose that the packet received by P1 is represented by Pkt = (SA = 326 A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, 327 and Pkt0 is the rest of the packet. The encapsulated packet Pkt' 328 will be one of the followings: 330 o Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup 331 path not via PE3; or (otherwise) 333 o Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, 334 A3:1::B100)Pkt0. 336 where T is a Source Address, is the TI-LFA Repair List 337 to PE4 computed by P1 when the backup path to PE4 goes through PE3. 339 When PE4 receives the re-routed packet, it decapsulates the packet 340 and forwards the decapsulated packet by executing End.DT6 behavior 341 for an End.DT6 SID instance. The SID instance is End.M, the Mirror 342 SID that is associated with the IPv6 FIB table for PE3. The packet 343 received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 344 A3:1::B100)Pkt0. 346 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 347 packet, removes this outer IPv6 header, and then processes the inner 348 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 349 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry 350 for PE3's VPN SID A3:1::B100 from the table, and forwards the packet 351 to CE2 using the entry. 353 4. Extensions to IGP for Egress Protection 355 This section describes extensions to IS-IS and OSPF for advertising 356 the information about SRv6 path egress protection. 358 4.1. Extensions to IS-IS 360 A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It 361 is used in the SRv6 Locator TLV defined in 362 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and 363 the locators of the node to be protected. The SRv6 Mirror SID 364 inherit the topology/algorithm from the parent locator. The format 365 of the sub-TLV is illustrated below. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type (TBD1) | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Flags | SRv6 Endpoint Function | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | SID (16 octets) | 375 : : 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | sub-TLVs | 379 : : 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 3: IS-IS SRv6 Mirror SID sub-TLV 384 Type: TBD1 (suggested value 8) is to be assigned by IANA. 386 Length: variable. 388 Flags: 1 octet. No flags are currently defined. 390 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 391 74 for Mirror SID. 393 SID: 16 octets. This field contains the SRv6 Mirror SID to be 394 advertised. 396 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 397 the other is the protected SIDs sub-TLV. 399 A protected locators sub-TLV is used to carry the Locators to be 400 protected by the SRv6 mirror SID. It has the following format. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type (TBD2) | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Locator-Size | Locator (variable) ~ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 : : 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Locator-Size | Locator (variable) ~ 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 4: IS-IS Protected Locators sub-TLV 416 Type: TBD2 (suggested value 1) is to be assigned by IANA. 418 Length: variable. 420 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 421 field. 423 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 424 protected by the SRv6 mirror SID. The Locator is encoded in the 425 minimal number of octets for the given number of bits. 427 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 428 the SRv6 Mirror SID. It has the following format. 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type (TBD3) | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | SID-Size | SID (variable) ~ 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 : : 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | SID-Size | SID (variable) ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 5: IS-IS Protected SIDs sub-TLV 444 Type: TBD3 (suggested value 2) is to be assigned by IANA. 446 Length: variable. 448 SID-Size: 1 octet. Number of bits in the SID field. It is from 1 449 to 128. When it is less than 128, the SID field is a locator. 450 When it is 128, the SID field is an SRv6 SID. 452 SID: 1-16 octets. This field encodes an SRv6 SID or locator to be 453 protected. The SID/locator is encoded in the minimal number of 454 octets for the given number of bits. Trailing bits MUST be set to 455 zero and ignored when received. 457 When node B advertises that B wants to protect node A's locators with 458 a Mirror SID through an LSP, the LSP contains an IS-IS SRv6 Mirror 459 SID sub-TLV, which includes the Mirror SID and the node A's locators 460 in an IS-IS Protected locators sub-TLV. If B wants to protect just a 461 specific set of SIDs of node A, the Mirror SID sub-TLV includes these 462 SIDs in an IS-IS Protected SIDs sub-TLV. 464 4.2. Extensions to OSPF 466 Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. 467 It is used to advertise SRv6 Mirror SID and the locators of the node 468 to be protected. Its format is illustrated below. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type (TBD4) | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Flags | SRv6 Endpoint Function | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | SID (16 octets) | 478 : : 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | sub-TLVs | 482 : : 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 6: OSPF SRv6 Mirror SID sub-TLV 487 Type: TBD4 (suggested value 8) is to be assigned by IANA. 489 Length: variable. 491 Flags: 1 octet. No flags are currently defined. 493 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 494 74 for End.M SID. 496 SID: 16 octets. This field contains the SRv6 Mirror SID to be 497 advertised. 499 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 500 the other is the protected SIDs sub-TLV. 502 A protected locators sub-TLV is used to carry the locators of the 503 node to be protected by the SRv6 Mirror SID. It has the following 504 format. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type (TBD5) | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Locator-Size | Locator (variable) ~ 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 : : 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Locator-Size | Locator (variable) ~ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 7: OSPF Protected Locators sub-TLV 520 Type: TBD5 (suggested value 1) is to be assigned by IANA. 522 Length: variable. 524 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 525 field. 527 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 528 protected by the SRv6 mirror SID. The Locator is encoded in the 529 minimal number of octets for the given number of bits. 531 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 532 the SRv6 Mirror SID. It has the following format. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type (TBD6) | Length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | SID-Size | SID (variable) ~ 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 : : 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | SID-Size | SID (variable) ~ 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 8: OSPF Protected SIDs sub-TLV 548 Type: TBD6 (suggested value 2) is to be assigned by IANA. 550 Length: variable. 552 SID-Size: 1 octet. Number of bits in the SID field. It is from 1 553 to 128. When it is less than 128, the SID field is a locator. 554 When it is 128, the SID field is an SRv6 SID. 556 SID: 1-16 octets. This field encodes an SRv6 SID or locator to be 557 protected. The SID/locator is encoded in the minimal number of 558 octets for the given number of bits. Trailing bits MUST be set to 559 zero and ignored when received. 561 5. Security Considerations 563 The security about the egress protection is described in in details 564 in [RFC8679]. The extensions to OSPF and IS-IS described in this 565 document for SRv6 path egress protection should not cause extra 566 security issues. 568 6. IANA Considerations 570 6.1. SRv6 Endpoint Behaviors 572 Under sub-registry "SRv6 Endpoint Behaviors", 573 [I-D.ietf-spring-srv6-network-programming], IANA is requested to 574 assign the following Mirror SID as an End.DT6 SID instance: 576 +==============+========+=====================+===============+ 577 | Value | Hex | Endpoint behavior | Reference | 578 +==============+========+=====================+===============+ 579 | 74(suggested)| 0x004A | End.M (Mirror SID) | This document | 580 +--------------+--------+---------------------+---------------+ 582 6.2. IS-IS 584 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 585 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 586 following new Sub-TLV: 588 +==============+=========================+===============+ 589 | Sub-TLV Type | Sub-TLV Name | Reference | 590 +==============+=========================+===============+ 591 | 8 | SRv6 Mirror SID Sub-TLV | This document | 592 +--------------+-------------------------+---------------+ 594 IANA is requested to create and maintain a new registry for sub-sub- 595 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 597 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 599 Initial values for the registry are given below. The future 600 assignments are to be made through IETF Review [RFC5226]. 602 Value Sub-Sub-TLV Name Definition 603 ----- ----------------------- ------------- 604 0 Reserved 605 1 Protected Locators Sub-Sub-TLV This Document 606 2 Protected SIDs Sub-Sub-TLV 607 3-255 Unassigned 609 6.3. OSPFv3 611 Under registry "OSPFv3 Locator LSA Sub-TLVs" 612 [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the 613 following new Sub-TLV: 615 +==============+=========================+===============+ 616 | Sub-TLV Type | Sub-TLV Name | Reference | 617 +==============+=========================+===============+ 618 | 8 | SRv6 Mirror SID Sub-TLV | This document | 619 +--------------+-------------------------+---------------+ 621 IANA is requested to create and maintain a new registry for sub-sub- 622 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 624 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 626 Initial values for the registry are given below. The future 627 assignments are to be made through IETF Review [RFC5226]. 629 Value Sub-Sub-TLV Name Definition 630 ----- ----------------------- ------------- 631 0 Reserved 632 1 Protected Locators Sub-Sub-TLV This Document 633 2 Protected SIDs Sub-Sub-TLV 634 3-65535 Unassigned 636 7. Acknowledgements 638 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 639 Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura, 640 Chris Bowers and Ketan Talaulikar for their comments to this work. 642 8. References 643 8.1. Normative References 645 [I-D.ietf-lsr-isis-srv6-extensions] 646 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 647 Z. Hu, "IS-IS Extension to Support Segment Routing over 648 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-14 649 (work in progress), April 2021. 651 [I-D.ietf-spring-srv6-network-programming] 652 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 653 Matsushima, S., and Z. Li, "Segment Routing over IPv6 654 (SRv6) Network Programming", draft-ietf-spring-srv6- 655 network-programming-28 (work in progress), December 2020. 657 [I-D.li-ospf-ospfv3-srv6-extensions] 658 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 659 "OSPFv3 Extensions for SRv6", draft-li-ospf- 660 ospfv3-srv6-extensions-07 (work in progress), November 661 2019. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 669 Scope Link State PDUs (LSPs)", RFC 7356, 670 DOI 10.17487/RFC7356, September 2014, 671 . 673 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 674 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 675 RFC 7490, DOI 10.17487/RFC7490, April 2015, 676 . 678 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 679 "Extensions to RSVP-TE for Label Switched Path (LSP) 680 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 681 2018, . 683 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 684 Decraene, B., Litkowski, S., and R. Shakir, "Segment 685 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 686 July 2018, . 688 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 689 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 690 Extensions for Segment Routing", RFC 8665, 691 DOI 10.17487/RFC8665, December 2019, 692 . 694 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 695 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 696 Extensions for Segment Routing", RFC 8667, 697 DOI 10.17487/RFC8667, December 2019, 698 . 700 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 701 Michel, C., and H. Chen, "MPLS Egress Protection 702 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 703 . 705 8.2. Informative References 707 [I-D.hegde-spring-node-protection-for-sr-te-paths] 708 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 709 "Node Protection for SR-TE Paths", draft-hegde-spring- 710 node-protection-for-sr-te-paths-07 (work in progress), 711 July 2020. 713 [I-D.hu-spring-segment-routing-proxy-forwarding] 714 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 715 Yisong, "SR-TE Path Midpoint Restoration", draft-hu- 716 spring-segment-routing-proxy-forwarding-14 (work in 717 progress), April 2021. 719 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 720 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 721 Decraene, B., and D. Voyer, "Topology Independent Fast 722 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 723 routing-ti-lfa-06 (work in progress), February 2021. 725 [I-D.ietf-spring-segment-routing-policy] 726 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 727 P. Mattes, "Segment Routing Policy Architecture", draft- 728 ietf-spring-segment-routing-policy-11 (work in progress), 729 April 2021. 731 [I-D.sivabalan-pce-binding-label-sid] 732 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 733 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 734 in PCE-based Networks.", draft-sivabalan-pce-binding- 735 label-sid-07 (work in progress), July 2019. 737 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 738 IANA Considerations Section in RFCs", RFC 5226, 739 DOI 10.17487/RFC5226, May 2008, 740 . 742 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 743 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 744 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 745 2009, . 747 Authors' Addresses 749 Zhibo Hu 750 Huawei 751 Huawei Bld., No.156 Beiqing Rd. 752 Beijing 100095 753 China 755 Email: huzhibo@huawei.com 757 Huaimo Chen 758 Futurewei 759 Boston, MA 760 USA 762 Email: Huaimo.chen@futurewei.com 764 Huanan Chen 765 China Telecom 766 109, West Zhongshan Road, Tianhe District 767 Guangzhou 510000 768 China 770 Email: chenhuan6@chinatelecom.cn 772 Peng Wu 773 Huawei 774 Huawei Bld., No.156 Beiqing Rd. 775 Beijing 100095 776 China 778 Email: baggio.wupeng@huawei.com 779 Mehmet Toy 780 Verizon 781 USA 783 Email: mehmet.toy@verizon.com 785 Chang Cao 786 China Unicom 787 Beijing China 789 Email: caoc15@chinaunicom.cn 791 Tao He 792 China Unicom 793 Beijing China 795 Email: het21@chinaunicom.cn 797 Lei Liu 798 Fujitsu 799 USA 801 Email: liulei.kddi@gmail.com 803 Xufeng Liu 804 Volta Networks 805 McLean, VA 806 USA 808 Email: xufeng.liu.ietf@gmail.com