idnits 2.17.1 draft-chen-pce-sr-ingress-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a PCE receives an Open message without a SR_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE MUST not send the PCC any request for ingress protection of a SR path/tunnel. -- The document date (April 29, 2021) is 1086 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 148, but not defined == Missing Reference: 'CE2' is mentioned on line 148, but not defined == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.li-ospf-ospfv3-srv6-extensions' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 572, 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 591, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 609, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-13 ** Downref: Normative reference to an Experimental RFC: RFC 8424 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Toy 5 Expires: October 31, 2021 Verizon 6 A. Wang 7 China Telecom 8 Z. Li 9 China Mobile 10 L. Liu 11 Fujitsu 12 X. Liu 13 Volta Networks 14 April 29, 2021 16 SR Path Ingress Protection 17 draft-chen-pce-sr-ingress-protection-05 19 Abstract 21 This document describes extensions to Path Computation Element (PCE) 22 communication Protocol (PCEP) for protecting the ingress node of a 23 Segment Routing (SR) tunnel or path. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 31, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. SR Path Ingress Protection Example . . . . . . . . . . . . . 3 68 4. Behavior after Ingress Failure . . . . . . . . . . . . . . . 4 69 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Capability for SR Path Ingress Protection . . . . . . . . 5 71 5.2. SR Path Ingress Protection . . . . . . . . . . . . . . . 6 72 5.2.1. Traffic-Description sub-TLV . . . . . . . . . . . . . 7 73 5.2.2. Primary-Ingress sub-TLV . . . . . . . . . . . . . . . 10 74 5.2.3. Service sub-TLV . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The fast protection of a transit node of a Segment Routing (SR) path 86 or tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 87 and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8424] 88 presents extensions to RSVP-TE for the fast protection of the ingress 89 node of a traffic engineering (TE) Label Switching Path (LSP). 90 However, these documents do not discuss any protocol extensions for 91 the fast protection of the ingress node of an SR path or tunnel. 93 This document fills that void and specifies protocol extensions to 94 Path Computation Element (PCE) communication Protocol (PCEP) for the 95 fast protection of the ingress node of an SR path or tunnel. Ingress 96 node and ingress, fast protection and protection as well as SR path 97 and SR tunnel will be used exchangeably in the following sections. 99 2. Terminologies 101 The following terminologies are used in this document. 103 SR: Segment Routing 105 SRv6: SR for IPv6 107 SRH: Segment Routing Header 109 SID: Segment Identifier 111 CE: Customer Edge 113 PE: Provider Edge 115 LFA: Loop-Free Alternate 117 TI-LFA: Topology Independent LFA 119 TE: Traffic Engineering 121 BFD: Bidirectional Forwarding Detection 123 VPN: Virtual Private Network 125 L3VPN: Layer 3 VPN 127 FIB: Forwarding Information Base 129 PLR: Point of Local Repair 131 BGP: Border Gateway Protocol 133 IGP: Interior Gateway Protocol 135 OSPF: Open Shortest Path First 137 IS-IS: Intermediate System to Intermediate System 139 3. SR Path Ingress Protection Example 141 Figure 1 shows an example of protecting ingress PE1 of a SR path, 142 which is from ingress PE1 to egress PE3. 144 ******* ******* 145 [PE1]-----[P1]-----[PE3] PE1 Ingress 146 / | |& &&&&& | \ PEx Provider Edge 147 / | |& | \ CEx Customer Edge 148 [CE1] | |& | [CE2] Px Non Provider Edge 149 \ | |& | / *** SR Path 150 \ | &&&&& |& | / &&& Backup Path 151 [PE2]-----[P2]-----[PE4] 153 Figure 1: Protecting Ingress PE1 of SR Path 155 In normal operations, CE1 sends the traffic with destination PE3 to 156 ingress PE1, which imports the traffic into the SR path. 158 When CE1 detects the failure of ingress PE1, it switches the traffic 159 to backup ingress PE2, which imports the traffic from CE1 into a 160 backup SR path. The backup path is from the backup ingress PE2 to 161 the egress PE3. When the traffic is imported into the backup path, 162 it is sent to the egress PE3 along the path. 164 4. Behavior after Ingress Failure 166 After failure of the ingress of an SR path happens, there are a 167 couple of different ways to detect the failure. In each way, there 168 may be some specific behavior for the traffic source (e.g., CE1) and 169 the backup ingress (e.g., PE2). 171 In one way, the traffic source (e.g., CE1) is responsible for fast 172 detecting the failure of the ingress (e.g., PE1) of an SR path. Fast 173 detecting the failure means detecting the failure in a few or tens of 174 milliseconds. The backup ingress (e.g., PE2) is ready to import the 175 traffic from the traffic source into the backup SR path installed. 177 In normal operations, the source sends the traffic to the ingress of 178 the SR path. When the source detects the failure of the ingress, it 179 switches the traffic to the backup ingress, which delivers the 180 traffic to the egress of the SR path via the backup SR path. 182 In another way, both the backup ingress and the traffic source are 183 concurrently responsible for fast detecting the failure of the 184 ingress of an SR path. 186 In normal operations, the source (e.g., CE1) sends the traffic to the 187 ingress (e.g., PE1). It switches the traffic to the backup ingress 188 (e.g., PE2) when it detects the failure of the ingress. 190 The backup ingress does not import any traffic from the source into 191 the backup SR path in normal operations. When it detects the failure 192 of the ingress, it imports the traffic from the source into the 193 backup SR path. 195 5. Extensions to PCEP 197 PCC runs on each of the edge nodes of a network normally. PCE runs 198 on a server as a controller to communicate with PCCs. PCE and PCCs 199 work together to support protection for the ingress of a SR path. 201 5.1. Capability for SR Path Ingress Protection 203 When a PCE and a PCC establish a PCEP session between them, they 204 exchange their capabilities of supporting protection for the ingress 205 node of an SR path/tunnel. 207 A new sub-TLV called SR_INGRESS_PROTECTION_CAPABILITY is defined. It 208 is included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1 209 (suggested value 2 for backup SR path/tunnel) in the OPEN object, 210 which is exchanged in Open messages when a PCC and a PCE establish a 211 PCEP session between them. Its format is illustrated below. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type = TBD2 | Length=4 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Reserved | Flags |D|A| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: SR_INGRESS_PROTECTION_CAPABILITY sub-TLV 223 Type: TBD2 is to be assigned by IANA. 225 Length: 4. 227 Reserved: 2 octets. Must be set to zero in transmission and ignored 228 on reception. 230 Flags: 2 octets. Two flags are defined. 232 o D flag: A PCC sets this flag to 1 to indicate that it is able 233 to detect its adjacent node's failure quickly. 235 o A flag: A PCE sets this flag to 1 to request a PCC to let the 236 forwarding entry for the backup SR path/tunnel be Active. 238 A PCC, which supports ingress protection for a SR tunnel/path, sends 239 a PCE an Open message containing SR_INGRESS_PROTECTION_CAPABILITY 240 sub-TLV. This sub-TLV indicates that the PCC is capable of 241 supporting the ingress protection for a SR tunnel/path. 243 A PCE, which supports ingress protection for a SR tunnel/path, sends 244 a PCC an Open message containing SR_INGRESS_PROTECTION_CAPABILITY 245 sub-TLV. This sub-TLV indicates that the PCE is capable of 246 supporting the ingress protection for a SR tunnel/path. 248 Assume that both a PCC and a PCE support SR_PCE_CAPABILITY, that is 249 that each of the Open messages sent by the PCC and PCE contains PATH- 250 SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=1 and a SR- 251 PCE-CAPABILITY sub-TLV. 253 If a PCE receives an Open message without a 254 SR_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE 255 MUST not send the PCC any request for ingress protection of a SR 256 path/tunnel. 258 If a PCC receives an Open message without a 259 SR_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCE, then the PCC 260 MUST ignore any request for ingress protection of a SR path/tunnel 261 from the PCE. 263 If a PCC sets D flag to zero, then the PCE SHOULD send the PCC an 264 Open message with A flag set to one. When the PCE sends the PCC a 265 message for initiating a backup SR path/tunnel, the PCC SHOULD let 266 the forwarding entry for the backup SR path/tunnel be Active. 268 5.2. SR Path Ingress Protection 270 A new sub-TLV called SR_INGRESS_PROTECTION is defined. When a PCE 271 sends a PCC a PCInitiate message for initiating a backup SR path/ 272 tunnel to protect the primary ingress node of a primary SR path/ 273 tunnel, the message contains this TLV in the RP/SRP object. Its 274 format is illustrated below. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type = TBD3 | Length (variable) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved | Flags |A| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ~ ~ 284 ~ sub-TLVs (optional) ~ 285 ~ ~ 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: SR_INGRESS_PROTECTION sub-TLV 290 Type: TBD3 is to be assigned by IANA. 292 Length: Variable. 294 Reserved: 2 octets. Must be set to zero in transmission and ignored 295 on reception. 297 Flags: 2 octets. One flag is defined. 299 o A flag: A PCE sets this flag to 1 to request a PCC to let the 300 forwarding entry for the backup SR path/tunnel be Active. 302 Three optional sub-TLVs are defined. 304 5.2.1. Traffic-Description sub-TLV 306 A Traffic-Description sub-TLV describes the traffic to be imported 307 into a backup SR path/tunnel. Its format is illustrated below. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type = TBD4 | Length (variable) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ~ ~ 315 ~ sub-TLVs (optional) ~ 316 ~ ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 4: Traffic-Description sub-TLV 321 Type: TBD4 is to be assigned by IANA. 323 Length: Variable. 325 Two optional sub-TLVs are defined. One is FEC sub-TLV and the other 326 interface sub-TLV. 328 A FEC sub-TLV describes the traffic to be imported into the backup SR 329 path/tunnel. It is an IP prefix with an optional virtual network ID. 330 It has two formats: one for IPv4 and the other for IPv6, which are 331 illustrated below. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type = TBD5 | Length (variable) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |IPv4 Prefix Len| IPv4 Prefix ~ 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 ~ (Optional) Virtual Network ID (2 octets) ~ 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 5: IPv4 FEC sub-TLV 345 Type: TBD5 is to be assigned by IANA. 347 Length: Variable. 349 IPv4 Prefix Len: Indicates the length of the IPv4 Prefix. 351 IPv4 Prefix: IPv4 Prefix rounded to octets. 353 Virtual Network ID: 2 octets. This is optional. It indicates the 354 ID of a virtual network. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type = TBD6 | Length (variable) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |IPv6 Prefix Len| IPv6 Prefix ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 ~ Optional Virtual Network ID (2 octets) ~ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 6: IPv6 FEC sub-TLV 368 Type: TBD6 is to be assigned by IANA. 370 Length: Variable. 372 IPv6 Prefix Len: Indicates the length of the IPv6 Prefix. 374 IPv6 Prefix: IPv6 Prefix rounded to octets. 376 Virtual Network ID: 2 octets. This is optional. It indicates the 377 ID of a virtual network. 379 An Interface sub-TLV indicates the interface from which the traffic 380 is received and imported into the backup SR path/tunnel. It has 381 three formats: one for interface index, the other two for IPv4 and 382 IPv6 address, which are 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 = TBD7 | Length (4) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Interface Index (4 octets) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 7: Interface Index sub-TLV 394 Type: TBD7 is to be assigned by IANA. 396 Length: 4. 398 Interface Index: 4 octets. It indicates the index of an interface. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type = TBD8 | Length (4) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Interface IPv4 Address (4 octets) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 8: Interface IPv4 Address sub-TLV 410 Type: TBD8 is to be assigned by IANA. 412 Length: 4. 414 Interface IPv4 Address: 4 octets. It represents the IPv4 address of 415 an interface. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type = TBD9 | Length (16) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Interface IPv6 Address (16 octets) | 423 ~ ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 9: Interface IPv6 Address sub-TLV 428 Type: TBD9 is to be assigned by IANA. 430 Length: 16. 432 Interface IPv6 Address: 16 octets. It represents the IPv6 address 433 of an interface. 435 5.2.2. Primary-Ingress sub-TLV 437 A Primary-Ingress sub-TLV indicates the IP address of the primary 438 ingress node of a primary SR path/tunnel. It has two formats: one 439 for primary ingress node IPv4 address and the other for primary 440 ingress node IPv6 address, which are illustrated below. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type = TBDa | Length (4) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Primary Ingress IPv4 Address (4 octets) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 10: Primary Ingress IPv4 Address sub-TLV 452 Type: TBDa is to be assigned by IANA. 454 Length: 4. 456 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 457 address of the primary ingress node of a SR path/tunnel. 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 = TBDb | Length (16) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Primary Ingress IPv6 Address (16 octets) | 465 ~ ~ 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 11: Primary Ingress IPv6 Address sub-TLV 470 Type: TBDb is to be assigned by IANA. 472 Length: 16. 474 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 475 address of the primary ingress node of a SR path/tunnel. 477 5.2.3. Service sub-TLV 479 A Service sub-TLV contains a service ID or label to be added into a 480 packet to be carried by a SR path/tunnel. It has two formats: one 481 for the service identified by a label and the other for the service 482 identified by a service identifier (ID) of 32 or 128 bits, which are 483 illustrated below. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type = TBDc | Length (4) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | zero | Service Label (20 bits) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Figure 12: Service Label sub-TLV 495 Type: TBDc is to be assigned by IANA. 497 Length: 4. 499 Service Label: the least significant 20 bits. It represents a label 500 of 20 bits. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type = TBDd | Length (4/16) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Service ID (4 or 16 octets) | 508 ~ ~ 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 13: Service ID sub-TLV 513 Type: TBDd is to be assigned by IANA. 515 Length: 4 or 16. 517 Service ID: 4 or 16 octets. It represents Identifier (ID) of a 518 service in 4 or 16 octets. 520 6. Security Considerations 522 TBD 524 7. Acknowledgements 526 The authors of this document would like to thank Dhruv Dhody for the 527 review and comments. 529 8. IANA Considerations 531 TBD 533 9. References 535 9.1. Normative References 537 [I-D.bashandy-isis-srv6-extensions] 538 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 539 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 540 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 541 in progress), March 2019. 543 [I-D.hu-spring-segment-routing-proxy-forwarding] 544 Hu, Z., Chen, H., Yao, J., Bowers, C., Zhu, Y., and Y. 545 Liu, "SR-TE Path Midpoint Protection", draft-hu-spring- 546 segment-routing-proxy-forwarding-13 (work in progress), 547 February 2021. 549 [I-D.ietf-isis-segment-routing-extensions] 550 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 551 Gredler, H., and B. Decraene, "IS-IS Extensions for 552 Segment Routing", draft-ietf-isis-segment-routing- 553 extensions-25 (work in progress), May 2019. 555 [I-D.ietf-ospf-segment-routing-extensions] 556 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 557 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 558 Extensions for Segment Routing", draft-ietf-ospf-segment- 559 routing-extensions-27 (work in progress), December 2018. 561 [I-D.li-ospf-ospfv3-srv6-extensions] 562 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 563 "OSPFv3 Extensions for SRv6", draft-li-ospf- 564 ospfv3-srv6-extensions-07 (work in progress), November 565 2019. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 573 Scope Link State PDUs (LSPs)", RFC 7356, 574 DOI 10.17487/RFC7356, September 2014, 575 . 577 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 578 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 579 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 580 . 582 9.2. Informative References 584 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 585 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 586 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 587 Camarillo, "Topology Independent Fast Reroute using 588 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 589 lfa-05 (work in progress), October 2018. 591 [I-D.hegde-spring-node-protection-for-sr-te-paths] 592 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 593 "Node Protection for SR-TE Paths", draft-hegde-spring- 594 node-protection-for-sr-te-paths-07 (work in progress), 595 July 2020. 597 [I-D.ietf-spring-segment-routing-policy] 598 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 599 P. Mattes, "Segment Routing Policy Architecture", draft- 600 ietf-spring-segment-routing-policy-09 (work in progress), 601 November 2020. 603 [I-D.sivabalan-pce-binding-label-sid] 604 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 605 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 606 in PCE-based Networks.", draft-sivabalan-pce-binding- 607 label-sid-07 (work in progress), July 2019. 609 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 610 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 611 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 612 2009, . 614 Authors' Addresses 616 Huaimo Chen 617 Futurewei 618 Boston, MA 619 USA 621 Email: Huaimo.chen@futurewei.com 623 Mehmet Toy 624 Verizon 625 USA 627 Email: mehmet.toy@verizon.com 629 Aijun Wang 630 China Telecom 631 Beiqijia Town, Changping District 632 Beijing, 102209 633 China 635 Email: wangaj3@chinatelecom.cn 636 Zhenqiang Li 637 China Mobile 638 32 Xuanwumen West Ave, Xicheng District 639 Beijing, 100053 640 China 642 Email: lizhengqiang@chinamobile.com 644 Lei Liu 645 Fujitsu 647 USA 649 Email: liulei.kddi@gmail.com 651 Xufeng Liu 652 Volta Networks 654 McLean, VA 655 USA 657 Email: xufeng.liu.ietf@gmail.com