idnits 2.17.1 draft-hu-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 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 (January 16, 2020) is 1560 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 422, but not defined == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 535, 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 552, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 588, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-04 == 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-01 == 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: July 19, 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 January 16, 2020 21 SRv6 Path Egress Protection 22 draft-hu-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 July 19, 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 . . . . . . . . . . . 5 72 4.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . . . 5 73 4.2. Extensions to OSPF . . . . . . . . . . . . . . . . . . . 7 74 5. Behavior for SRv6 Mirror SID . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 TI-LFA backup path for PE3 is from P1 to PE4 174 via P2. In normal operations, after receiving a packet with 175 destination PE3, P1 forwards the packet to PE3 according to its FIB. 176 When PE3 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 TI-LFA backup path for destination PE3 having 203 locator A3:1::/64 is from P1 to PE4 having mirror SID A4:1::3. When 204 P1 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 4. Extensions to IGP for Egress Protection 226 This section describes extensions to IS-IS and OSPF for advertising 227 the information about SRv6 path egress protection. 229 4.1. Extensions to IS-IS 231 A new sub-TLV, called IS-IS SRv6 End.M SID sub-TLV, is defined. It 232 is used in the SRv6 Locator TLV defined in 233 [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Segment 234 Identifiers (SIDs) with END.M function for SRv6 path egress 235 protection. The SRv6 End.M SIDs inherit the topology/algorithm from 236 the parent locator. The format of the sub-TLV is illustrated below. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type (TBD1) | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Flags | SRv6 Endpoint Function | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | SID (16 octets) | 246 : : 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | sub-TLVs | 250 : : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: IS-IS SRv6 End.M SID sub-TLV 255 Type: TBD1 (suggested value 8) is to be assigned by IANA. 257 Length: variable. 259 Flags: 1 octet. No flags are currently defined. 261 SRv6 Endpoint Function: 2 octets. Add a new endpoint function 40 262 for End.M SID. 264 SID: 16 octets. This field contains the SRv6 End.M SID to be 265 advertised. 267 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 268 the other is the protected SIDs sub-TLV. 270 A protected locators sub-TLV is used to carry the Locators to be 271 protected by the SRv6 mirror SID. It has the following format. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type (TBD2) | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Locator-Size | Locator (variable) ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 : : 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Locator-Size | Locator (variable) ~ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 3: IS-IS Protected Locators sub-TLV 287 Type: TBD2 (suggested value 1) is to be assigned by IANA. 289 Length: variable. 291 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 292 field. 294 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 295 protected by the SRv6 mirror SID. The Locator is encoded in the 296 minimal number of octets for the given number of bits. 298 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 299 the SRv6 mirror SID. It has the following format. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type (TBD3) | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SID (16 octets) ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 : : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SID (16 octets) ~ 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 4: IS-IS Protected SIDs sub-TLV 315 Type: TBD3 (suggested value 2) is to be assigned by IANA. 317 Length: variable. 319 SID: 16 octets. This field encodes an SRv6 SID to be advertised. 321 4.2. Extensions to OSPF 323 Similarly, a new sub-TLV, called OSPF SRv6 End.M SID sub-TLV, is 324 defined. It is used to advertise SRv6 Segment Identifiers (SIDs) 325 with END.M function for SRv6 path egress protection. Its format is 326 illustrated below. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type (TBD4) | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Flags | SRv6 Endpoint Function | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | SID (16 octets) | 336 : : 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | sub-TLVs | 340 : : 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 5: OSPF SRv6 End.M SID sub-TLV 345 Type: TBD4 (suggested value 8) is to be assigned by IANA. 347 Length: variable. 349 Flags: 1 octet. No flags are currently defined. 351 SRv6 Endpoint Function: 2 octets. Add a new endpoint function 40 352 for End.M SID. 354 SID: 16 octets. This field contains the SRv6 End.M SID to be 355 advertised. 357 Two sub-TLVs are defined. One is the protected locators sub-TLV, and 358 the other is the protected SIDs sub-TLV. 360 A protected locators sub-TLV is used to carry the Locators to be 361 protected by the SRv6 mirror SID. It has the following format. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type (TBD5) | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Locator-Size | Locator (variable) ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 : : 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Locator-Size | Locator (variable) ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 6: OSPF Protected Locators sub-TLV 377 Type: TBD5 (suggested value 1) is to be assigned by IANA. 379 Length: variable. 381 Locator-Size: 1 octet. Number of bits (1 - 128) in the Locator 382 field. 384 Locator: 1-16 octets. This field encodes an SRv6 Locator to be 385 protected by the SRv6 mirror SID. The Locator is encoded in the 386 minimal number of octets for the given number of bits. 388 A protected SIDs sub-TLV is used to carry the SIDs to be protected by 389 the SRv6 mirror SID. It has the following format. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type (TBD6) | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | SID (16 octets) ~ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | SID (16 octets) ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 7: OSPF Protected SIDs sub-TLV 405 Type: TBD6 (suggested value 2) is to be assigned by IANA. 407 Length: variable. 409 SID: 16 octets. This field encodes an SRv6 SID to be advertised. 411 5. Behavior for SRv6 Mirror SID 413 The "Endpoint with mirror protection to a VPN SID" function (End.M 414 for short) is a variant of the End function. The End.M is used for 415 SRv6 VPN egress protection. It is described below. 417 End.M: Mirror protection 418 When N receives a packet destined to S and S is a local End.M SID, 419 N does: 420 IF NH=SRH and SL = 1 ;; Ref1 421 SL-- 422 Map to a local VPN SID based on Mirror SID and SRH[SL] ;; Ref1 423 forward according to the local VPN SID ;; Ref2 424 ELSE 425 drop the packet 427 Figure 8: SRv6 Mirror SID Procedure 429 Ref1: An End.M SID must always be the penultimate SID. 431 Ref2: The rest forwarding behavior is the same as the corresponding 432 VPN sid. 434 6. Security Considerations 436 The security about the egress protection is described in in details 437 in [RFC8679]. The extensions to OSPF and IS-IS described in this 438 document for SRv6 path egress protection should not cause extra 439 security issues. 441 7. IANA Considerations 443 7.1. IS-IS 445 Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" 446 [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the 447 following new Sub-TLV: 449 +==============+========================+===============+ 450 | Sub-TLV Type | Sub-TLV Name | Reference | 451 +==============+========================+===============+ 452 | 8 | SRv6 End.M SID Sub-TLV | This document | 453 +--------------+------------------------+---------------+ 455 IANA is requested to create and maintain a new registry for sub-sub- 456 TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is 458 o Sub-Sub-TLVs for SRv6 End.M SID Sub-TLV 460 Initial values for the registry are given below. The future 461 assignments are to be made through IETF Review [RFC5226]. 463 Value Sub-Sub-TLV Name Definition 464 ----- ----------------------- ------------- 465 0 Reserved 466 1 Protected Locators Sub-Sub-TLV This Document 467 2 Protected SIDs Sub-Sub-TLV 468 3-255 Unassigned 470 7.2. OSPFv3 472 Under registry "OSPFv3 Locator LSA Sub-TLVs" 473 [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the 474 following new Sub-TLV: 476 +==============+========================+===============+ 477 | Sub-TLV Type | Sub-TLV Name | Reference | 478 +==============+========================+===============+ 479 | 8 | SRv6 End.M SID Sub-TLV | This document | 480 +--------------+------------------------+---------------+ 482 IANA is requested to create and maintain a new registry for sub-sub- 483 TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is 485 o Sub-Sub-TLVs for SRv6 End.M SID Sub-TLV 487 Initial values for the registry are given below. The future 488 assignments are to be made through IETF Review [RFC5226]. 490 Value Sub-Sub-TLV Name Definition 491 ----- ----------------------- ------------- 492 0 Reserved 493 1 Protected Locators Sub-Sub-TLV This Document 494 2 Protected SIDs Sub-Sub-TLV 495 3-65535 Unassigned 497 8. Acknowledgements 499 The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang 500 Li, Bruno Decraene and Jeff Tantsura for their comments to this work. 502 9. References 504 9.1. Normative References 506 [I-D.ietf-isis-segment-routing-extensions] 507 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 508 Gredler, H., and B. Decraene, "IS-IS Extensions for 509 Segment Routing", draft-ietf-isis-segment-routing- 510 extensions-25 (work in progress), May 2019. 512 [I-D.ietf-lsr-isis-srv6-extensions] 513 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 514 Z. Hu, "IS-IS Extension to Support Segment Routing over 515 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-04 516 (work in progress), January 2020. 518 [I-D.ietf-ospf-segment-routing-extensions] 519 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 520 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 521 Extensions for Segment Routing", draft-ietf-ospf-segment- 522 routing-extensions-27 (work in progress), December 2018. 524 [I-D.li-ospf-ospfv3-srv6-extensions] 525 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 526 "OSPFv3 Extensions for SRv6", draft-li-ospf- 527 ospfv3-srv6-extensions-07 (work in progress), November 528 2019. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, 532 DOI 10.17487/RFC2119, March 1997, 533 . 535 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 536 Scope Link State PDUs (LSPs)", RFC 7356, 537 DOI 10.17487/RFC7356, September 2014, 538 . 540 [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, 541 "Extensions to RSVP-TE for Label Switched Path (LSP) 542 Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 543 2018, . 545 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 546 Michel, C., and H. Chen, "MPLS Egress Protection 547 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 548 . 550 9.2. Informative References 552 [I-D.hegde-spring-node-protection-for-sr-te-paths] 553 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 554 "Node Protection for SR-TE Paths", draft-hegde-spring- 555 node-protection-for-sr-te-paths-05 (work in progress), 556 July 2019. 558 [I-D.hu-spring-segment-routing-proxy-forwarding] 559 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 560 Path Midpoint Protection", draft-hu-spring-segment- 561 routing-proxy-forwarding-07 (work in progress), January 562 2020. 564 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 565 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 566 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 567 "Topology Independent Fast Reroute using Segment Routing", 568 draft-ietf-rtgwg-segment-routing-ti-lfa-01 (work in 569 progress), March 2019. 571 [I-D.ietf-spring-segment-routing-policy] 572 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 573 P. Mattes, "Segment Routing Policy Architecture", draft- 574 ietf-spring-segment-routing-policy-06 (work in progress), 575 December 2019. 577 [I-D.sivabalan-pce-binding-label-sid] 578 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 579 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 580 in PCE-based Networks.", draft-sivabalan-pce-binding- 581 label-sid-07 (work in progress), July 2019. 583 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 584 IANA Considerations Section in RFCs", RFC 5226, 585 DOI 10.17487/RFC5226, May 2008, 586 . 588 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 589 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 590 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 591 2009, . 593 Authors' Addresses 595 Zhibo Hu 596 Huawei 597 Huawei Bld., No.156 Beiqing Rd. 598 Beijing 100095 599 China 601 Email: huzhibo@huawei.com 602 Huaimo Chen 603 Futurewei 604 Boston, MA 605 USA 607 Email: Huaimo.chen@futurewei.com 609 Huanan Chen 610 China Telecom 611 109, West Zhongshan Road, Tianhe District 612 Guangzhou 510000 613 China 615 Email: chenhn8.gd@chinatelecom.cn 617 Peng Wu 618 Huawei 619 Huawei Bld., No.156 Beiqing Rd. 620 Beijing 100095 621 China 623 Email: baggio.wupeng@huawei.com 625 Mehmet Toy 626 Verizon 627 USA 629 Email: mehmet.toy@verizon.com 631 Chang Cao 632 China Unicom 633 Beijing China 635 Email: caoc15@chinaunicom.cn 637 Tao He 638 China Unicom 639 Beijing China 641 Email: het21@chinaunicom.cn 642 Lei Liu 643 Fujitsu 644 USA 646 Email: liulei.kddi@gmail.com 648 Xufeng Liu 649 Volta Networks 650 McLean, VA 651 USA 653 Email: xufeng.liu.ietf@gmail.com