idnits 2.17.1 draft-ietf-rtgwg-srv6-egress-protection-04.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 (17 October 2021) is 920 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 285, but not defined == Unused Reference: 'RFC7356' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC8665' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC8667' 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 742, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 755, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-17 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-02 == 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-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 15 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: 20 April 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 17 October 2021 21 SRv6 Path Egress Protection 22 draft-ietf-rtgwg-srv6-egress-protection-04 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." 50 This Internet-Draft will expire on 20 April 2022. 52 Copyright Notice 54 Copyright (c) 2021 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 59 license-info) in effect on the date of publication of this document. 60 Please review these documents carefully, as they describe your rights 61 and restrictions with respect to this document. Code Components 62 extracted from this document must include Simplified BSD License text 63 as described in Section 4.e of the Trust Legal Provisions and are 64 provided without warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. SR Path Egress Protection . . . . . . . . . . . . . . . . . . 4 71 3.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Extensions to IGP for Egress Protection . . . . . . . . . . . 9 74 4.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 9 75 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 14 79 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 8.2. Informative References . . . . . . . . . . . . . . . . . 17 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 134 P2P: Point-to-Point 136 CE: Customer Edge 138 PE: Provider Edge 140 LFA: Loop-Free Alternate 142 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 242 o Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL 243 = . 245 When PEB receives the re-routed packet, which is (T, Mirror SID) (S, 246 SIDa)Pkt0, it decapsulates the packet and forwards the decapsulated 247 packet using the FIB table Tm identified by the Mirror SID as a 248 variant of End.DT6 SID. The Mirror SID is called 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 Tm for node 254 PEA 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 The behavior of Mirror SID (End.M for short) is a variant of the 259 End.DT6 behavior (refer to Section 4.6 of [RFC8986]). The End.M SID 260 MUST be the last segment in an SR path, and a SID instance is 261 associated with an IPv6 FIB table Tm. 263 When processing the Upper-Layer header of a packet matching a FIB 264 entry locally instantiated as an End.M SID, N does the following: 266 S01. If (Upper-Layer header type == 41(IPv6) ) { 267 S02. Remove the outer IPv6 header with all its extension headers 268 S03. Set the packet's associated FIB table to Tm 269 S04. Submit the packet to the egress IPv6 FIB lookup for 270 transmission to the new destination 271 S05. } Else { 272 S06. Process as per Section 4.1.1 of RFC8986 273 S07. } 275 3.2. Example 277 Figure 2 shows an example of protecting egress PE3 of a SR path, 278 which is from ingress PE1 to egress PE3. 280 Locator: A3:1::/64 281 ******* ******* VPN SID: A3:1::B100 282 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 283 / | |& | \ / PE4 Backup Egress 284 / | |& | \ / CEx Customer Edge 285 [CE1] | |& | X Px Non-Provider Edge 286 \ | |& | / \ *** SR Path 287 \ | |& &&&&& | / \ &&& Backup Path 288 [PE2]-----[P2]-----[PE4]---[CE3] 289 Locator: A4:1::/64 290 VPN SID: A4:1::B100 291 Mirror SID: A4:1::3, protect A3:1::/64 293 Figure 2: PE4 Protects Egress PE3 of SR Path 295 Where node P1's pre-computed backup path for PE3 is from P1 to PE4 296 via P2. In normal operations, after receiving a packet with 297 destination PE3, P1 forwards the packet to PE3 according to its FIB. 298 When PE3 receives the packet, it sends the packet to CE2. 300 When PE3 fails, P1 as PLR detects the failure through using a failure 301 detection mechanism such as BFD and forwards the packet to PE4 via 302 the backup path. When PE4 receives the packet, it sends the packet 303 to the same CE2. 305 In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has 306 a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator 307 A4:1::/64 and VPN SID A4:1::B100. A Mirror SID A4:1::3 is configured 308 on PE4 for protecting PE3 with locator A3:1::/64. 310 After the configuration, PE4 advertises this information through an 311 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's 312 locator and Mirror SID A4:1::3. Every node in the SR domain will 313 receive this IGP LS, which indicates that PE4 wants to protect PE3's 314 locator with Mirror SID A4:1::3. 316 When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs 317 to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds 318 PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 319 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 320 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are 321 for the same VPN. 323 The forwarding behaviors for these two VPN SIDs are the same from 324 function's point of view. If the behavior for PE3's VPN SID in PE3 325 forwards the packet with it to CE2, then the behavior for PE4's VPN 326 SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 327 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB 328 table identified by Mirror SID A4:1::3 according to the forwarding 329 behavior for PE4's VPN SID A4:1::B100. 331 Node P1's pre-computed backup path for destination PE3`s locator is 332 from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet 333 destined to PE3's VPN SID A3:1::B100, in normal operations, it 334 forwards the packet with source A1:1:: and destination PE3's VPN SID 335 A3:1::B100 according to the FIB using the destination PE3's VPN SID 336 A3:1::B100. 338 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 339 pre-computed. P1 encapsulates the packet using H.Encaps before 340 sending it to PE4. 342 Suppose that the packet received by P1 is represented by Pkt = (SA = 343 A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, 344 and Pkt0 is the rest of the packet. The encapsulated packet Pkt' 345 will be one of the followings: 347 o Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup 348 path not via PE3; or (otherwise) 350 o Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, 351 A3:1::B100)Pkt0. 353 where T is a Source Address, is the TI-LFA Repair List 354 to PE4 computed by P1 when the backup path to PE4 goes through PE3. 356 When PE4 receives the re-routed packet, it decapsulates the packet 357 and forwards the decapsulated packet by executing End.DT6 behavior 358 for an End.DT6 SID instance. The SID instance is End.M, the Mirror 359 SID that is associated with the IPv6 FIB table for PE3. The packet 360 received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 361 A3:1::B100)Pkt0. 363 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 364 packet, removes this outer IPv6 header, and then processes the inner 365 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 366 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry 367 for PE3's VPN SID A3:1::B100 from the table, and forwards the packet 368 to CE2 using the entry. 370 4. Extensions to IGP for Egress Protection 372 This section describes extensions to IS-IS and OSPF for advertising 373 the information about SRv6 path egress protection. 375 4.1. Extensions to IS-IS 377 A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It 378 is used in the SRv6 Locator TLV defined in 379 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and 380 the locators of the node to be protected. The SRv6 Mirror SID 381 inherit the topology/algorithm from the parent locator. The format 382 of the sub-TLV is illustrated below. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type (TBD1) | Length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Flags | SRv6 Endpoint Function | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | SID (16 octets) | 392 : : 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | sub-TLVs | 396 : : 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 3: IS-IS SRv6 Mirror SID sub-TLV 401 Type: TBD1 (suggested value 8) is to be assigned by IANA. 403 Length: variable. 405 Flags: 1 octet. No flags are currently defined. 407 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 408 74 for Mirror SID. 410 SID: 16 octets. This field contains the SRv6 Mirror SID to be 411 advertised. 413 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 414 the other is the protected SIDs sub-TLV. 416 A protected locators sub-TLV is used to carry the Locators to be 417 protected by the SRv6 mirror SID. It has the following format. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type (TBD2) | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Locator-Size | Locator (variable) ~ 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 : : 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Locator-Size | Locator (variable) ~ 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 4: IS-IS Protected Locators sub-TLV 433 Type: TBD2 (suggested value 1) is to be assigned by IANA. 435 Length: variable. 437 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 438 field. 440 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 441 protected by the SRv6 mirror SID. The Locator is encoded in the 442 minimal number of octets for the given number of bits. 444 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 445 the SRv6 Mirror SID. It has the following format. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type (TBD3) | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | SID-Size | SID (variable) ~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 : : 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | SID-Size | SID (variable) ~ 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 5: IS-IS Protected SIDs sub-TLV 461 Type: TBD3 (suggested value 2) is to be assigned by IANA. 463 Length: variable. 465 SID-Size: 1 octet. Number of bits in the SID field. It is from 1 466 to 128. When it is less than 128, the SID field is a locator. 467 When it is 128, the SID field is an SRv6 SID. 469 SID: 1-16 octets. This field encodes an SRv6 SID or locator to be 470 protected. The SID/locator is encoded in the minimal number of 471 octets for the given number of bits. Trailing bits MUST be set to 472 zero and ignored when received. 474 When node B advertises that B wants to protect node A's locators with 475 a Mirror SID through an LSP, the LSP contains an IS-IS SRv6 Mirror 476 SID sub-TLV, which includes the Mirror SID and the node A's locators 477 in an IS-IS Protected locators sub-TLV. If B wants to protect just a 478 specific set of SIDs of node A, the Mirror SID sub-TLV includes these 479 SIDs in an IS-IS Protected SIDs sub-TLV. 481 4.2. Extensions to OSPF 483 Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. 484 It is used to advertise SRv6 Mirror SID and the locators of the node 485 to be protected. Its format is illustrated below. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type (TBD4) | Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Flags | SRv6 Endpoint Function | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | SID (16 octets) | 495 : : 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | sub-TLVs | 499 : : 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 6: OSPF SRv6 Mirror SID sub-TLV 504 Type: TBD4 (suggested value 8) is to be assigned by IANA. 506 Length: variable. 508 Flags: 1 octet. No flags are currently defined. 510 SRv6 Endpoint Function: 2 octets. It contains the endpoint function 511 74 for End.M SID. 513 SID: 16 octets. This field contains the SRv6 Mirror SID to be 514 advertised. 516 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 517 the other is the protected SIDs sub-TLV. 519 A protected locators sub-TLV is used to carry the locators of the 520 node to be protected by the SRv6 Mirror SID. It has the following 521 format. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type (TBD5) | Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Locator-Size | Locator (variable) ~ 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 : : 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Locator-Size | Locator (variable) ~ 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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", Work in Progress, Internet-Draft, draft- 665 ietf-lsr-isis-srv6-extensions-17, 18 June 2021, 666 . 669 [I-D.ietf-lsr-ospfv3-srv6-extensions] 670 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 671 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 672 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-02, 15 673 February 2021, . 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 682 Scope Link State PDUs (LSPs)", RFC 7356, 683 DOI 10.17487/RFC7356, September 2014, 684 . 686 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 687 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 688 RFC 7490, DOI 10.17487/RFC7490, April 2015, 689 . 691 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 692 "Extensions to RSVP-TE for Label Switched Path (LSP) 693 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 694 2018, . 696 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 697 Decraene, B., Litkowski, S., and R. Shakir, "Segment 698 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 699 July 2018, . 701 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 702 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 703 Extensions for Segment Routing", RFC 8665, 704 DOI 10.17487/RFC8665, December 2019, 705 . 707 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 708 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 709 Extensions for Segment Routing", RFC 8667, 710 DOI 10.17487/RFC8667, December 2019, 711 . 713 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 714 Michel, C., and H. Chen, "MPLS Egress Protection 715 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 716 . 718 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 719 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 720 (SRv6) Network Programming", RFC 8986, 721 DOI 10.17487/RFC8986, February 2021, 722 . 724 8.2. Informative References 726 [I-D.hu-spring-segment-routing-proxy-forwarding] 727 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 728 Yisong, "SR-TE Path Midpoint Restoration", Work in 729 Progress, Internet-Draft, draft-hu-spring-segment-routing- 730 proxy-forwarding-14, 29 April 2021, 731 . 734 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 735 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 736 Decraene, B., and D. Voyer, "Topology Independent Fast 737 Reroute using Segment Routing", Work in Progress, 738 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 739 07, 29 June 2021, . 742 [I-D.ietf-spring-segment-routing-policy] 743 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 744 P. Mattes, "Segment Routing Policy Architecture", Work in 745 Progress, Internet-Draft, draft-ietf-spring-segment- 746 routing-policy-13, 28 May 2021, 747 . 750 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 751 IANA Considerations Section in RFCs", RFC 5226, 752 DOI 10.17487/RFC5226, May 2008, 753 . 755 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 756 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 757 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 758 2009, . 760 Authors' Addresses 762 Zhibo Hu 763 Huawei 764 Huawei Bld., No.156 Beiqing Rd. 765 Beijing 766 100095 767 China 769 Email: huzhibo@huawei.com 771 Huaimo Chen 772 Futurewei 773 Boston, MA, 774 United States of America 776 Email: Huaimo.chen@futurewei.com 778 Huanan Chen 779 China Telecom 780 109, West Zhongshan Road, Tianhe District 781 Guangzhou 782 510000 783 China 785 Email: chenhn8.gd@chinatelecom.cn 787 Peng Wu 788 Huawei 789 Huawei Bld., No.156 Beiqing Rd. 790 Beijing 791 100095 792 China 794 Email: baggio.wupeng@huawei.com 796 Mehmet Toy 797 Verizon 798 United States of America 800 Email: mehmet.toy@verizon.com 802 Chang Cao 803 China Unicom 805 Email: caoc15@chinaunicom.cn 806 Tao He 807 China Unicom 809 Email: het21@chinaunicom.cn 811 Lei Liu 812 Fujitsu 813 United States of America 815 Email: liulei.kddi@gmail.com 817 Xufeng Liu 818 Volta Networks 819 McLean, VA 820 United States of America 822 Email: xufeng.liu.ietf@gmail.com