idnits 2.17.1 draft-chen-pce-sr-ingress-protection-01.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 (October 22, 2019) is 1642 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 548, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'I-D.li-ospf-ospfv3-srv6-extensions' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 570, 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 589, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 607, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-04 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-05 ** Downref: Normative reference to an Experimental RFC: RFC 8424 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 1 error (**), 0 flaws (~~), 17 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: April 24, 2020 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 October 22, 2019 16 SR Path Ingress Protection 17 draft-chen-pce-sr-ingress-protection-01 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 April 24, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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., and Y. Zhu, "SR-TE 545 Path Midpoint Protection", draft-hu-spring-segment- 546 routing-proxy-forwarding-04 (work in progress), July 2019. 548 [I-D.ietf-isis-segment-routing-extensions] 549 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 550 Gredler, H., and B. Decraene, "IS-IS Extensions for 551 Segment Routing", draft-ietf-isis-segment-routing- 552 extensions-25 (work in progress), May 2019. 554 [I-D.ietf-ospf-segment-routing-extensions] 555 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 556 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 557 Extensions for Segment Routing", draft-ietf-ospf-segment- 558 routing-extensions-27 (work in progress), December 2018. 560 [I-D.li-ospf-ospfv3-srv6-extensions] 561 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 562 "OSPFv3 Extensions for SRv6", draft-li-ospf- 563 ospfv3-srv6-extensions-05 (work in progress), August 2019. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 571 Scope Link State PDUs (LSPs)", RFC 7356, 572 DOI 10.17487/RFC7356, September 2014, 573 . 575 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 576 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 577 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 578 . 580 9.2. Informative References 582 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 583 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 584 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 585 Camarillo, "Topology Independent Fast Reroute using 586 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 587 lfa-05 (work in progress), October 2018. 589 [I-D.hegde-spring-node-protection-for-sr-te-paths] 590 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 591 "Node Protection for SR-TE Paths", draft-hegde-spring- 592 node-protection-for-sr-te-paths-05 (work in progress), 593 July 2019. 595 [I-D.ietf-spring-segment-routing-policy] 596 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 597 bogdanov@google.com, b., and P. Mattes, "Segment Routing 598 Policy Architecture", draft-ietf-spring-segment-routing- 599 policy-03 (work in progress), May 2019. 601 [I-D.sivabalan-pce-binding-label-sid] 602 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 603 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 604 in PCE-based Networks.", draft-sivabalan-pce-binding- 605 label-sid-07 (work in progress), July 2019. 607 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 608 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 609 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 610 2009, . 612 Authors' Addresses 614 Huaimo Chen 615 Futurewei 616 Boston, MA 617 USA 619 Email: Huaimo.chen@futurewei.com 621 Mehmet Toy 622 Verizon 623 USA 625 Email: mehmet.toy@verizon.com 627 Aijun Wang 628 China Telecom 629 Beiqijia Town, Changping District 630 Beijing 102209 631 China 633 Email: wangaj.bri@chinatelecom.cn 634 Zhenqiang Li 635 China Mobile 636 32 Xuanwumen West Ave, Xicheng District 637 Beijing 100053 638 China 640 Email: lizhengqiang@chinamobile.com 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