idnits 2.17.1 draft-hu-rtgwg-srv6-egress-protection-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 1, 2020) is 1489 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 264, but not defined == Unused Reference: 'RFC7356' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC8665' is defined on line 632, 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 651, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-05 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-05 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft Huawei 4 Intended status: Standards Track H. Chen 5 Expires: September 2, 2020 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 March 1, 2020 21 SRv6 Path Egress Protection 22 draft-hu-rtgwg-srv6-egress-protection-08 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 September 2, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. SR Path Egress Protection . . . . . . . . . . . . . . . . . . 4 71 3.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Extensions to IGP for Egress Protection . . . . . . . . . . . 8 74 4.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 8 75 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The fast protection of a transit node of a Segment Routing (SR) path 89 or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 90 [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] 91 specifies the fast protection of egress node(s) of an MPLS TE LSP 92 tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. 93 However, these documents do not discuss the fast protection of the 94 egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. 96 This document fills that void and presents protocol extensions for 97 the fast protection of the egress node of an SRv6 path or tunnel. 98 Egress node and egress, fast protection and protection as well as 99 SRv6 path and SRv6 tunnel will be used exchangeably below. 101 There are a number of topics related to the egress protection, which 102 include the detection of egress node failure, the relation between 103 egress protection and global repair, and so on. These are discussed 104 in details in [RFC8679]. 106 2. Terminologies 108 The following terminologies are used in this document. 110 SR: Segment Routing 112 SRv6: SR for IPv6 114 SRH: Segment Routing Header 116 SID: Segment Identifier 118 LSA: Link State Advertisement in OSPF 120 LSP: Label Switched Path in MPLS or Link State Protocol PDU in IS-IS 122 PDU: Protocol Data Unit 124 LS: Link Sate, which is LSA in OSPF or LSP in IS-IS 126 TE: Traffic Engineering 128 SA: Source Address 130 DA: Destination Address 132 P2MP: Point-to-MultiPoint 134 P2P: Point-to-Point 136 CE: Customer Edge 138 PE: Provider Edge 140 LFA: Loop-Free Alternate 142 TI-LFA: Topology Independent LFA 143 BFD: Bidirectional Forwarding Detection 145 VPN: Virtual Private Network 147 L3VPN: Layer 3 VPN 149 VRF: Virtual Routing and Forwarding 151 FIB: Forwarding Information Base 153 PLR: Point of Local Repair 155 BGP: Border Gateway Protocol 157 IGP: Interior Gateway Protocol 159 OSPF: Open Shortest Path First 161 IS-IS: Intermediate System to Intermediate System 163 3. SR Path Egress Protection 165 This section describes the mechanism of SR path egress protection and 166 illustrates it through an example. 168 3.1. Mechanism 170 Figure 1 is used to explain the mechanism of SR path egress node 171 protection. 173 ******* ******* SIDa 174 [PE1]-----[P1]-----[PEA]---[CE2] PEA Egress 175 / | |& | \ / PEB Backup Egress 176 / | |& | \ / CEx Customer Edge 177 [CE1] | |& | X Px Non-Provider Edge 178 \ | |& | / \ *** SR Path 179 \ | |& &&&&& | / \ &&& Backup Path 180 [PE2]-----[P2]-----[PEB]---[CE3] 181 Mirror SID 183 Figure 1: PEB Protects Egress PEA of SR Path 185 Where node PEA is the egress of the SR path from PE1 to PEA, and has 186 SIDa which is the active segment in the packet from the SR path at 187 PEA. Node PEB is the backup egress (or say protector) to provide the 188 protection for egress (or say primary egress) PEA. Node P1 is the 189 direct previous hop of egress PEA and acts as PLR to support the 190 protection for PEA. 192 When PEB is selected as a backup egress to protect the egress PEA, a 193 Mirror SID is configured on PEB to protect PEA. PEB advertises this 194 information through IGP, which includes the Mirror SID and the egress 195 PEA. The information is represented by , which 196 indicates that PEB protects PEA with Mirror SID. 198 After PEA receives the information , it may 199 send the forwarding behavior of the SIDa at PEA to PEB with the 200 Mirror SID using some protocols such as BGP if PEB can not obtain 201 this behavior from other approaches if PEB wants to protect SIDa of 202 PEA. How to send the forwarding behavior of the SIDa to PEB is out 203 scope of this document. 205 When PEB gets the forwarding behavior of the SIDa of PEA from PEA or 206 other means, it adds a forwarding entry for the SIDa according to the 207 behavior into the forwarding table for node PEA. This table is 208 identified by the Mirror SID, which indicates node PEA's context. 209 Using the forwarding entry for SIDa in this table, a packet with SIDa 210 will be transmitted by PEB to the same destination as it is 211 transmitted by PEA. For example, assume that the packet with SIDa is 212 transmitted by PEA to CE2 through the forwarding behavior of the SIDa 213 in PEA. The packet will be transmitted by PEB to the same CE2 214 through looking up the table identified by the Mirror SID. 216 After P1 as PLR receives the information and 217 knows that PEB wants to protect SIDa of PEA, it computes a shortest 218 path to PEB. A Repair List RL is obtained based on the path. It is 219 one of the followings: 221 o RL = if the path does not go through PEA; or 223 o RL = if the path goes through PEA, where 224 is the TI-LFA Repair List to PEB computed by P1. 226 When PEA fails, P1 as PLR sends the packet with SIDa carried by the 227 SR path to PEB, but encapsulates the packet before sending it by 228 executing H.Encaps with the Repair List RL and a Source Address T. 230 Suppose that the packet received by P1 is represented by Pkt = (S, 231 SIDa)Pkt0, where SA = S and DA = SIDa, and Pkt0 is the rest of the 232 packet. 234 The execution of H.Encaps pushes an IPv6 header to Pkt and sets some 235 fields in the outer and inner IPv6 header to produce an encapsulated 236 packet Pkt'. Pkt' will be one of the followings: 238 o Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL = ; or 239 o Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL 240 = . 242 When PEB receives the re-routed packet, which is (T, Mirror SID) (S, 243 SIDa)Pkt0, it decapsulates the packet and forwards the decapsulated 244 packet using the forwarding table identified by Mirror SID through 245 executing End.DT6. 247 It obtains the Mirror SID in the outer IPv6 header of the packet, 248 removes this outer IPv6 header with all its extension headers, and 249 then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet 250 without the outer IPv6 header). PEB finds the forwarding table for 251 node PEA using the Mirror SID as the context ID, and submits the 252 packet to this forwarding table lookup and transmission to the same 253 destination as PEA does. 255 3.2. Example 257 Figure 2 shows an example of protecting egress PE3 of a SR path, 258 which is from ingress PE1 to egress PE3. 260 ******* ******* VPN SID: A3:1::B100 261 [PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress 262 / | |& | \ / PE4 Backup Egress 263 / | |& | \ / CEx Customer Edge 264 [CE1] | |& | X Px Non-Provider Edge 265 \ | |& | / \ *** SR Path 266 \ | |& &&&&& | / \ &&& Backup Path 267 [PE2]-----[P2]-----[PE4]---[CE3] 268 VPN SID: A4:1::B100 269 Mirror SID: A4:1::3, protect PE3 271 Figure 2: PE4 Protects Egress PE3 of SR Path 273 Where node P1's pre-computed backup path for PE3 is from P1 to PE4 274 via P2. In normal operations, after receiving a packet with 275 destination PE3, P1 forwards the packet to PE3 according to its FIB. 276 When PE3 receives the packet, it sends the packet to CE2. 278 When PE3 fails, P1 as PLR detects the failure through using a failure 279 detection mechanism such as BFD and forwards the packet to PE4 via 280 the backup path. When PE4 receives the packet, it sends the packet 281 to the same CE2. 283 In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has 284 a VPN SID A3:1::B100. PE4 has a VPN SID A4:1::B100. A Mirror SID 285 A4:1::3 is configured on PE4 for protecting PE3. 287 After the configuration, PE4 advertises this information through an 288 IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE4's ID, 289 PE3's ID and Mirror SID A4:1::3. Every node in the SR domain will 290 receive this IGP LS, which indicates that PE4 wants to protect PE3 291 with Mirror SID A4:1::3. 293 When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs 294 to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds 295 PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 296 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 297 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are 298 for the same VPN. 300 The forwarding behaviors for these two VPN SIDs are the same from 301 function's point of view. If the behavior for PE3's VPN SID in PE3 302 forwards the packet with it to CE2, then the behavior for PE4's VPN 303 SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 304 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the table 305 (or FIB) identified by Mirror SID A4:1::3 according to the forwarding 306 behavior for PE4's VPN SID A4:1::B100. 308 Node P1's pre-computed backup path for destination PE3 is from P1 to 309 PE4 having mirror SID A4:1::3. When P1 receives a packet destined to 310 PE3's VPN SID A3:1::B100, in normal operations, it forwards the 311 packet with source A1:1:: and destination PE3's VPN SID A3:1::B100 312 according to the FIB using the destination PE3's VPN SID A3:1::B100. 314 When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path 315 pre-computed. P1 encapsulates the packet using H.Encaps before 316 sending it to PE4. 318 Suppose that the packet received by P1 is represented by Pkt = (SA = 319 A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, 320 and Pkt0 is the rest of the packet. The encapsulated packet Pkt' 321 will be one of the followings: 323 o Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup 324 path not via PE3; or (otherwise) 326 o Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, 327 A3:1::B100)Pkt0. 329 where T is a Source Address, is the TI-LFA Repair List 330 to PE4 computed by P1 when the backup path to PE4 goes through PE3. 332 When PE4 receives the re-routed packet, it decapsulates the packet 333 and forwards the decapsulated packet by End.DT6. The packet received 334 by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID 335 A3:1::B100)Pkt0. 337 PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the 338 packet, removes this outer IPv6 header, and then processes the inner 339 IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the forwarding table 340 for PE3 using Mirror SID A4:1::3 as the context ID, gets the 341 forwarding entry for PE3's VPN SID A3:1::B100 from the table, and 342 forwards the packet to CE2 using the entry. 344 4. Extensions to IGP for Egress Protection 346 This section describes extensions to IS-IS and OSPF for advertising 347 the information about SRv6 path egress protection. 349 4.1. Extensions to IS-IS 351 A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It 352 is used in the SRv6 Locator TLV defined in 353 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and 354 the ID of the node to be protected. The SRv6 Mirror SID inherit the 355 topology/algorithm from the parent locator. The format of the sub- 356 TLV is illustrated below. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type (TBD1) | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | SID (16 octets) | 364 : : 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | sub-TLVs | 368 : : 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: IS-IS SRv6 Mirror SID sub-TLV 373 Type: TBD1 (suggested value 8) is to be assigned by IANA. 375 Length: variable. 377 SID: 16 octets. This field contains the SRv6 Mirror SID to be 378 advertised. 380 Two sub-TLVs are defined. One is the protected node sub-TLV, and the 381 other is the protected SIDs sub-TLV. 383 A protected node sub-TLV is used to carry the ID of the node to be 384 protected by the SRv6 Mirror SID. It has the following format. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type (TBD2) | Length | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 391 | Node-ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 4: IS-IS Protected Node sub-TLV 396 Type: TBD2 (suggested value 1) is to be assigned by IANA. 398 Length: 1 octet. Its value is 6. 400 Node-ID: 6 octets. It contains a 6-octet ISO Node-ID (ISO system- 401 ID). 403 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 404 the SRv6 Mirror SID. It has the following format. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type (TBD3) | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | SID (16 octets) ~ 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 : : 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | SID (16 octets) ~ 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 5: IS-IS Protected SIDs sub-TLV 420 Type: TBD3 (suggested value 2) is to be assigned by IANA. 422 Length: variable. 424 SID: 16 octets. This field encodes an SRv6 SID to be protected. 426 When node B advertises that B wants to protect node A with a Mirror 427 SID through an LSP, the LSP contains an IS-IS SRv6 Mirror SID sub- 428 TLV, which includes the Mirror SID and the node A's ID in an IS-IS 429 Protected Node sub-TLV. If B wants to protect just a specific set of 430 SIDs of node A, the Mirror SID sub-TLV includes these SIDs in an IS- 431 IS Protected SIDs sub-TLV; otherwise (i.e., B wants to protect all 432 the SIDs of A) it does not contain any IS-IS Protected SIDs sub-TLV. 434 Note: the IS-IS extensions for SR MPLS is described in [RFC8667]. It 435 says that the SID/Label Binding TLV may also be used to advertise a 436 Mirror SID. For B to protect egress A of SR MPLS path, B may also 437 use this TLV to advertise the node A's ID and a specific set of SIDs 438 of A to be protected. An IS-IS SR MPLS Mirror SID sub-TLV may be 439 obtained from an IS-IS SRv6 Mirror SID sub-TLV by replacing each SID 440 field in the latter with an SID/Label sub-TLV. B may advertise a 441 SID/Label Binding TLV including this IS-IS SR MPLS Mirror SID sub- 442 TLV. 444 Alternatively, an IS-IS SR MPLS Mirror Supplement sub-TLV is defined 445 from an IS-IS SRv6 Mirror SID sub-TLV by removing the SID field in 446 the top level and replacing each other SID field with an SID/Label 447 sub-TLV. That is that an IS-IS SR MPLS Mirror Supplement sub-TLV 448 just contains a Protected Node sub-TLV and a Protected SIDs sub-TLV, 449 which includes SID/Label sub-TLVs. When the SID/Label Binding TLV 450 contains an SID/Label sub-TLV for the Mirror SID, it includes an IS- 451 IS SR MPLS Mirror Supplement sub-TLV. 453 4.2. Extensions to OSPF 455 Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. 456 It is used to advertise SRv6 Mirror SID and the ID of the node to be 457 protected. Its format is illustrated below. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type (TBD4) | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | SID (16 octets) | 465 : : 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | sub-TLVs | 469 : : 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Figure 6: OSPF SRv6 Mirror SID sub-TLV 474 Type: TBD4 (suggested value 8) is to be assigned by IANA. 476 Length: variable. 478 SID: 16 octets. This field contains the SRv6 Mirror SID to be 479 advertised. 481 Two sub-TLVs are defined. One is the protected node sub-TLV, and the 482 other is the protected SIDs sub-TLV. 484 A protected node sub-TLV is used to carry the ID of the node to be 485 protected by the SRv6 Mirror SID. It has the following format. 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 (TBD5) | Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Node-ID | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 7: OSPF Protected Node sub-TLV 497 Type: TBD5 (suggested value 1) is to be assigned by IANA. 499 Length: 2 octets. Its value is 4. 501 Node-ID: 4 octets. It contains the ID of the OSPF node or router to 502 be protected. 504 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 505 the SRv6 Mirror SID. It has the following format. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type (TBD6) | Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | SID (16 octets) ~ 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 : : 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | SID (16 octets) ~ 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 8: OSPF Protected SIDs sub-TLV 521 Type: TBD6 (suggested value 2) is to be assigned by IANA. 523 Length: variable. 525 SID: 16 octets. This field encodes an SRv6 SID to be protected. 527 5. Security Considerations 529 The security about the egress protection is described in in details 530 in [RFC8679]. The extensions to OSPF and IS-IS described in this 531 document for SRv6 path egress protection should not cause extra 532 security issues. 534 6. IANA Considerations 536 6.1. IS-IS 538 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 539 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 540 following new Sub-TLV: 542 +==============+=========================+===============+ 543 | Sub-TLV Type | Sub-TLV Name | Reference | 544 +==============+=========================+===============+ 545 | 8 | SRv6 Mirror SID Sub-TLV | This document | 546 +--------------+-------------------------+---------------+ 548 IANA is requested to create and maintain a new registry for sub-sub- 549 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 551 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 553 Initial values for the registry are given below. The future 554 assignments are to be made through IETF Review [RFC5226]. 556 Value Sub-Sub-TLV Name Definition 557 ----- ----------------------- ------------- 558 0 Reserved 559 1 Protected Node Sub-Sub-TLV This Document 560 2 Protected SIDs Sub-Sub-TLV 561 3-255 Unassigned 563 6.2. OSPFv3 565 Under registry "OSPFv3 Locator LSA Sub-TLVs" 566 [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the 567 following new Sub-TLV: 569 +==============+=========================+===============+ 570 | Sub-TLV Type | Sub-TLV Name | Reference | 571 +==============+=========================+===============+ 572 | 8 | SRv6 Mirror SID Sub-TLV | This document | 573 +--------------+-------------------------+---------------+ 575 IANA is requested to create and maintain a new registry for sub-sub- 576 TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry name is 578 o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV 580 Initial values for the registry are given below. The future 581 assignments are to be made through IETF Review [RFC5226]. 583 Value Sub-Sub-TLV Name Definition 584 ----- ----------------------- ------------- 585 0 Reserved 586 1 Protected Node Sub-Sub-TLV This Document 587 2 Protected SIDs Sub-Sub-TLV 588 3-65535 Unassigned 590 7. Acknowledgements 592 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 593 Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene and Jeff 594 Tantsura for their comments to this work. 596 8. References 598 8.1. Normative References 600 [I-D.ietf-lsr-isis-srv6-extensions] 601 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 602 Z. Hu, "IS-IS Extension to Support Segment Routing over 603 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 604 (work in progress), February 2020. 606 [I-D.li-ospf-ospfv3-srv6-extensions] 607 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 608 "OSPFv3 Extensions for SRv6", draft-li-ospf- 609 ospfv3-srv6-extensions-07 (work in progress), November 610 2019. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 618 Scope Link State PDUs (LSPs)", RFC 7356, 619 DOI 10.17487/RFC7356, September 2014, 620 . 622 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 623 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 624 RFC 7490, DOI 10.17487/RFC7490, April 2015, 625 . 627 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 628 "Extensions to RSVP-TE for Label Switched Path (LSP) 629 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 630 2018, . 632 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 633 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 634 Extensions for Segment Routing", RFC 8665, 635 DOI 10.17487/RFC8665, December 2019, 636 . 638 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 639 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 640 Extensions for Segment Routing", RFC 8667, 641 DOI 10.17487/RFC8667, December 2019, 642 . 644 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 645 Michel, C., and H. Chen, "MPLS Egress Protection 646 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 647 . 649 8.2. Informative References 651 [I-D.hegde-spring-node-protection-for-sr-te-paths] 652 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 653 "Node Protection for SR-TE Paths", draft-hegde-spring- 654 node-protection-for-sr-te-paths-05 (work in progress), 655 July 2019. 657 [I-D.hu-spring-segment-routing-proxy-forwarding] 658 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 659 Path Midpoint Protection", draft-hu-spring-segment- 660 routing-proxy-forwarding-07 (work in progress), January 661 2020. 663 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 664 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 665 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 666 "Topology Independent Fast Reroute using Segment Routing", 667 draft-ietf-rtgwg-segment-routing-ti-lfa-02 (work in 668 progress), January 2020. 670 [I-D.ietf-spring-segment-routing-policy] 671 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 672 P. Mattes, "Segment Routing Policy Architecture", draft- 673 ietf-spring-segment-routing-policy-06 (work in progress), 674 December 2019. 676 [I-D.sivabalan-pce-binding-label-sid] 677 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 678 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 679 in PCE-based Networks.", draft-sivabalan-pce-binding- 680 label-sid-07 (work in progress), July 2019. 682 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 683 IANA Considerations Section in RFCs", RFC 5226, 684 DOI 10.17487/RFC5226, May 2008, 685 . 687 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 688 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 689 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 690 2009, . 692 Authors' Addresses 694 Zhibo Hu 695 Huawei 696 Huawei Bld., No.156 Beiqing Rd. 697 Beijing 100095 698 China 700 Email: huzhibo@huawei.com 702 Huaimo Chen 703 Futurewei 704 Boston, MA 705 USA 707 Email: Huaimo.chen@futurewei.com 709 Huanan Chen 710 China Telecom 711 109, West Zhongshan Road, Tianhe District 712 Guangzhou 510000 713 China 715 Email: chenhuan6@chinatelecom.cn 716 Peng Wu 717 Huawei 718 Huawei Bld., No.156 Beiqing Rd. 719 Beijing 100095 720 China 722 Email: baggio.wupeng@huawei.com 724 Mehmet Toy 725 Verizon 726 USA 728 Email: mehmet.toy@verizon.com 730 Chang Cao 731 China Unicom 732 Beijing China 734 Email: caoc15@chinaunicom.cn 736 Tao He 737 China Unicom 738 Beijing China 740 Email: het21@chinaunicom.cn 742 Lei Liu 743 Fujitsu 744 USA 746 Email: liulei.kddi@gmail.com 748 Xufeng Liu 749 Volta Networks 750 McLean, VA 751 USA 753 Email: xufeng.liu.ietf@gmail.com