idnits 2.17.1 draft-chen-idr-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 152, but not defined == Missing Reference: 'CE2' is mentioned on line 152, but not defined == Unused Reference: 'RFC7356' is defined on line 489, 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 503, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 532, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-12 == 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-03 == 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 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). 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-idr-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 BGP . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. SR Path Ingress Protection Sub-TLV . . . . . . . . . . . 5 70 5.1.1. Primary Ingress Sub-TLV . . . . . . . . . . . . . . . 6 71 5.1.2. Service Sub-TLV . . . . . . . . . . . . . . . . . . . 7 72 6. Backup Ingress Behavior . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . 10 77 9.2. Ingress Protection Information Sub-TLVs . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Fast protection of a transit node of a Segment Routing (SR) path or 86 tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 87 and [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 or tunnel. 91 This document fills that void and specifies protocol extensions and 92 procedures for fast protection of the ingress node of an SR path. SR 93 path and SR tunnel, Ingress node and ingress as well as fast 94 protection and protection 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 To protect against the failure of the (primary) ingress node of a 139 (primary) SR path, a backup ingress node is configured or selected 140 and is different from the (primary) ingress node. A backup SR path 141 from the backup ingress node is computed and installed. Primary 142 ingress and ingress as well as primary SR path and SR path will be 143 used exchangeably. 145 Figure 1 shows an example of protecting ingress PE1 of a SR path, 146 which is from ingress PE1 to egress PE3. 148 ******* ******* 149 [PE1]-----[P1]-----[PE3] 150 / | |&&&&&&&& | \ PE1 Ingress 151 / | |& | \ CEx Customer Edge 152 [CE1] | |& | [CE2] Px Non-Ingress 153 \ | |& | / *** SR Path 154 \ | &&&&&&&|& | / &&& Backup SR Path 155 [PE2]-----[P2]-----[PE4] 157 Figure 1: Protecting Ingress PE1 of SR Path PE1-P1-PE3 159 In normal operations, CE1 sends the traffic with destination PE3 to 160 ingress PE1, which imports the traffic into the SR path. 162 When CE1 detects the failure of ingress PE1, it switches the traffic 163 to backup ingress PE2, which imports the traffic from CE1 into a 164 backup SR path. The backup path is from the backup ingress PE2 to 165 the egress PE3. When the traffic is imported into the backup path, 166 it is sent to the egress PE3 along the path. 168 4. Behavior after Ingress Failure 170 After the failure of the ingress of an SR path happens, there are a 171 couple of different ways to detect the failure. In each way, there 172 may be some specific behavior for the traffic source (e.g., CE1) and 173 the backup ingress (e.g., PE2). 175 In one way, the traffic source (e.g., CE1) is responsible for fast 176 detecting the failure of the ingress (e.g., PE1) of an SR path. Fast 177 detecting the failure means detecting the failure in a few or tens of 178 milliseconds. The backup ingress (e.g., PE2) is ready to import the 179 traffic from the traffic source into the backup SR path installed. 181 In normal operations, the source sends the traffic to the ingress of 182 the SR path. When the source detects the failure of the ingress, it 183 switches the traffic to the backup ingress, which delivers the 184 traffic to the egress of the SR path via the backup SR path. 186 In another way, the backup ingress is responsible for fast detecting 187 the failure of the ingress of an SR path. 189 In normal operations, the source (e.g., CE1) sends the traffic to the 190 ingress (e.g., PE1) and may send the traffic to the backup ingress 191 (e.g., PE2). It sends the traffic to the backup ingress (e.g., PE2) 192 after the ingress fails. 194 The backup ingress does not import any traffic from the source into 195 the backup SR path in normal operations. When it detects the failure 196 of the ingress, it imports the traffic from the source into the 197 backup SR path. 199 5. Extensions to BGP 201 For a SR path from a primary ingress node to an egress node, a backup 202 ingress node is selected to protect the failure of the primary 203 ingress node of the SR path. This section describes the extensions 204 to BGP for representing the information for protecting the primary 205 ingress node in a BGP UPDATE message and distributing the information 206 to the backup ingress node. The information includes a SR backup 207 path. 209 [I-D.ietf-idr-segment-routing-te-policy] specifies a way of 210 representing a SR path in a BGP UPDATE message and distributing the 211 SR path to the ingress node of the SR path. 213 This is extended to represent the information for protecting the 214 primary ingress by defining a few of new Sub-TLVs. 216 5.1. SR Path Ingress Protection Sub-TLV 218 A new Sub-TLV, called SR Path Ingress Protection Sub-TLV, is defined. 219 When a UPDATE message is sent to the backup ingress node for 220 protecting the primary ingress node of a SR path, the message 221 contains this Sub-TLV. Its format is illustrated below. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type (TBD1) | Length (variable) | Flags |A| 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 ~ ~ 229 ~ Sub-TLVs (optional) ~ 230 ~ ~ 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: SR Path Ingress Protection Sub-TLV 235 Type: TBD1 is to be assigned by IANA. 237 Length: Variable. 239 Flags: 1 octet. One flag is defined. 241 Flag A: 1 bit. It is set to 242 1: request a backup ingress to let the forwarding entry for the 243 backup SR path be Active. 245 0: request a backup ingress to let the forwarding entry for the 246 backup SR path be inactive initially and to make the entry 247 be active after detecting the failure of the primary ingress 248 node of the primary SR path. 250 A couple types of optional Sub-TLVs are defined, which are Primary 251 Ingress Sub-TLV and Service Sub-TLV. 253 5.1.1. Primary Ingress Sub-TLV 255 A Primary Ingress Sub-TLV indicates the IP address of the primary 256 ingress node of a primary SR path. It has two formats: one for 257 primary ingress node IPv4 address and the other for primary ingress 258 node IPv6 address, which are illustrated below. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type (1) | Length (4) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Primary Ingress IPv4 Address (4 octets) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: Primary Ingress IPv4 Address Sub-TLV 270 Type: Its value (1 suggested) is to be assigned by IANA. 272 Length: 4. 274 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 275 address of the primary ingress node of a primary SR path. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type (2) | Length (16) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Primary Ingress IPv6 Address (16 octets) | 283 ~ ~ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 4: Primary Ingress IPv6 Address Sub-TLV 288 Type: Its value (2 suggested) is to be assigned by IANA. 290 Length: 16. 292 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 293 address of the primary ingress node of a primary SR path. 295 5.1.2. Service Sub-TLV 297 A Service Sub-TLV contains a service ID or label to be added into a 298 packet to be carried by a SR path. It has three formats: the first 299 one for the service identified by a label, the second one for the 300 service identified by a service identifier (ID) of 32 bits, and the 301 third one for the service identified by a service identifier (ID) of 302 128 bits. Their formats are illustrated below. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type (3) | Length (4) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | zero | Service Label (20 bits) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 5: Service Label Sub-TLV 314 Type: Its value (3 suggested) is to be assigned by IANA. 316 Length: 4. 318 Service Label: the least significant 20 bits. It represents a label 319 of 20 bits. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type (4) | Length (4) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Service ID (4 octets) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 6: 32 Bits Service ID Sub-TLV 331 Type: Its value (4 suggested) is to be assigned by IANA. 333 Length: 4. 335 Service ID: 4 octets. It represents a Service Identifier (ID) of 32 336 bits. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type (5) | Length (16) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Service ID (16 octets) | 344 ~ ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 7: 128 Bits Service ID Sub-TLV 349 Type: Its value (5 suggested) is to be assigned by IANA. 351 Length: 16. 353 Service ID: 16 octets. It represents a Service Identifier (ID) of 354 128 bits. 356 6. Backup Ingress Behavior 358 When a backup ingress node receives a UPDATE message containing the 359 information for protecting the primary ingress node of a SR path, it 360 installs a forwarding entry in its FIB based on the information. The 361 information is encoded in a SR policy of the following structure: 363 SR Policy SAFI NLRI: 364 Attributes: 365 Tunnel Encaps Attribute (23) 366 Tunnel Type (15): SR Policy 367 SR Path Ingress Protection Sub-TLV 368 Primary Ingress Sub-TLV 369 Service Sub-TLV 370 Preference Sub-TLV 371 Binding SID Sub-TLV 372 Explicit NULL Label Policy (ENLP) Sub-TLV 373 Priority Sub-TLV 374 Policy Name Sub-TLV 375 Segment List Sub-TLV 376 Weight Sub-TLV 377 Segment Sub-TLV 378 Segment Sub-TLV 379 ... 380 ... 382 Where: 384 o SR Policy SAFI NLRI is defined in 385 [I-D.ietf-idr-segment-routing-te-policy]. 387 o Tunnel Encapsulation Attribute is defined in 388 [I-D.ietf-idr-tunnel-encaps]. 390 o Tunnel Type of SR Policy is defined in 391 [I-D.ietf-idr-segment-routing-te-policy]. 393 o SR Path Ingress Protection, Primary Ingress and Service Sub-TLVs 394 are defined in this document. 396 o Preference, Binding SID, ENLP, Priority, Policy Name, Segment 397 List, Weight and Segment Sub-TLVs are defined in 398 [I-D.ietf-idr-segment-routing-te-policy]. 400 After receiving a SR policy with a SR Path Ingress Protection Sub- 401 TLV, the backup ingress node will install one or more candidate paths 402 into its "BGP table". Another module such as SRPM will choose one or 403 more paths and install the forwarding entries for them in the data 404 plane. 406 The forwarding entries for the paths installed in the data plane will 407 be set to be inactive if the flag A in the SR Path Ingress Protection 408 Sub-TLV is zero. When the primary ingress node fails, these 409 forwarding entries are set to be active. The failure of the primary 410 ingress may be detected by the backup ingress node through using a 411 mechanism such as BFD. The IP address of the primary ingress in the 412 Primary Ingress Sub-TLV may be used for detecting the failure of the 413 primary ingress node. 415 If the flag A in the SR Path Ingress Protection Sub-TLV is one, then 416 the forwarding entries for the paths installed in the data plane will 417 be set to be active. 419 When there is a Service Sub-TLV in the SR Path Ingress Protection 420 Sub-TLV, the ID or Label in the Service Sub-TLV will be included in 421 the forwarding entries. When a packet is imported into a backup SR 422 path using the forwarding entries, the service ID or Label is pushed 423 first and then the sequence of segments represented in the Segment 424 List Sub-TLV. 426 7. Security Considerations 428 Protocol extensions defined in this document do not affect the BGP 429 security other than those as discussed in the Security Considerations 430 section of [RFC5575]. 432 8. Acknowledgements 434 TBD 436 9. IANA Considerations 438 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs 440 Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute 441 Sub-TLVs", IANA is requested to assign a new Sub-TLV value for SR 442 Path Ingress Protection as follows: 444 Value sub-TLV Name Reference 445 ----- ------------------------------------ -------------- 446 TBD1 SR Path Ingress Protection Sub-TLV This Document 448 9.2. Ingress Protection Information Sub-TLVs 450 A new registry called "Ingress Protection Information Sub-TLVs" is 451 defined in this document. IANA is requested to create and maintain 452 new registry: 454 o Ingress Protection Information Sub-TLVs 456 Initial values for the registry are given below. The future 457 assignments are to be made through IETF Review [RFC5226]. 459 Value sub-TLV Name Reference 460 ----- ------------------------------------- -------------- 461 0 Reserved 462 1 Primary Ingress IPv4 Address Sub-TLV This Document 463 2 Primary Ingress IPv6 Address Sub-TLV This Document 464 3 Service Label Sub-TLV This Document 465 4 32 Bits Service ID Sub-TLV This Document 466 5 128 Bits Service ID Sub-TLV This Document 467 6-255 Unassigned 469 10. References 471 10.1. Normative References 473 [I-D.ietf-idr-segment-routing-te-policy] 474 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 475 D., and S. Lin, "Advertising Segment Routing Policies in 476 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 477 progress), July 2019. 479 [I-D.ietf-idr-tunnel-encaps] 480 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 481 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 482 tunnel-encaps-12 (work in progress), May 2019. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 490 Scope Link State PDUs (LSPs)", RFC 7356, 491 DOI 10.17487/RFC7356, September 2014, 492 . 494 10.2. Informative References 496 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 497 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 498 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 499 Camarillo, "Topology Independent Fast Reroute using 500 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 501 lfa-05 (work in progress), October 2018. 503 [I-D.hegde-spring-node-protection-for-sr-te-paths] 504 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 505 "Node Protection for SR-TE Paths", draft-hegde-spring- 506 node-protection-for-sr-te-paths-05 (work in progress), 507 July 2019. 509 [I-D.hu-spring-segment-routing-proxy-forwarding] 510 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 511 Path Midpoint Protection", draft-hu-spring-segment- 512 routing-proxy-forwarding-03 (work in progress), April 513 2019. 515 [I-D.ietf-spring-segment-routing-policy] 516 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 517 bogdanov@google.com, b., and P. Mattes, "Segment Routing 518 Policy Architecture", draft-ietf-spring-segment-routing- 519 policy-03 (work in progress), May 2019. 521 [I-D.sivabalan-pce-binding-label-sid] 522 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 523 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 524 in PCE-based Networks.", draft-sivabalan-pce-binding- 525 label-sid-06 (work in progress), February 2019. 527 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 528 IANA Considerations Section in RFCs", RFC 5226, 529 DOI 10.17487/RFC5226, May 2008, 530 . 532 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 533 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 534 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 535 2009, . 537 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 538 and D. McPherson, "Dissemination of Flow Specification 539 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 540 . 542 Authors' Addresses 544 Huaimo Chen 545 Futurewei 546 Boston, MA 547 USA 549 Email: huaimo.chen@futurewei.com 551 Mehmet Toy 552 Verizon 553 USA 555 Email: mehmet.toy@verizon.com 557 Aijun Wang 558 China Telecom 559 Beiqijia Town, Changping District 560 Beijing 102209 561 China 563 Email: wangaj.bri@chinatelecom.cn 565 Zhenqiang Li 566 China Mobile 567 32 Xuanwumen West Ave, Xicheng District 568 Beijing 100053 569 China 571 Email: lizhengqiang@chinamobile.com 572 Lei Liu 573 Fujitsu 574 USA 576 Email: liulei.kddi@gmail.com 578 Xufeng Liu 579 Volta Networks 580 McLean, VA 581 USA 583 Email: xufeng.liu.ietf@gmail.com