idnits 2.17.1 draft-hu-rtgwg-srv6-egress-protection-07.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 6 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 (February 21, 2020) is 1526 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 163, but not defined == Missing Reference: 'CE2' is mentioned on line 163, but not defined == Missing Reference: 'SL' is mentioned on line 451, but not defined == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 564, 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 586, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 622, 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 (~~), 19 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: August 24, 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 February 21, 2020 21 SRv6 Path Egress Protection 22 draft-hu-rtgwg-srv6-egress-protection-07 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 August 24, 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 4. Extensions to IGP for Egress Protection . . . . . . . . . . . 6 72 4.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 6 73 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 8 74 5. Behavior for SRv6 Mirror SID . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The fast protection of a transit node of a Segment Routing (SR) path 88 or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 89 [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] 90 specifies the fast protection of egress node(s) of an MPLS TE LSP 91 tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. 92 However, these documents do not discuss the fast protection of the 93 egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. 95 This document fills that void and presents protocol extensions for 96 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 LSP: Label Switched Path 120 TE: Traffic Engineering 122 P2MP: Point-to-MultiPoint 124 P2P: Point-to-Point 126 CE: Customer Edge 128 PE: Provider Edge 130 LFA: Loop-Free Alternate 132 TI-LFA: Topology Independent LFA 134 BFD: Bidirectional Forwarding Detection 136 VPN: Virtual Private Network 138 L3VPN: Layer 3 VPN 140 VRF: Virtual Routing and Forwarding 142 FIB: Forwarding Information Base 144 PLR: Point of Local Repair 145 BGP: Border Gateway Protocol 147 IGP: Interior Gateway Protocol 149 OSPF: Open Shortest Path First 151 IS-IS: Intermediate System to Intermediate System 153 3. SR Path Egress Protection 155 Figure 1 shows an example of protecting egress PE3 of a SR path, 156 which is from ingress PE1 to egress PE3. 158 Locator: A3:1::/64 159 ******* ******* VPN SID: A3:1::B100 160 [PE1]-----[P1]-----[PE3] 161 / | |& | \ PE3 Egress 162 / | |& | \ CEx Customer Edge 163 [CE1] | |& | [CE2] Px Non-Provider Edge 164 \ | |& | / *** SR Path 165 \ | |& &&&&& | / &&& Backup Path 166 [PE2]-----[P2]-----[PE4] 167 Locator: A4:1::/64 168 VPN SID: A4:1::B100 169 Mirror SID: A4:1::3, protect A3:1::/64 171 Figure 1: Protecting SR Path Egress PE3 173 Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2. 174 In normal operations, after receiving a packet with destination PE3, 175 P1 forwards the packet to PE3 according to its FIB. When PE3 176 receives the packet, it sends the packet to CE2. 178 When PE3 fails, P1 as PLR detects the failure through using a failure 179 detection mechanism such as BFD and forwards the packet to PE4 via 180 the backup path. When PE4 receives the packet, it sends the packet 181 to the same CE2. 183 In Figure 1, CE2 is dual home to PE3 and PE4. PE3 has a locator 184 A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator A4:1::/64 and 185 a VPN SID A4:1::B100. A mirror SID A4:1::3 is configured on PE4 for 186 protecting PE3 with locator A3:1::/64. 188 After the mirror SID is configured on a local PE (e.g., PE4), when 189 the local PE (e.g., BGP on the local PE) receives a prefix whose VPN 190 SID belongs to a remote PE (e.g., PE3) with the locator that is 191 protected by the local PE through mirror SID, the local PE (e.g., 192 PE4) creates a mapping from the remote PE's (e.g., PE3's) VPN SID and 193 the mirror SID to the local PE's (e.g., PE4's) VPN SID. The remote 194 PE is protected by the local PE. 196 For example, local PE4 has Prefix 1.1.1.1 with VPN SID:A4:1::B100, 197 when PE4 receives prefix 1.1.1.1 with remote PE3's VPN SID 198 A3:1::B100, it creates a mapping from remote PE3's VPN SID and the 199 mirror SID (i.e., "A3:1::B100, A4:1::3") to local PE4's VPN SID 200 (i.e., "A4:1::B100"). 202 Node P1's pre-computed backup path for destination PE3 having locator 203 A3:1::/64 is from P1 to PE4 having mirror SID A4:1::3. When P1 204 receives a packet destined to PE3's VPN SID A3:1::B100, in normal 205 operations, it forwards the packet with source A1:1:: and destination 206 PE3's VPN SID A3:1::B100 according to the FIB using the destination 207 PE3's VPN SID A3:1::B100. 209 When PE3 fails, node P1 protects PE3 through sending the packet to 210 PE4 via the backup path pre-computed. P1 modifies the packet before 211 sending it to PE4. The modified packet has destination PE4 with 212 mirror SID A4:1::3, and SRH with PE3's VPN SID A3:1::B100 and the 213 mirror SID A4:1::3 (i.e., "A3:1::B100, A4:1::3; SL=1"). 215 When PE4 receives the packet, it forwards the packet to CE2 through 216 executing END.M instruction according to the local VPN SID (i.e., 217 A4:1::B100). 219 For protecting the egress link between PE3 and CE2, when the link 220 fails, PE3 acting as PLR like P1 detects the failure and forwards the 221 packet to PE4 via the pre-computed backup path from PE3 to PE4. When 222 PE4 receives the packet, it sends the packet to the same CE2. 224 Assume that resource X is to be protected by resource Y, where X is 225 the egress node of a SR path/tunnel or the egress link between the 226 egress node and a CE, Y is the backup egress node for providing 227 protection against the failure of X; node Z acting as PLR is the 228 direct previous hop of X. Node Z uses the procedure below to compute 229 a backup path from Z to Y without going through X. 231 Step 1: Find the P-Space P(Z, X) and the Q-Space Q(Y, X), which are 232 similar to those in [RFC7490]; 234 Step 2: Find a post-convergence path from Z to Y without going 235 through X; 237 Step 3: Try to get a backup path by intersecting P(Z, X) and Q(Y, X) 238 with the post-convergence path; 240 Step 4: If a backup path is found, then return it; 241 Step 5: Try to find a shortest path from Z to Y without going 242 through X; 244 Step 6: If a backup path is found, then return it; 246 Step 7: Return "No backup path found". 248 For a (primary) locator associated with the (primary) egress node of 249 a SR path/tunnel, most often the locator is routable. This is the 250 case we assumed, in which the above procedure is used to compute a 251 backup path from Z as PLR to Y as backup egress node. 253 4. Extensions to IGP for Egress Protection 255 This section describes extensions to IS-IS and OSPF for advertising 256 the information about SRv6 path egress protection. 258 4.1. Extensions to IS-IS 260 A new sub-TLV, called IS-IS SRv6 End.M SID sub-TLV, is defined. It 261 is used in the SRv6 Locator TLV defined in 262 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Segment 263 Identifiers (SIDs) with END.M function for SRv6 path egress 264 protection. The SRv6 End.M SIDs inherit the topology/algorithm from 265 the parent locator. The format of the sub-TLV is illustrated below. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type (TBD1) | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Flags | SRv6 Endpoint Function | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SID (16 octets) | 275 : : 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | sub-TLVs | 279 : : 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 2: IS-IS SRv6 End.M SID sub-TLV 284 Type: TBD1 (suggested value 8) is to be assigned by IANA. 286 Length: variable. 288 Flags: 1 octet. No flags are currently defined. 290 SRv6 Endpoint Function: 2 octets. Add a new endpoint function 40 291 for End.M SID. 293 SID: 16 octets. This field contains the SRv6 End.M (i.e., Mirror) 294 SID to be advertised. 296 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 297 the other is the protected SIDs sub-TLV. 299 A protected locators sub-TLV is used to carry the Locators to be 300 protected by the SRv6 mirror SID. It has the following format. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type (TBD2) | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Locator-Size | Locator (variable) ~ 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 : : 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Locator-Size | Locator (variable) ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 3: IS-IS Protected Locators sub-TLV 316 Type: TBD2 (suggested value 1) is to be assigned by IANA. 318 Length: variable. 320 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 321 field. 323 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 324 protected by the SRv6 mirror SID. The Locator is encoded in the 325 minimal number of octets for the given number of bits. 327 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 328 the SRv6 mirror SID. It has the following format. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type (TBD3) | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | SID (16 octets) ~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 : : 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | SID (16 octets) ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 4: IS-IS Protected SIDs sub-TLV 344 Type: TBD3 (suggested value 2) is to be assigned by IANA. 346 Length: variable. 348 SID: 16 octets. This field encodes an SRv6 SID to be advertised. 350 4.2. Extensions to OSPF 352 Similarly, a new sub-TLV, called OSPF SRv6 End.M SID sub-TLV, is 353 defined. It is used to advertise SRv6 Segment Identifiers (SIDs) 354 with END.M function for SRv6 path egress protection. Its format is 355 illustrated below. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type (TBD4) | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Flags | SRv6 Endpoint Function | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | SID (16 octets) | 365 : : 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | sub-TLVs | 369 : : 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 5: OSPF SRv6 End.M SID sub-TLV 374 Type: TBD4 (suggested value 8) is to be assigned by IANA. 376 Length: variable. 378 Flags: 1 octet. No flags are currently defined. 380 SRv6 Endpoint Function: 2 octets. Add a new endpoint function 40 381 for End.M SID. 383 SID: 16 octets. This field contains the SRv6 End.M (i.e., Mirror) 384 SID to be advertised. 386 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 387 the other is the protected SIDs sub-TLV. 389 A protected locators sub-TLV is used to carry the Locators to be 390 protected by the SRv6 mirror SID. It has the following format. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type (TBD5) | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Locator-Size | Locator (variable) ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 : : 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Locator-Size | Locator (variable) ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 6: OSPF Protected Locators sub-TLV 406 Type: TBD5 (suggested value 1) is to be assigned by IANA. 408 Length: variable. 410 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 411 field. 413 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 414 protected by the SRv6 mirror SID. The Locator is encoded in the 415 minimal number of octets for the given number of bits. 417 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 418 the SRv6 mirror SID. It has the following format. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type (TBD6) | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | SID (16 octets) ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 : : 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | SID (16 octets) ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 7: OSPF Protected SIDs sub-TLV 434 Type: TBD6 (suggested value 2) is to be assigned by IANA. 436 Length: variable. 438 SID: 16 octets. This field encodes an SRv6 SID to be advertised. 440 5. Behavior for SRv6 Mirror SID 442 The "Endpoint with mirror protection to a VPN SID" function (End.M 443 for short) is a variant of the End function. The End.M is used for 444 SRv6 VPN egress protection. It is described below. 446 End.M: Mirror protection 447 When N receives a packet destined to S and S is a local End.M SID, 448 N does: 449 IF NH=SRH and SL = 1 ;; Ref1 450 SL-- 451 Map to a local VPN SID based on Mirror SID and SRH[SL] ;; Ref1 452 forward according to the local VPN SID ;; Ref2 453 ELSE 454 drop the packet 456 Figure 8: SRv6 Mirror SID Procedure 458 Ref1: An End.M SID must always be the penultimate SID. 460 Ref2: The rest forwarding behavior is the same as the corresponding 461 VPN sid. 463 6. Security Considerations 465 The security about the egress protection is described in in details 466 in [RFC8679]. The extensions to OSPF and IS-IS described in this 467 document for SRv6 path egress protection should not cause extra 468 security issues. 470 7. IANA Considerations 472 7.1. IS-IS 474 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 475 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 476 following new Sub-TLV: 478 +==============+========================+===============+ 479 | Sub-TLV Type | Sub-TLV Name | Reference | 480 +==============+========================+===============+ 481 | 8 | SRv6 End.M SID Sub-TLV | This document | 482 +--------------+------------------------+---------------+ 484 IANA is requested to create and maintain a new registry for sub-sub- 485 TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is 487 o Sub-Sub-TLVs for SRv6 End.M SID Sub-TLV 489 Initial values for the registry are given below. The future 490 assignments are to be made through IETF Review [RFC5226]. 492 Value Sub-Sub-TLV Name Definition 493 ----- ----------------------- ------------- 494 0 Reserved 495 1 Protected Locators Sub-Sub-TLV This Document 496 2 Protected SIDs Sub-Sub-TLV 497 3-255 Unassigned 499 7.2. OSPFv3 501 Under registry "OSPFv3 Locator LSA Sub-TLVs" 502 [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the 503 following new Sub-TLV: 505 +==============+========================+===============+ 506 | Sub-TLV Type | Sub-TLV Name | Reference | 507 +==============+========================+===============+ 508 | 8 | SRv6 End.M SID Sub-TLV | This document | 509 +--------------+------------------------+---------------+ 511 IANA is requested to create and maintain a new registry for sub-sub- 512 TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is 514 o Sub-Sub-TLVs for SRv6 End.M SID Sub-TLV 516 Initial values for the registry are given below. The future 517 assignments are to be made through IETF Review [RFC5226]. 519 Value Sub-Sub-TLV Name Definition 520 ----- ----------------------- ------------- 521 0 Reserved 522 1 Protected Locators Sub-Sub-TLV This Document 523 2 Protected SIDs Sub-Sub-TLV 524 3-65535 Unassigned 526 8. Acknowledgements 528 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 529 Li, Bruno Decraene and Jeff Tantsura for their comments to this work. 531 9. References 533 9.1. Normative References 535 [I-D.ietf-isis-segment-routing-extensions] 536 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 537 Gredler, H., and B. Decraene, "IS-IS Extensions for 538 Segment Routing", draft-ietf-isis-segment-routing- 539 extensions-25 (work in progress), May 2019. 541 [I-D.ietf-lsr-isis-srv6-extensions] 542 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 543 Z. Hu, "IS-IS Extension to Support Segment Routing over 544 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 545 (work in progress), February 2020. 547 [I-D.ietf-ospf-segment-routing-extensions] 548 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 549 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 550 Extensions for Segment Routing", draft-ietf-ospf-segment- 551 routing-extensions-27 (work in progress), December 2018. 553 [I-D.li-ospf-ospfv3-srv6-extensions] 554 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 555 "OSPFv3 Extensions for SRv6", draft-li-ospf- 556 ospfv3-srv6-extensions-07 (work in progress), November 557 2019. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 565 Scope Link State PDUs (LSPs)", RFC 7356, 566 DOI 10.17487/RFC7356, September 2014, 567 . 569 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 570 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 571 RFC 7490, DOI 10.17487/RFC7490, April 2015, 572 . 574 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 575 "Extensions to RSVP-TE for Label Switched Path (LSP) 576 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 577 2018, . 579 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 580 Michel, C., and H. Chen, "MPLS Egress Protection 581 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 582 . 584 9.2. Informative References 586 [I-D.hegde-spring-node-protection-for-sr-te-paths] 587 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 588 "Node Protection for SR-TE Paths", draft-hegde-spring- 589 node-protection-for-sr-te-paths-05 (work in progress), 590 July 2019. 592 [I-D.hu-spring-segment-routing-proxy-forwarding] 593 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 594 Path Midpoint Protection", draft-hu-spring-segment- 595 routing-proxy-forwarding-07 (work in progress), January 596 2020. 598 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 599 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 600 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 601 "Topology Independent Fast Reroute using Segment Routing", 602 draft-ietf-rtgwg-segment-routing-ti-lfa-02 (work in 603 progress), January 2020. 605 [I-D.ietf-spring-segment-routing-policy] 606 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 607 P. Mattes, "Segment Routing Policy Architecture", draft- 608 ietf-spring-segment-routing-policy-06 (work in progress), 609 December 2019. 611 [I-D.sivabalan-pce-binding-label-sid] 612 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 613 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 614 in PCE-based Networks.", draft-sivabalan-pce-binding- 615 label-sid-07 (work in progress), July 2019. 617 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 618 IANA Considerations Section in RFCs", RFC 5226, 619 DOI 10.17487/RFC5226, May 2008, 620 . 622 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 623 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 624 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 625 2009, . 627 Authors' Addresses 629 Zhibo Hu 630 Huawei 631 Huawei Bld., No.156 Beiqing Rd. 632 Beijing 100095 633 China 635 Email: huzhibo@huawei.com 637 Huaimo Chen 638 Futurewei 639 Boston, MA 640 USA 642 Email: Huaimo.chen@futurewei.com 644 Huanan Chen 645 China Telecom 646 109, West Zhongshan Road, Tianhe District 647 Guangzhou 510000 648 China 650 Email: chenhuan6@chinatelecom.cn 651 Peng Wu 652 Huawei 653 Huawei Bld., No.156 Beiqing Rd. 654 Beijing 100095 655 China 657 Email: baggio.wupeng@huawei.com 659 Mehmet Toy 660 Verizon 661 USA 663 Email: mehmet.toy@verizon.com 665 Chang Cao 666 China Unicom 667 Beijing China 669 Email: caoc15@chinaunicom.cn 671 Tao He 672 China Unicom 673 Beijing China 675 Email: het21@chinaunicom.cn 677 Lei Liu 678 Fujitsu 679 USA 681 Email: liulei.kddi@gmail.com 683 Xufeng Liu 684 Volta Networks 685 McLean, VA 686 USA 688 Email: xufeng.liu.ietf@gmail.com