idnits 2.17.1 draft-chen-pce-sr-ingress-protection-00.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 (July 6, 2019) is 1756 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 145, but not defined == Missing Reference: 'CE2' is mentioned on line 145, but not defined == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'I-D.li-ospf-ospfv3-srv6-extensions' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 617, 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 631, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 649, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-03 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-03 == 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 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-06 Summary: 0 errors (**), 0 flaws (~~), 18 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: January 7, 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 July 6, 2019 16 SR Path Ingress Protection 17 draft-chen-pce-sr-ingress-protection-00 19 Abstract 21 This document describes protocol extensions and procedures for 22 protecting the ingress node of a Segment Routing (SR) path. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 7, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. SR Path Ingress Protection Example . . . . . . . . . . . . . 3 67 4. Behavior after Ingress Failure . . . . . . . . . . . . . . . 4 68 5. Extensions to PCE . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Capability for SR Path Ingress Protection . . . . . . . . 5 70 5.2. SR Path Ingress Protection . . . . . . . . . . . . . . . 6 71 5.2.1. Traffic-Description sub-TLV . . . . . . . . . . . . . 7 72 5.2.2. Primary-Ingress sub-TLV . . . . . . . . . . . . . . . 10 73 5.2.3. Service sub-TLV . . . . . . . . . . . . . . . . . . . 11 74 5.2.4. Downstream-Node sub-TLV . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 9.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Fast protection of a transit node of a Segment Routing (SR) path is 86 described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and 87 [I-D.hu-spring-segment-routing-proxy-forwarding]. However, these 88 documents do not discuss the procedures for fast protection of the 89 ingress node of an SR path. 91 This document fills that void and specifies protocol extensions and 92 procedures for fast protection of the ingress node of an SR path. 93 Ingress node and ingress as well as fast protection and protection 94 will be used exchangeably. 96 2. Terminologies 98 The following terminologies are used in this document. 100 SR: Segment Routing 102 SRv6: SR for IPv6 104 SRH: Segment Routing Header 106 SID: Segment Identifier 108 CE: Customer Edge 110 PE: Provider Edge 112 LFA: Loop-Free Alternate 114 TI-LFA: Topology Independent LFA 116 TE: Traffic Engineering 118 BFD: Bidirectional Forwarding Detection 120 VPN: Virtual Private Network 122 L3VPN: Layer 3 VPN 124 FIB: Forwarding Information Base 126 PLR: Point of Local Repair 128 BGP: Border Gateway Protocol 130 IGP: Interior Gateway Protocol 132 OSPF: Open Shortest Path First 134 IS-IS: Intermediate System to Intermediate System 136 3. SR Path Ingress Protection Example 138 Figure 1 shows an example of protecting ingress PE1 of a SR path, 139 which is from ingress PE1 to egress PE3. 141 ******* ******* 142 [PE1]-----[P1]-----[PE3] 143 / | |& | \ PE1 Ingress 144 / | |& | \ CEx Customer Edge 145 [CE1] | |& | [CE2] Px Non-Ingress 146 \ | |& | / *** SR Path 147 \ | &&&&&& |& | / &&& Backup Path 148 [PE2]-----[P2]-----[PE4] 150 Figure 1: Protecting SR Path Ingress PE1 152 In normal operations, CE1 sends the traffic with destination PE3 to 153 ingress PE1, which imports the traffic into the SR path. 155 When CE1 detects the failure of ingress PE1, it switches the traffic 156 to backup ingress PE2, which imports the traffic from CE1 into a 157 backup SR path. In one option, this backup path is from the backup 158 ingress PE2 to ingress PE1's next hop (or endpoint) node P1, where 159 the traffic is "merged" into the SR path, and then sent to egress 160 PE3. 162 In another option, the backup path is from the backup ingress PE2 to 163 the egress PE3. When the traffic is imported into the backup path, 164 it is sent to the egress PE3 along the path. 166 4. Behavior after Ingress Failure 168 After failure of the ingress of an SR path happens, there are a 169 couple of different ways to detect the failure. In each way, there 170 may be some specific behavior for the traffic source (e.g., CE1) and 171 the backup ingress (e.g., PE2). 173 In one way, the traffic source (e.g., CE1) is responsible for fast 174 detecting the failure of the ingress (e.g., PE1) of an SR path. Fast 175 detecting the failure means detecting the failure in a few or tens of 176 milliseconds. The backup ingress (e.g., PE2) is ready to import the 177 traffic from the traffic source into the backup SR path installed. 179 In normal operations, the source sends the traffic to the ingress of 180 the SR path. When the source detects the failure of the ingress, it 181 switches the traffic to the backup ingress, which delivers the 182 traffic to the egress of the SR path via the backup SR path. 184 In another way, both the backup ingress and the traffic source are 185 concurrently responsible for fast detecting the failure of the 186 ingress of an SR path. 188 In normal operations, the source (e.g., CE1) sends the traffic to the 189 ingress (e.g., PE1). It switches the traffic to the backup ingress 190 (e.g., PE2) when it detects the failure of the ingress. 192 The backup ingress does not import any traffic from the source into 193 the backup SR path in normal operations. When it detects the failure 194 of the ingress, it imports the traffic from the source into the 195 backup SR path. 197 5. Extensions to PCE 199 PCC runs on each of the edge nodes of a network normally. PCE runs 200 on a server as a controller to communicate with PCCs. PCE and PCCs 201 work together to support protection for the ingress of a SR path. 203 5.1. Capability for SR Path Ingress Protection 205 When a PCE and a PCC establish a PCEP session between them, they 206 exchange their capabilities of supporting protection for the ingress 207 node of an SR path/tunnel. 209 A new sub-TLV called SR_INGRESS_PROTECTION_CAPABILITY is defined. It 210 is included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1 211 (suggested value 2 for backup SR path/tunnel) in the OPEN object, 212 which is exchanged in Open messages when a PCC and a PCE establish a 213 PCEP session between them. Its format is illustrated below. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type = TBD2 | Length=4 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Reserved | Flags |D|A| 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: SR_INGRESS_PROTECTION_CAPABILITY sub-TLV 225 Type: TBD2 is to be assigned by IANA. 227 Length: 4. 229 Reserved: 2 octets. Must be set to zero in transmission and ignored 230 on reception. 232 Flags: 2 octets. Two flags are defined. 234 o D flag: A PCC sets this flag to 1 to indicate that it is able 235 to detect its adjacent node's failure quickly. 237 o A flag: A PCE sets this flag to 1 to request a PCC to let the 238 forwarding entry for the backup SR path/tunnel be Active. 240 A PCC, which supports ingress protection for a SR tunnel/path, sends 241 a PCE an Open message containing SR_INGRESS_PROTECTION_CAPABILITY 242 sub-TLV. This sub-TLV indicates that the PCC is capable of 243 supporting the ingress protection for a SR tunnel/path. 245 A PCE, which supports ingress protection for a SR tunnel/path, sends 246 a PCC an Open message containing SR_INGRESS_PROTECTION_CAPABILITY 247 sub-TLV. This sub-TLV indicates that the PCE is capable of 248 supporting the ingress protection for a SR tunnel/path. 250 Assume that both a PCC and a PCE support SR_PCE_CAPABILITY, that is 251 that each of the Open messages sent by the PCC and PCE contains PATH- 252 SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=1 and a SR- 253 PCE-CAPABILITY sub-TLV. 255 If a PCE receives an Open message without a 256 SR_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE 257 MUST not send the PCC any request for ingress protection of a SR 258 path/tunnel. 260 If a PCC receives an Open message without a 261 SR_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCE, then the PCC 262 MUST ignore any request for ingress protection of a SR path/tunnel 263 from the PCE. 265 If a PCC sets D flag to zero, then the PCE SHOULD send the PCC an 266 Open message with A flag set to one. When the PCE sends the PCC a 267 message for initiating a backup SR path/tunnel, the PCC SHOULD let 268 the forwarding entry for the backup SR path/tunnel be Active. 270 5.2. SR Path Ingress Protection 272 A new sub-TLV called SR_INGRESS_PROTECTION is defined. When a PCE 273 sends a PCC a PCInitiate message for initiating a backup SR path/ 274 tunnel to protect the primary ingress node of a primary SR path/ 275 tunnel, the message contains this TLV in the RP/SRP object. Its 276 format is illustrated below. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type = TBD3 | Length (variable) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Reserved | Flags |A| 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 ~ ~ 286 ~ sub-TLVs (optional) ~ 287 ~ ~ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 3: SR_INGRESS_PROTECTION sub-TLV 292 Type: TBD3 is to be assigned by IANA. 294 Length: Variable. 296 Reserved: 2 octets. Must be set to zero in transmission and ignored 297 on reception. 299 Flags: 2 octets. One flag is defined. 301 o A flag: A PCE sets this flag to 1 to request a PCC to let the 302 forwarding entry for the backup SR path/tunnel be Active. 304 Four optional sub-TLVs are defined. 306 5.2.1. Traffic-Description sub-TLV 308 A Traffic-Description sub-TLV describes the traffic to be imported 309 into a backup SR path/tunnel. Its format is illustrated below. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type = TBD4 | Length (variable) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ ~ 317 ~ sub-TLVs (optional) ~ 318 ~ ~ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 4: Traffic-Description sub-TLV 323 Type: TBD4 is to be assigned by IANA. 325 Length: Variable. 327 Two optional sub-TLVs are defined. One is FEC sub-TLV and the other 328 interface sub-TLV. 330 A FEC sub-TLV describes the traffic to be imported into the backup SR 331 path/tunnel. It is an IP prefix with an optional virtual network ID. 332 It has two formats: one for IPv4 and the other for IPv6, which are 333 illustrated below. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type = TBD5 | Length (variable) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |IPv4 Prefix Len| IPv4 Prefix ~ 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 ~ (Optional) Virtual Network ID (2 octets) ~ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 5: IPv4 FEC sub-TLV 347 Type: TBD5 is to be assigned by IANA. 349 Length: Variable. 351 IPv4 Prefix Len: Indicates the length of the IPv4 Prefix. 353 IPv4 Prefix: IPv4 Prefix rounded to octets. 355 Virtual Network ID: 2 octets. This is optional. It indicates the 356 ID of a virtual network. 358 0 1 2 3 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type = TBD6 | Length (variable) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |IPv6 Prefix Len| IPv6 Prefix ~ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 ~ Optional Virtual Network ID (2 octets) ~ 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 6: IPv6 FEC sub-TLV 370 Type: TBD6 is to be assigned by IANA. 372 Length: Variable. 374 IPv6 Prefix Len: Indicates the length of the IPv6 Prefix. 376 IPv6 Prefix: IPv6 Prefix rounded to octets. 378 Virtual Network ID: 2 octets. This is optional. It indicates the 379 ID of a virtual network. 381 An Interface sub-TLV indicates the interface from which the traffic 382 is received and imported into the backup SR path/tunnel. It has 383 three formats: one for interface index, the other two for IPv4 and 384 IPv6 address, which are illustrated below. 386 0 1 2 3 387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type = TBD7 | Length (4) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Interface Index (4 octets) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 7: Interface Index sub-TLV 396 Type: TBD7 is to be assigned by IANA. 398 Length: 4. 400 Interface Index: 4 octets. It indicates the index of an interface. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type = TBD8 | Length (4) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Interface IPv4 Address (4 octets) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 8: Interface IPv4 Address sub-TLV 412 Type: TBD8 is to be assigned by IANA. 414 Length: 4. 416 Interface IPv4 Address: 4 octets. It represents the IPv4 address of 417 an interface. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = TBD9 | Length (16) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Interface IPv6 Address (16 octets) | 425 ~ ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 9: Interface IPv6 Address sub-TLV 430 Type: TBD9 is to be assigned by IANA. 432 Length: 16. 434 Interface IPv6 Address: 16 octets. It represents the IPv6 address 435 of an interface. 437 5.2.2. Primary-Ingress sub-TLV 439 A Primary-Ingress sub-TLV indicates the IP address of the primary 440 ingress node of a primary SR path/tunnel. It has two formats: one 441 for primary ingress node IPv4 address and the other for primary 442 ingress node IPv6 address, which are illustrated below. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type = TBDa | Length (4) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Primary Ingress IPv4 Address (4 octets) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 10: Primary Ingress IPv4 Address sub-TLV 454 Type: TBDa is to be assigned by IANA. 456 Length: 4. 458 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 459 address of the primary ingress node of a SR path/tunnel. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type = TBDb | Length (16) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Primary Ingress IPv6 Address (16 octets) | 467 ~ ~ 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 11: Primary Ingress IPv6 Address sub-TLV 472 Type: TBDb is to be assigned by IANA. 474 Length: 16. 476 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 477 address of the primary ingress node of a SR path/tunnel. 479 5.2.3. Service sub-TLV 481 A Service sub-TLV contains a service ID or label to be added into a 482 packet to be carried by a SR path/tunnel. It has two formats: one 483 for the service identified by a label and the other for the service 484 identified by a service identifier (ID) of 32 or 128 bits, which are 485 illustrated below. 487 0 1 2 3 488 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type = TBDc | Length (4) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | zero | Service Label (20 bits) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 12: Service Label sub-TLV 497 Type: TBDc is to be assigned by IANA. 499 Length: 4. 501 Service Label: the least significant 20 bits. It represents a label 502 of 20 bits. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type = TBDd | Length (4/16) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Service ID (4 or 16 octets) | 510 ~ ~ 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 13: Service ID sub-TLV 515 Type: TBDd is to be assigned by IANA. 517 Length: 4 or 16. 519 Service ID: 4 or 16 octets. It represents Identifier (ID) of a 520 service in 4 or 16 octets. 522 5.2.4. Downstream-Node sub-TLV 524 A Downstream-Node sub-TLV gives the IP address of the downstream 525 endpoint node of the primary ingress along the primary SR path/ 526 tunnel. It has two formats: one for downstream node IPv4 address and 527 the other for downstream node IPv6 address, which are illustrated 528 below. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type = TBDe | Length (4) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Downstream Node IPv4 Address (4 octets) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 14: Downstream-Node IPv4 Address sub-TLV 540 Type: TBDe is to be assigned by IANA. 542 Length: 4. 544 Downstream Node IPv4 Address: 4 octets. It represents an IPv4 host 545 address of the downstream endpoint node of the primary ingress 546 node of a SR path/tunnel. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type = TBDf | Length (16) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Downstream Node IPv6 Address (16 octets) | 554 ~ ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 15: Downstream-Node IPv6 Address sub-TLV 559 Type: TBDf is to be assigned by IANA. 561 Length: 16. 563 Downstream Node IPv6 Address: 4 octets. It represents an IPv6 host 564 address of the downstream endpoint node of the primary ingress 565 node of a SR path/tunnel. 567 6. IANA Considerations 569 TBD 571 7. Security Considerations 573 TBD 575 8. Acknowledgements 577 TBD 579 9. References 581 9.1. Normative References 583 [I-D.bashandy-isis-srv6-extensions] 584 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 585 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 586 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 587 in progress), March 2019. 589 [I-D.hu-spring-segment-routing-proxy-forwarding] 590 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 591 Path Midpoint Protection", draft-hu-spring-segment- 592 routing-proxy-forwarding-03 (work in progress), April 593 2019. 595 [I-D.ietf-isis-segment-routing-extensions] 596 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 597 Gredler, H., and B. Decraene, "IS-IS Extensions for 598 Segment Routing", draft-ietf-isis-segment-routing- 599 extensions-25 (work in progress), May 2019. 601 [I-D.ietf-ospf-segment-routing-extensions] 602 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 603 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 604 Extensions for Segment Routing", draft-ietf-ospf-segment- 605 routing-extensions-27 (work in progress), December 2018. 607 [I-D.li-ospf-ospfv3-srv6-extensions] 608 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 609 "OSPFv3 Extensions for SRv6", draft-li-ospf- 610 ospfv3-srv6-extensions-03 (work in progress), March 2019. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 618 Scope Link State PDUs (LSPs)", RFC 7356, 619 DOI 10.17487/RFC7356, September 2014, 620 . 622 9.2. Informative References 624 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 625 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 626 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 627 Camarillo, "Topology Independent Fast Reroute using 628 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 629 lfa-05 (work in progress), October 2018. 631 [I-D.hegde-spring-node-protection-for-sr-te-paths] 632 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 633 "Node Protection for SR-TE Paths", draft-hegde-spring- 634 node-protection-for-sr-te-paths-05 (work in progress), 635 July 2019. 637 [I-D.ietf-spring-segment-routing-policy] 638 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 639 bogdanov@google.com, b., and P. Mattes, "Segment Routing 640 Policy Architecture", draft-ietf-spring-segment-routing- 641 policy-03 (work in progress), May 2019. 643 [I-D.sivabalan-pce-binding-label-sid] 644 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 645 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 646 in PCE-based Networks.", draft-sivabalan-pce-binding- 647 label-sid-06 (work in progress), February 2019. 649 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 650 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 651 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 652 2009, . 654 Authors' Addresses 656 Huaimo Chen 657 Futurewei 658 Boston, MA 659 USA 661 Email: Huaimo.chen@futurewei.com 663 Mehmet Toy 664 Verizon 665 USA 667 Email: mehmet.toy@verizon.com 669 Aijun Wang 670 China Telecom 671 Beiqijia Town, Changping District 672 Beijing 102209 673 China 675 Email: wangaj.bri@chinatelecom.cn 677 Zhenqiang Li 678 China Mobile 679 32 Xuanwumen West Ave, Xicheng District 680 Beijing 100053 681 China 683 Email: lizhengqiang@chinamobile.com 684 Lei Liu 685 Fujitsu 686 USA 688 Email: liulei.kddi@gmail.com 690 Xufeng Liu 691 Volta Networks 692 McLean, VA 693 USA 695 Email: xufeng.liu.ietf@gmail.com