idnits 2.17.1 draft-ietf-rtgwg-srv6-egress-protection-05.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 (April 18, 2022) is 739 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 284, but not defined == Unused Reference: 'RFC7356' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC8665' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC8667' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 746, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-03 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-19 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 14 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: October 20, 2022 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 April 18, 2022 21 SRv6 Path Egress Protection 22 draft-ietf-rtgwg-srv6-egress-protection-05 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 October 20, 2022. 51 Copyright Notice 53 Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . 9 75 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 13 79 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 Tm identified by the Mirror SID as a 247 variant of End.DT6 SID. The Mirror SID is called End.M. 249 It obtains the Mirror SID in the outer IPv6 header of the packet, 250 removes this outer IPv6 header with all its extension headers, and 251 then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet 252 without the outer IPv6 header). PEB finds the FIB table Tm for node 253 PEA using the Mirror SID as the context ID, and submits the packet to 254 this FIB table lookup and transmission to the same destination as PEA 255 does. 257 The behavior of Mirror SID (End.M for short) is a variant of the 258 End.DT6 behavior (refer to Section 4.6 of [RFC8986]). The End.M SID 259 MUST be the last segment in an SR path, and a SID instance is 260 associated with an IPv6 FIB table Tm. 262 When processing the Upper-Layer header of a packet matching a FIB 263 entry locally instantiated as an End.M SID, N does the following: 265 S01. If (Upper-Layer header type == 41(IPv6) ) { 266 S02. Remove the outer IPv6 header with all its extension headers 267 S03. Set the packet's associated FIB table to Tm 268 S04. Submit the packet to the egress IPv6 FIB lookup for 269 transmission to the new destination 270 S05. } Else { 271 S06. Process as per Section 4.1.1 of RFC8986 272 S07. } 274 3.2. Example 276 Figure 2 shows an example of protecting egress PE3 of a SR path, 277 which is from ingress PE1 to egress PE3. 279 Locator: A3:1::/64 280 ******* ******* VPN SID: A3:1::B100 281 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 282 / | |& | \ / PE4 Backup Egress 283 / | |& | \ / CEx Customer Edge 284 [CE1] | |& | X Px Non-Provider Edge 285 \ | |& | / \ *** SR Path 286 \ | |& &&&&& | / \ &&& Backup Path 287 [PE2]-----[P2]-----[PE4]---[CE3] 288 Locator: A4:1::/64 289 VPN SID: A4:1::B100 290 Mirror SID: A4:1::3, protect A3:1::/64 292 Figure 2: PE4 Protects Egress PE3 of SR Path 294 Where node P1's pre-computed backup path for PE3 is from P1 to PE4 295 via P2. In normal operations, after receiving a packet with 296 destination PE3, P1 forwards the packet to PE3 according to its FIB. 297 When PE3 receives the packet, it sends the packet to CE2. 299 When PE3 fails, P1 as PLR detects the failure through using a failure 300 detection mechanism such as BFD and forwards the packet to PE4 via 301 the backup path. When PE4 receives the packet, it sends the packet 302 to the same CE2. 304 In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has 305 a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator 306 A4:1::/64 and VPN SID A4:1::B100. A Mirror SID A4:1::3 is configured 307 on PE4 for protecting PE3 with locator A3:1::/64. 309 After the configuration, PE4 advertises this information through an 310 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's 311 locator and Mirror SID A4:1::3. Every node in the SR domain will 312 receive this IGP LS, which indicates that PE4 wants to protect PE3's 313 locator with Mirror SID A4:1::3. 315 When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs 316 to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds 317 PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 318 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 319 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are 320 for the same VPN. 322 The forwarding behaviors for these two VPN SIDs are the same from 323 function's point of view. If the behavior for PE3's VPN SID in PE3 324 forwards the packet with it to CE2, then the behavior for PE4's VPN 325 SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 326 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB 327 table identified by Mirror SID A4:1::3 according to the forwarding 328 behavior for PE4's VPN SID A4:1::B100. 330 Node P1's pre-computed backup path for destination PE3`s locator is 331 from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet 332 destined to PE3's VPN SID A3:1::B100, in normal operations, it 333 forwards the packet with source A1:1:: and destination PE3's VPN SID 334 A3:1::B100 according to the FIB using the destination PE3's VPN SID 335 A3:1::B100. 337 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 338 pre-computed. P1 encapsulates the packet using H.Encaps before 339 sending it to PE4. 341 Suppose that the packet received by P1 is represented by Pkt = (SA = 342 A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, 343 and Pkt0 is the rest of the packet. The encapsulated packet Pkt' 344 will be one of the followings: 346 o Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup 347 path not via PE3; or (otherwise) 349 o Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, 350 A3:1::B100)Pkt0. 352 where T is a Source Address, is the TI-LFA Repair List 353 to PE4 computed by P1 when the backup path to PE4 goes through PE3. 355 When PE4 receives the re-routed packet, it decapsulates the packet 356 and forwards the decapsulated packet by executing End.DT6 behavior 357 for an End.DT6 SID instance. The SID instance is End.M, the Mirror 358 SID that is associated with the IPv6 FIB table for PE3. The packet 359 received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 360 A3:1::B100)Pkt0. 362 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 363 packet, removes this outer IPv6 header, and then processes the inner 364 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 365 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry 366 for PE3's VPN SID A3:1::B100 from the table, and forwards the packet 367 to CE2 using the entry. 369 4. Extensions to IGP for Egress Protection 371 This section describes extensions to IS-IS and OSPF for advertising 372 the information about SRv6 path egress protection. 374 4.1. Extensions to IS-IS 376 A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It 377 is used in the SRv6 Locator TLV defined in 378 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and 379 the locators of the node to be protected. The SRv6 Mirror SID 380 inherit the topology/algorithm from the parent locator. The format 381 of the sub-TLV is illustrated below. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type (TBD1) | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Flags | SRv6 Endpoint Function | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | SID (16 octets) | 391 : : 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | sub-TLVs | 395 : : 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 3: IS-IS SRv6 Mirror SID sub-TLV 400 Type: TBD1 (suggested value 8) is to be assigned by IANA. 402 Length: variable. 404 Flags: 1 octet. No flags are currently defined. 406 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 407 74 for Mirror SID. 409 SID: 16 octets. This field contains the SRv6 Mirror SID to be 410 advertised. 412 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 413 the other is the protected SIDs sub-TLV. 415 A protected locators sub-TLV is used to carry the Locators to be 416 protected by the SRv6 mirror SID. It has the following format. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type (TBD2) | Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Locator-Size | Locator (variable) ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 : : 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Locator-Size | Locator (variable) ~ 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 4: IS-IS Protected Locators sub-TLV 432 Type: TBD2 (suggested value 1) is to be assigned by IANA. 434 Length: variable. 436 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 437 field. 439 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 440 protected by the SRv6 mirror SID. The Locator is encoded in the 441 minimal number of octets for the given number of bits. 443 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 444 the SRv6 Mirror SID. It has the following format. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type (TBD3) | Length | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | SID-Size | SID (variable) ~ 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 : : 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | SID-Size | SID (variable) ~ 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 5: IS-IS Protected SIDs sub-TLV 460 Type: TBD3 (suggested value 2) is to be assigned by IANA. 462 Length: variable. 464 SID-Size: 1 octet. Number of bits in the SID field. It is from 1 465 to 128. When it is less than 128, the SID field is a locator. 466 When it is 128, the SID field is an SRv6 SID. 468 SID: 1-16 octets. This field encodes an SRv6 SID or locator to be 469 protected. The SID/locator is encoded in the minimal number of 470 octets for the given number of bits. Trailing bits MUST be set to 471 zero and ignored when received. 473 When node B advertises that B wants to protect node A's locators with 474 a Mirror SID through an LSP, the LSP contains an IS-IS SRv6 Mirror 475 SID sub-TLV, which includes the Mirror SID and the node A's locators 476 in an IS-IS Protected locators sub-TLV. If B wants to protect just a 477 specific set of SIDs of node A, the Mirror SID sub-TLV includes these 478 SIDs in an IS-IS Protected SIDs sub-TLV. 480 4.2. Extensions to OSPF 482 Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. 483 It is used to advertise SRv6 Mirror SID and the locators of the node 484 to be protected. Its format is illustrated below. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type (TBD4) | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Flags | SRv6 Endpoint Function | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | SID (16 octets) | 494 : : 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | sub-TLVs | 498 : : 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 6: OSPF SRv6 Mirror SID sub-TLV 503 Type: TBD4 (suggested value 8) is to be assigned by IANA. 505 Length: variable. 507 Flags: 1 octet. No flags are currently defined. 509 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 510 74 for End.M SID. 512 SID: 16 octets. This field contains the SRv6 Mirror SID to be 513 advertised. 515 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 516 the other is the protected SIDs sub-TLV. 518 A protected locators sub-TLV is used to carry the locators of the 519 node to be protected by the SRv6 Mirror SID. It has the following 520 format. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type (TBD5) | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Locator-Size | Locator (variable) ~ 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 : : 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Locator-Size | Locator (variable) ~ 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 7: OSPF Protected Locators sub-TLV 536 Type: TBD5 (suggested value 1) is to be assigned by IANA. 538 Length: variable. 540 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 541 field. 543 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 544 protected by the SRv6 mirror SID. The Locator is encoded in the 545 minimal number of octets for the given number of bits. 547 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 548 the SRv6 Mirror SID. It has the following format. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type (TBD6) | Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | SID-Size | SID (variable) ~ 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 : : 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | SID-Size | SID (variable) ~ 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 8: OSPF Protected SIDs sub-TLV 564 Type: TBD6 (suggested value 2) is to be assigned by IANA. 566 Length: variable. 568 SID-Size: 1 octet. Number of bits in the SID field. It is from 1 569 to 128. When it is less than 128, the SID field is a locator. 570 When it is 128, the SID field is an SRv6 SID. 572 SID: 1-16 octets. This field encodes an SRv6 SID or locator to be 573 protected. The SID/locator is encoded in the minimal number of 574 octets for the given number of bits. Trailing bits MUST be set to 575 zero and ignored when received. 577 5. Security Considerations 579 The security about the egress protection is described in in details 580 in [RFC8679]. The extensions to OSPF and IS-IS described in this 581 document for SRv6 path egress protection should not cause extra 582 security issues. 584 6. IANA Considerations 586 6.1. SRv6 Endpoint Behaviors 588 Under sub-registry "SRv6 Endpoint Behaviors" [RFC8986], IANA has 589 assigned the following for End.M Endpoint Behavior: 591 +==============+========+=====================+===============+ 592 | Value | Hex | Endpoint behavior | Reference | 593 +==============+========+=====================+===============+ 594 | 74 | 0x004A | End.M (Mirror SID) | This document | 595 +--------------+--------+---------------------+---------------+ 597 6.2. IS-IS 599 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 600 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 601 following new Sub-TLV: 603 +==============+=========================+===============+ 604 | Sub-TLV Type | Sub-TLV Name | Reference | 605 +==============+=========================+===============+ 606 | 8 | SRv6 Mirror SID Sub-TLV | This document | 607 +--------------+-------------------------+---------------+ 609 IANA is requested to create and maintain a new registry for sub-sub- 610 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 612 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 614 Initial values for the registry are given below. The future 615 assignments are to be made through IETF Review [RFC5226]. 617 Value Sub-Sub-TLV Name Definition 618 ----- ----------------------- ------------- 619 0 Reserved 620 1 Protected Locators Sub-Sub-TLV This Document 621 2 Protected SIDs Sub-Sub-TLV 622 3-255 Unassigned 624 6.3. OSPFv3 626 Under registry "OSPFv3 Locator LSA Sub-TLVs" 627 [I-D.ietf-lsr-ospfv3-srv6-extensions], IANA is requested to assign 628 the following new Sub-TLV: 630 +==============+=========================+===============+ 631 | Sub-TLV Type | Sub-TLV Name | Reference | 632 +==============+=========================+===============+ 633 | 8 | SRv6 Mirror SID Sub-TLV | This document | 634 +--------------+-------------------------+---------------+ 636 IANA is requested to create and maintain a new registry for sub-sub- 637 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 639 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 641 Initial values for the registry are given below. The future 642 assignments are to be made through IETF Review [RFC5226]. 644 Value Sub-Sub-TLV Name Definition 645 ----- ----------------------- ------------- 646 0 Reserved 647 1 Protected Locators Sub-Sub-TLV This Document 648 2 Protected SIDs Sub-Sub-TLV 649 3-65535 Unassigned 651 7. Acknowledgements 653 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 654 Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura, 655 Chris Bowers and Ketan Talaulikar for their comments to this work. 657 8. References 659 8.1. Normative References 661 [I-D.ietf-lsr-isis-srv6-extensions] 662 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 663 Z. Hu, "IS-IS Extensions to Support Segment Routing over 664 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 665 (work in progress), October 2021. 667 [I-D.ietf-lsr-ospfv3-srv6-extensions] 668 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 669 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 670 ospfv3-srv6-extensions-03 (work in progress), November 671 2021. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 679 Scope Link State PDUs (LSPs)", RFC 7356, 680 DOI 10.17487/RFC7356, September 2014, 681 . 683 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 684 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 685 RFC 7490, DOI 10.17487/RFC7490, April 2015, 686 . 688 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 689 "Extensions to RSVP-TE for Label Switched Path (LSP) 690 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 691 2018, . 693 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 694 Decraene, B., Litkowski, S., and R. Shakir, "Segment 695 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 696 July 2018, . 698 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 699 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 700 Extensions for Segment Routing", RFC 8665, 701 DOI 10.17487/RFC8665, December 2019, 702 . 704 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 705 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 706 Extensions for Segment Routing", RFC 8667, 707 DOI 10.17487/RFC8667, December 2019, 708 . 710 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 711 Michel, C., and H. Chen, "MPLS Egress Protection 712 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 713 . 715 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 716 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 717 (SRv6) Network Programming", RFC 8986, 718 DOI 10.17487/RFC8986, February 2021, 719 . 721 8.2. Informative References 723 [I-D.hu-spring-segment-routing-proxy-forwarding] 724 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 725 Yisong, "SR-TE Path Midpoint Restoration", draft-hu- 726 spring-segment-routing-proxy-forwarding-19 (work in 727 progress), April 2022. 729 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 730 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 731 Decraene, B., and D. Voyer, "Topology Independent Fast 732 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 733 routing-ti-lfa-08 (work in progress), January 2022. 735 [I-D.ietf-spring-segment-routing-policy] 736 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 737 P. Mattes, "Segment Routing Policy Architecture", draft- 738 ietf-spring-segment-routing-policy-22 (work in progress), 739 March 2022. 741 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 742 IANA Considerations Section in RFCs", RFC 5226, 743 DOI 10.17487/RFC5226, May 2008, 744 . 746 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 747 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 748 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 749 2009, . 751 Authors' Addresses 753 Zhibo Hu 754 Huawei 755 Huawei Bld., No.156 Beiqing Rd. 756 Beijing 100095 757 China 759 Email: huzhibo@huawei.com 761 Huaimo Chen 762 Futurewei 763 Boston, MA 764 USA 766 Email: Huaimo.chen@futurewei.com 768 Huanan Chen 769 China Telecom 770 109, West Zhongshan Road, Tianhe District 771 Guangzhou 510000 772 China 774 Email: chenhn8.gd@chinatelecom.cn 776 Peng Wu 777 Huawei 778 Huawei Bld., No.156 Beiqing Rd. 779 Beijing 100095 780 China 782 Email: baggio.wupeng@huawei.com 783 Mehmet Toy 784 Verizon 785 USA 787 Email: mehmet.toy@verizon.com 789 Chang Cao 790 China Unicom 791 Beijing China 793 Email: caoc15@chinaunicom.cn 795 Tao He 796 China Unicom 797 Beijing China 799 Email: het21@chinaunicom.cn 801 Lei Liu 802 Fujitsu 803 USA 805 Email: liulei.kddi@gmail.com 807 Xufeng Liu 808 Volta Networks 809 McLean, VA 810 USA 812 Email: xufeng.liu.ietf@gmail.com