idnits 2.17.1 draft-ietf-pce-sr-path-segment-03.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 date (February 8, 2021) is 1172 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-08 == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-00 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-05 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 12, 2021 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 February 8, 2021 13 Path Computation Element Communication Protocol (PCEP) Extension for 14 Path Segment in Segment Routing (SR) 15 draft-ietf-pce-sr-path-segment-03 17 Abstract 19 The Path Computation Element (PCE) provides path computation 20 functions in support of traffic engineering in Multiprotocol Label 21 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 23 The Source Packet Routing in Networking (SPRING) architecture 24 describes how Segment Routing (SR) can be used to steer packets 25 through an IPv6 or MPLS network using the source routing paradigm. A 26 Segment Routed Path can be derived from a variety of mechanisms, 27 including an IGP Shortest Path Tree (SPT), explicit configuration, or 28 a Path Computation Element (PCE). 30 Path identification is needed for several use cases such as 31 performance measurement in Segment Routing (SR) network. This 32 document specifies extensions to the Path Computation Element 33 Communication Protocol (PCEP) to support requesting, replying, 34 reporting and updating the Path Segment ID (Path SID) between PCEP 35 speakers. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 12, 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 74 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 75 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1.1. SR PCE Capability sub-TLV . . . . . . . . . . . . . . 5 78 4.1.2. SRv6 PCE Capability sub-TLV . . . . . . . . . . . . . 6 79 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 7 80 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 82 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 84 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.1. Stateful PCE Operation . . . . . . . . . . . . . . . . . 10 86 5.1.1. Ingress PCC-Initiated Path Segment Allocation . . . . 10 87 5.1.2. PCE Initiated Path Segment Allocation . . . . . . . . 13 88 5.2. PCECC Based Operation . . . . . . . . . . . . . . . . . . 14 89 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 14 90 5.2.2. PCECC based Path Segment Allocation . . . . . . . . . 14 91 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 16 92 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 93 7.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 17 94 7.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 18 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 8.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 97 8.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 98 8.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 19 99 8.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 100 8.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 101 8.5. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 102 8.6. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 104 10. Manageability Considerations . . . . . . . . . . . . . . . . 21 105 10.1. Control of Function and Policy . . . . . . . . . . . . . 21 106 10.2. Information and Data Models . . . . . . . . . . . . . . 21 107 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 21 108 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 21 109 10.5. Requirements On Other Protocols . . . . . . . . . . . . 21 110 10.6. Impact On Network Operations . . . . . . . . . . . . . . 22 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 114 12.2. Informative References . . . . . . . . . . . . . . . . . 24 115 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 118 1. Introduction 120 [RFC5440] describes the Path Computation Element (PCE) Communication 121 Protocol (PCEP). PCEP enables the communication between a Path 122 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 123 purpose of computation of Multiprotocol Label Switching (MPLS) as 124 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 125 Path (TE LSP) characteristics. 127 [RFC8231] specifies a set of extensions to PCEP to enable stateful 128 control of TE LSPs within and across PCEP sessions in compliance with 129 [RFC4657]. It includes mechanisms to effect LSP State 130 Synchronization between PCCs and PCEs, delegation of control over 131 LSPs to PCEs, and PCE control of timing and sequence of path 132 computations within and across PCEP sessions. The model of operation 133 where LSPs are initiated from the PCE is described in [RFC8281]. 135 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 136 procedures and PCEP protocol extensions for using the PCE as the 137 central controller for static LSPs, where LSPs can be provisioned as 138 explicit label instructions at each hop on the end-to-end path. 140 Segment routing (SR) [RFC8402] leverages the source routing and 141 tunneling paradigms and supports steering packets into an explicit 142 forwarding path at the ingress node. 144 An SR path needs to be identified in some use cases such as 145 performance measurement. In order to identify an SR path, SR-MPLS 146 Path Segment is identified in [I-D.ietf-spring-mpls-path-segment] 147 while the SRv6 Path Segment is identified in 148 [I-D.ietf-spring-srv6-path-segment]. 150 [RFC8664] specifies extensions to the Path Computation Element 151 Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE 152 to compute and initiate SR-TE paths, as well as a PCC to request, 153 report or delegate SR paths. 155 [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the 156 procedures and PCEP protocol extensions when a PCE-based controller 157 is also responsible for configuring the forwarding actions on the 158 routers (SR SID distribution in this case), in addition to computing 159 the paths for packet flows in a segment routing network and telling 160 the edge routers what instructions to attach to packets as they enter 161 the network. 163 This document specifies a mechanism to carry the SR path 164 identification information in PCEP messages [RFC5440] [RFC8231] 165 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 166 [I-D.ietf-spring-mpls-path-segment] and SRv6 167 [I-D.ietf-spring-srv6-path-segment], or other IDs that can identify 168 an SR path. This document also extends the PCECC-SR mechanism to 169 inform the Path Segment to the egress PCC. 171 2. Terminology 173 This memo makes use of the terms defined in [RFC4655], [RFC8664], and 174 [RFC8402]. 176 2.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 3. Overview of Path Segment Extensions in PCEP 186 This document specifies a mechanism of allocating Path Segment and 187 extends PCEP to encode it in PCEP messages. For supporting Path 188 Segment in PCEP, several TLVs and flags are defined. The formats of 189 the objects and TLVs are described in Section 4. The procedures of 190 Path Segment allocation are described in Section 5. 192 There are various modes of operations, such as - 194 o The Path Segment can be allocated by Egress PCC. The PCE should 195 request the Path Segment from Egress PCC. 197 o The PCE can allocate a Path Segment on its own accord and inform 198 the ingress/egress PCC, useful for PCE-initiated LSPs. 200 o Ingress PCC can also request PCE to allocate the Path Segment, in 201 this case, the PCE would either allocate and inform the assigned 202 Path Segment to the ingress/egress PCC using PCEP messages, or 203 first request egress PCC for Path Segment and then inform it to 204 the ingress PCC. 206 The path information to the ingress PCC and PCE is exchanged via an 207 extension to [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6]. The 208 Path Segment information (for SR-MPLS) to the egress PCC can be 209 informed via an extension to the PCECC-SR procedures 210 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 212 For the PCE to allocate a Path Segment on its own, the PCE needs to 213 be aware of the MPLS label space from the PCCs. This is done via 214 mechanism as described in [I-D.li-pce-controlled-id-space]. 215 Otherwise, the PCE should request the egress PCC for Path Segment 216 allocation. 218 4. Objects and TLVs 220 4.1. OPEN Object 222 4.1.1. SR PCE Capability sub-TLV 224 [RFC8664] defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY 225 sub-TLV for SR-MPLS. PCEP speakers use this sub-TLV to exchange 226 information about their SR capability. The TLV defines a Flags field 227 [RFC8664]. 229 This document adds an additional flag for Path Segment allocation, as 230 follows - 232 o P (Path Segment Identification bit): A PCEP speaker sets this flag 233 to 1 to indicate that it has the capability to encode SR path 234 identification (Path Segment, as per 235 [I-D.ietf-spring-mpls-path-segment]). 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type=TBD11 | Length=4 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Reserved | Flags |P|N|X| MSD | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 247 The figure is included for the ease of the reader and will be removed 248 at the time of publication. 250 4.1.2. SRv6 PCE Capability sub-TLV 252 [I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type 253 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 254 this sub-TLV to exchange information about their SRv6 capability. 256 This document adds an additional flag for Path Segment allocation, as 257 follows - 259 o P (Path Segment Identification bit): A PCEP speaker sets this flag 260 to 1 to indicate that it has the capability to encode SRv6 Path 261 Segment [I-D.ietf-spring-srv6-path-segment]). 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type=TBD1 | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Reserved | Flags |P| | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 // ... // 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | MSD-Type | MSD-Value | Padding | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV 279 The figure is included for the ease of the reader and can be removed 280 at the time of publication. 282 4.1.3. PCECC-CAPABILITY sub-TLV 284 Along with the SR sub-TLVs, the PCECC Capability as per 285 [I-D.ietf-pce-pcep-extension-pce-controller-sr] should be advertised 286 if the PCE allocates the Path Segment and acts as a Central 287 Controller that manages the Label space. 289 The PCECC Capability should be advertised on the egress PCEP session, 290 along with the SR sub-TLVs. This is needed to ensure that the PCE 291 can use the PCECC objects/mechanism to request/inform the egress PCC 292 of the Path Segment as described in Section 5.2. 294 4.2. LSP Object 296 The LSP Object is defined in Section 7.3 of [RFC8231]. 297 [I-D.ietf-pce-binding-label-sid] defines a new P flag in the LSP 298 object for the PCE-allocated binding label/SID. The same flag can 299 also be used for the Path Segment as described here - 301 o A PCC would set this bit to 1 and include a PATH-SEGMENT TLV in 302 the LSP object to request for allocation of Path Segment by the 303 PCE in the PCEP message. A PCE would also set this bit to 1 and 304 include a PATH-SEGMENT TLV to indicate that the Path Segment is 305 allocated by PCE and encoded in the PCEP message towards PCC. 306 Further, a PCE would set this bit to 0 and include a PATH-SEGMENT 307 TLV in the LSP object to indicate that the Path Segment should be 308 allocated by the PCC as described in Section 5.1.1. 310 4.2.1. Path Segment TLV 312 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 313 Path Segment allocation. The type of this TLV is to be allocated by 314 IANA (TBA4). The format is as shown below. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | ST | Flag |L| Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ (Variable length) Path Segment ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 3: The PATH-SEGMENT TLV Format 328 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 329 length (16-bit) has a variable length. The value contains the 330 following fields: 332 o ST (The Segment type - 8 bits): The ST field specifies the type of 333 the Path Segment field, which carries a Path Segment corresponding 334 to the SR path. 336 * 0: MPLS Path Segment, which is an MPLS label as defined in 337 [I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set 338 to SR (MPLS). 340 * 1: SRv6 Path Segment, which is a 16-octet value as defined in 341 [I-D.ietf-spring-srv6-path-segment]. The PST type MUST be set 342 to SRv6. 344 * 2-255: Reserved for future use. 346 o Flags (8 bits): One flag is currently defined: 348 * L-Bit (Local/Global - 1 bit): If set, then the Path Segment 349 carried by the PATH-SEGMENT TLV has local significance. If not 350 set, then the Path Segment carried by this TLV has global 351 significance (i.e. Path Segment is global within an SR 352 domain). 354 * The unassigned bits MUST be set to 0 and MUST be ignored at 355 receipt. 357 o Reserved (16 bits): MUST be set to 0 and MUST be ignored at 358 receipt. 360 o Path Segment: The Path Segment of an SR path. The Path Segment 361 type is indicated by the ST field. When the ST is 0, it is a MPLS 362 Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label 363 format. When the ST is 1, the path segment is a 16-octet value. 365 In general, only one instance of PATH-SEGMENT TLV will be included in 366 LSP object. If more than one PATH-SEGMENT TLV is included, the first 367 one is processed and others MUST be ignored. Multiple Path Segment 368 allocation for use cases like alternate-making will be considered in 369 future version of this draft. 371 When the Path Segment allocation is enabled, a PATH-SEGMENT TLV MUST 372 be included in the LSP object. 374 If the label space is maintained by PCC itself, and the Path Segment 375 is allocated by Egress PCC, then the PCE should request the Path 376 Segment from Egress PCC as described in Section 5.1.1. In this case, 377 the PCE should send a PCUpdate or PCInitiate message to the egress 378 PCC to request the Path Segment. The P-flag in LSP should be unset 379 in this case. 381 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 382 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 383 node recognizes the TLV but does not support the TLV, it MUST send 384 PCErr with Error-Type = 2 (Capability not supported). 386 4.3. FEC Object 388 The FEC Object [I-D.ietf-pce-pcep-extension-pce-controller-sr] is 389 used to specify the FEC information and carried within PCInitiate or 390 PCRpt message for the PCECC-SR operations. The PCE MUST inform the 391 Path Identification information to the Egress PCC. To do this, this 392 document extends the procedures of 393 [I-D.ietf-pce-pcep-extension-pce-controller-sr] by defining a new FEC 394 object type for Path. 396 FEC Object-Type is TBA6 'Path'. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 // TLV(s) // 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 4: The path FEC object Format 408 One or more following TLV(s) are allowed in the 'path' FEC object - 410 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 411 readable string that identifies an LSP in the network. 413 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 414 SR, but could be used to encode the source, destination and other 415 identification information for the path. 417 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 418 identifier for the PCEP speaker, it is used to identify the 419 Ingress PCC. 421 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 422 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 423 each TLV is processed, if more than one TLV of each type is included, 424 the first one is processed and others MUST be ignored. 426 4.4. CCI Object 428 The Central Control Instructions (CCI) Object is used by the PCE to 429 specify the forwarding instructions is defined in 430 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further 431 [I-D.ietf-pce-pcep-extension-pce-controller-sr] defined a CCI object 432 type for SR. 434 The Path Segment information is encoded directly in the CCI SR 435 object. The Path Segment TLV as described in the Section 4.2.1, MUST 436 also be included in the CCI SR object as the TLV (as it includes 437 additional information regarding the Path Segment identifier). The C 438 flag in CCI object is used to indicate if the allocation needs to be 439 done by the PCC. 441 5. Operations 443 The Path Segment allocation and encoding is as per the Stateful PCE 444 operations for segment routing. The procedures are as per the 445 corresponding extensions defined in [RFC8664] and 446 [I-D.ietf-pce-segment-routing-ipv6] (which are further based on 447 [RFC8231] and [RFC8281]). The additional operations for Path Segment 448 are defined in this section. 450 To notify (or request) the Path Segment to the Egress PCC, the 451 procedures are as per the PCECC-SR 452 [I-D.ietf-pce-pcep-extension-pce-controller-sr] (which is based on 453 [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional 454 operations are defined in this section. 456 5.1. Stateful PCE Operation 458 As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can 459 be allocated by the egress PCC. In this case, the label space is 460 maintained on the PCC itself. 462 This section describes the mechanism of Path Segment allocation by 463 using PCInitiate and PCUpd message in Stateful PCE model. 465 5.1.1. Ingress PCC-Initiated Path Segment Allocation 467 The ingress PCC could request the Path Segment to be allocated by the 468 PCE via PCRpt message. The delegate flag (D-flag) MUST also be set 469 for this LSP. Also, the P-flag in the LSP object MUST be set. 471 On receiving a delegation request with Path Segment allocation 472 request from an ingress PCC, a stateful PCE requests the egress PCC 473 to allocate a Path Segment. 475 The PATH-SEGMENT TLV MUST be included in an LSP object in the 476 PCInitiate message sent from the PCE to the egress to request Path 477 Segment allocation by the egress PCC. The P flag in LSP object MUST 478 be set to 0. This PCInitiate message to egress PCC would be the 479 similar to the one sent to ingress PCC as per [RFC8664], but the 480 egress PCC would only allocate the Path Segment and would not trigger 481 the LSP initiation operation (as it would be the egress for this 482 LSP). 484 If the value of Path Segment is 0x0, it indicates that the PCE is 485 requesting a Path Segment for this LSP. If the Path Segment is set 486 to a value 'n' and the P flag is unset in the LSP object, it 487 indicates that the PCE requests a specific value 'n' of Path Segment. 488 If the Path Segment is allocated successfully, the egress PCC reports 489 the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP 490 object. Else, it MUST send a PCErr message with Error-Type = TBA7 491 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the 492 value of Path Segment is valid, but the PCC is unable to allocate the 493 Path Segment, it MUST send a PCErr message with Error-Type = TBA7 494 ("Path SID failure") and Error Value = 2 ("Unable to allocate the 495 specified label/SID"). 497 Once the PCE receives the PCRpt message, it can obtain the Path 498 Segment information from the egress PCC and then update the path with 499 Path Segment by sending PCUpd message to the ingress PCC. 501 If the Path Segment is updated successfully, the ingress PCC will 502 acknowledge with a PCRpt message to the PCE. In case of error, an 503 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 504 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 505 roll back the Path Segment value to the previous value (if any) by 506 sending a PCUpd message to synchronize with the egress PCC. 508 Ingress Egress 509 +-+-+ +-+-+ +-+-+ 510 |PCC| |PCE| |PCC| 511 +-+-+ +-+-+ +-+-+ 512 1) LSP State | ---- PCRpt ----> | | 513 Delegate | Delegate=1 | | 514 | P=1 |2) PCE update | 515 | | the LSP-DB and | 516 | | request Path SID | 517 | | | 518 | | --- PCInitiate ---> | Egress 519 | | PATH-SEGMENT | allocates 520 | | TLV in LSP | a Path-SID 521 | | | from its 522 | | <----- PCRpt ------ | space 523 | | Path SID | 524 | | | 525 |<---- PCUpd ---- |3)Paths update with | 526 | PATH-SEGMENT TLV | Path SID | 527 | | | 528 4) LSP State | ----- PCRpt ---> | | 529 Report | | | 530 | | | 532 Figure 5: Ingress PCC-Initiated Path Segment Allocation 534 If the ingress PCC wishes to withdraw or modify a previously reported 535 Path Segment value, it MUST send a PCRpt message without any PATH- 536 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 537 Segment respectively. In this case, the PCE should synchronize with 538 egress PCC via PCUpd message. 540 The Path Segment MUST be withdrawn when the corresponding LSP is 541 removed. When the LSP is deleted, the PCE MUST request the egress 542 PCC to withdraw the LSP and associated Path Segment via PCInitiate 543 message with the R flag is set in the SRP object. 545 If an egress PCC receives a valid Path Segment value from a PCE which 546 is different than the current Path Segment, it MUST try to allocate 547 the new value. If the new Path Segment is successfully allocated, 548 the egress PCC MUST report the new value to the PCE. Otherwise, it 549 MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 550 failure") and Error Value = 2 ("Unable to allocate the specified 551 label/SID"). 553 5.1.2. PCE Initiated Path Segment Allocation 555 A stateful PCE also can initiate or update an LSP with Path Segment 556 actively via requesting the egress PCC to allocate a Path Segment. 558 If a PCE wishes to modify a previously requested Path Segment value 559 or allocate a Path Segment for an PCE-Initiated LSP, it MUST request 560 the egress PCC to allocate a new value by sending a PCUpd message to 561 the egress PCC with PATH-SEGMENT TLV containing the new Path Segment 562 value. Also, the P flag in LSP object is unset. Absence of the 563 PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 564 withdraw the Path Segment. 566 The mechanism of requesting Path Segment is as per Section 5.1.1. 568 Once the PCE receives the PCRpt message, it can obtain the Path 569 Segment information from the egress PCC and then update or initiate 570 an LSP with Path Segment. 572 If the SR-Path is setup, the ingress PCC will acknowledge with a 573 PCRpt message to the PCE. In case of error, as described in 574 [RFC8664], an PCErr message will be sent back to the PCE. The PCE 575 MUST request the egress PCC to withdraw the LSP and associated Path 576 Segment via PCInitiate message with the R flag is set in the SRP 577 object. 579 If the Path Segment is updated successfully, the ingress PCC will 580 acknowledge with a PCRpt message to the PCE. In case of error, an 581 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 582 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 583 roll back the Path Segment value to the previous value (if any) by 584 sending a PCUpd message to synchronize with the egress PCC. 586 Ingress Egress 587 +-+-+ +-+-+ +-+-+ 588 |PCC| |PCE| |PCC| 589 +-+-+ +-+-+ +-+-+ 590 1) LSP State | ---- PCRpt ----> | | 591 Delegate if| Delegate=1 | | 592 the LSP exists| |2)PCE actively update| 593 | | the LSP-DB and | 594 | | request Path SID | 595 | | | 596 | | --- PCInitiate ---> | Egress 597 | | PATH-SEGMENT | allocates 598 | | TLV in LSP | a Path-SID 599 | | | from its 600 | | <----- PCRpt ------ | space 601 | | Path SID | 602 | | | 603 |<-- PCUpd/PCInit -- |3)Paths update with | 604 | PATH-SEGMENT TLV | Path SID | 605 | | | 606 4) LSP State | ----- PCRpt ---> | | 607 Report | | | 608 | | | 610 Figure 6: Stateful PCE-Initiated Path Segment Allocation 612 5.2. PCECC Based Operation 614 5.2.1. PCE Controlled Label Spaces Advertisement 616 For allocating the Path Segments to SR paths by the PCEs, the PCE 617 controlled label space MUST be known at PCEs via configurations or 618 any other mechanisms. The PCE controlled label spaces MAY be 619 advertised as described in [I-D.li-pce-controlled-id-space]. 621 5.2.2. PCECC based Path Segment Allocation 623 5.2.2.1. PCECC-Initiated 625 The PCE could allocate the Path Segment on its own for a PCE- 626 Initiated (or delegated LSP). The allocated Path Segment needs to be 627 informed to the Ingress and Egress PCC. The PCE would use the 628 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 629 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 630 The PCE would further inform the egress PCC about the Path Segment 631 allocated by the PCE using the PCInitiate message as described in 632 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 634 Ingress Egress 635 +-+-+ +-+-+ +-+-+ 636 |PCC| |PCE| |PCC| 637 +-+-+ +-+-+ +-+-+ 638 | | | 639 | <--PCInitiate--- |1)Initiate LSP with | 640 | PATH-SEGMENT TLV | Path SID | 641 | | | 642 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 643 | | | 644 |3) PCE informs the | --- PCInitiate ---> | 645 | Path SID to Egress| FEC=Path | 646 | | | 647 | | <-------- PCRpt --- | 648 | | | 650 Figure 7: PCE allocated Path Segment on its own 652 5.2.2.2. Ingress PCC-Initiated PCECC 654 The ingress PCC could request the Path Segment to be allocated by the 655 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 656 MUST also be set for this LSP. Also, the P-flag in the LSP object 657 MUST be set. 659 A PATH-SEGMENT TLV MUST be included in the LSP object. If the value 660 of Path Segment is 0x0, it indicates that the Ingress PCC is 661 requesting a Path Segment for this LSP. If the Path Segment is set 662 to a value 'n', it indicates that the ingress PCC requests a specific 663 value 'n' of Path Segment. 665 If the Path Segment is allocated successfully, the PCE would further 666 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 667 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 668 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 669 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 670 but the PCC is unable to allocate the Path Segment, it MUST send a 671 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 672 Value = 2 ("Unable to allocate the specified label/SID"). 674 The active PCE would allocate the Path Segment as per the PATH- 675 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 676 act based on the local policy. 678 The PCE would further inform the egress PCC about the Path Segment 679 allocated by the PCE using the PCInitiate message as described in 680 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 682 Ingress Egress 683 +-+-+ +-+-+ +-+-+ 684 |PCC| |PCE| |PCC| 685 +-+-+ +-+-+ +-+-+ 686 1) LSP State | ---- PCRpt ----> | | 687 Delegate | Delegate=1 | | 688 | P=1 |2) PCE update | 689 | | the LSP-DB and | 690 | | allocate Path SID | 691 |<---- PCUpd ---- |3)Paths update with | 692 | PATH-SEGMENT TLV | Path SID | 693 | | | 694 4) LSP State Report | ----- PCRpt ---> | | 695 | | | 696 |5) PCE informs the | --- PCInitiate ---> | 697 | Path SID to Egress| FEC=Path | 698 | | | 699 | | <-------- PCRpt --- | 700 | | | 702 Figure 8: Ingress PCC request Path Segment to PCE 704 6. Dataplane Considerations 706 As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS 707 network, when a packet is transmitted along an SR path, the labels in 708 the MPLS label stack will be swapped or popped. So that no label or 709 only the last label may be left in the MPLS label stack when the 710 packet reaches the egress node. Thus, the egress node cannot 711 determine from which SR path the packet comes. For this reason, it 712 introduces the Path Segment. 714 Apart from allocation and encoding of the Path Segment (described in 715 this document) for the LSP, it would also be included in the SID/ 716 Label stack of the LSP (usually for processing by the egress). To 717 support this, the Path Segment MAY also be a part of SR-ERO as 718 prepared by the PCE as per [RFC8664]. The PCC MAY also include the 719 Path Segment while preparing the label stack based on the local 720 policy and use-case. 722 It is important that the PCE learns the Maximum SID Depth (MSD) that 723 can be imposed at each node/link of a given SR path to ensure that 724 the SID stack depth does not exceed the number of SIDs the node is 725 capable of imposing. As a new type of segment, Path Segment will be 726 inserted in the SID list just like other SIDs. Thus, the PCE needs 727 to consider the affect of Path Segment when computing a LSP with Path 728 Segment allocation. 730 Similar to SR-MPLS, when SRv6 Path Segment is implemented, SRv6 731 dataplane is required to be supported on PCCs. 733 7. Implementation Status 735 [Note to the RFC Editor - remove this section before publication, as 736 well as remove the reference to [RFC7942]. 738 This section records the status of known implementations of the 739 protocol defined by this specification at the time of posting of this 740 Internet-Draft, and is based on a proposal described in [RFC7942]. 741 The description of implementations in this section is intended to 742 assist the IETF in its decision processes in progressing drafts to 743 RFCs. Please note that the listing of any individual implementation 744 here does not imply endorsement by the IETF. Furthermore, no effort 745 has been spent to verify the information presented here that was 746 supplied by IETF contributors. This is not intended as, and must not 747 be construed to be, a catalog of available implementations or their 748 features. Readers are advised to note that other implementations may 749 exist. 751 According to [RFC7942], "this will allow reviewers and working groups 752 to assign due consideration to documents that have the benefit of 753 running code, which may serve as evidence of valuable experimentation 754 and feedback that have made the implemented protocols more mature. 755 It is up to the individual working groups to use this information as 756 they see fit". 758 7.1. Huawei's Commercial Delivery 760 The feature of SR-MPLS Path Segment has been developed based on 761 Huawei VRP8. 763 o Organization: Huawei 765 o Implementation: Huawei's Commercial Delivery implementation based 766 on VRP8. 768 o Description: The implementation is under development and follows 769 the mechanism as defined in section-5.1.1. 771 o Maturity Level: Product 773 o Contact: tanren@huawei.com 775 7.2. ZTE's Commercial Delivery 777 The feature of SR-MPLS Path Segment has been developed based on Rosng 778 v8. 780 o Organization: ZTE 782 o Implementation: ZTE's Commercial Delivery implementation based on 783 Rosng v8. 785 o Description: The implementation is under development and follows 786 the mechanism as defined in section-5.1.1. 788 o Maturity Level: Product 790 o Contact: zhan.shuangping@zte.com.cn 792 8. IANA Considerations 794 8.1. SR PCE Capability Flags 796 SR PCE Capability TLV is defined in [RFC8664], and the registry to 797 manage the Flag field of the SR PCE Capability TLV is requested in 798 [RFC8664]. IANA is requested to make the following allocation in the 799 "SR Capability Flag Field" sub-registry. 801 Bit Description Reference 803 TBA1 Path Segment Allocation is supported(P) This document 805 8.2. SRv6 PCE Capability Flags 807 SRv6 PCE Capability TLV is defined in defined in 808 [I-D.ietf-pce-segment-routing-ipv6], and the registry to manage the 809 Flag field of the SRv6 PCE Capability Flags is requested in 810 [I-D.ietf-pce-segment-routing-ipv6]. IANA is requested to make the 811 following allocation in the aforementioned registry. 813 Bit Description Reference 815 TBA2 Path Segment Allocation is supported(P) This document 817 8.3. New LSP Flag Registry 819 [RFC8231] defines the LSP object; per that RFC, IANA created a 820 registry to manage the value of the LSP object's Flag field. IANA 821 has allocated a new bit in the "LSP Object Flag Field" sub-registry, 822 as follows: 824 Bit Description Reference 826 TBA3 Request for Path Segment Allocation(P) This document 828 8.4. New PCEP TLV 830 IANA is requested to add the assignment of a new allocation in the 831 existing "PCEP TLV Type Indicators" sub-registry as follows: 833 Value Description Reference 835 TBA4 PATH-SEGMENT TLV This document 837 8.4.1. Path Segment TLV 839 This document requests that a new sub-registry named "PATH-SEGMENT 840 TLV Segment Type (ST) Field" to be created to manage the value of the 841 ST field in the PATH-SEGMENT TLV. 843 Value Description Reference 845 0 MPLS Path Segment(MPLS label) This document 846 1 SRv6 Path Segment (IPv6 addr) This document 847 2-255 Reserved for future use This document 849 Further, this document also requests that a new sub-registry named 850 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 851 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 852 [RFC8126]. Each bit should be tracked with the following qualities: 854 o Bit number (counting from bit 0 as the most significant bit) 856 o Capability description 858 o Defining RFC 859 Bit Description Reference 861 7 Local Signification(L) This document 863 8.5. New FEC Type Registry 865 A new PCEP object called FEC is defined in 866 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. IANA is requested 867 to allocate a new Object-Type for FEC object in the "PCEP Objects" 868 sub-registry. 870 Value Description Reference 872 TBA6 Path This document 874 8.6. PCEP Error Type and Value 876 IANA is requested to allocate code-points in the "PCEP-ERROR Object 877 Error Types and Values" sub-registry for the following new error- 878 types and error-values: 880 Error-Type Meaning Reference 882 TBA7 Path SID failure: This document 883 Error-value = 1 884 Invalid SID 886 Error-value = 2 887 Unable to allocate 888 Path SID 890 9. Security Considerations 892 The security considerations described in [RFC5440]], [RFC8231], 893 [RFC8281] and [RFC8664] are applicable to this specification. No 894 additional security measure is required. 896 As described [RFC8664] and 897 [I-D.ietf-pce-pcep-extension-for-pce-controller], SR allows a network 898 controller to instantiate and control paths in the network. A rogue 899 PCE can manipulate Path SID allocations to have impact based on the 900 usage of Path SID such as accounting, bi-directional etc. 902 Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions 903 only be activated on authenticated and encrypted sessions across PCEs 904 and PCCs belonging to the same administrative authority, using 905 Transport Layer Security (TLS) [RFC8253], as per the recommendations 906 and best current practices in [RFC7525] (unless explicitly set aside 907 in [RFC8253]). 909 10. Manageability Considerations 911 All manageability requirements and considerations listed in 912 [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions 913 defined in this document. In addition, requirements and 914 considerations listed in this section apply. 916 10.1. Control of Function and Policy 918 A PCEP implementation SHOULD allow the operator to configure the 919 policy based on which it allocates the Path SID. This includes the 920 Path SID scope. 922 10.2. Information and Data Models 924 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In 925 future, this YANG module should be extended or augmented to provide 926 the following additional information relating to Path SID. 928 An implementation SHOULD allow the operator to view the Path SID 929 allocated to the LSP as well as Path SID as part of the computed SID 930 list for the SR path. 932 10.3. Liveness Detection and Monitoring 934 Mechanisms defined in this document do not imply any new liveness 935 detection and monitoring requirements in addition to those already 936 listed in [RFC5440]. 938 10.4. Verify Correct Operations 940 Mechanisms defined in this document do not imply any new operation 941 verification requirements in addition to those already listed in 942 [RFC5440], [RFC8231], and [RFC8664] . 944 10.5. Requirements On Other Protocols 946 Mechanisms defined in this document do not imply any new requirements 947 on other protocols. 949 10.6. Impact On Network Operations 951 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply 952 to PCEP extensions defined in this document. Further, the mechanism 953 described in this document can help the operator to request control 954 of the LSPs at a particular PCE. 956 11. Acknowledgments 958 Many thanks for Jeff Tantsura, Khasanov Boris, Aijun Wang,Loa 959 Andersson,Greg Mirsky,Shunwan Zhuang, Huanan Chen, Fengwei Qin, 960 Julien Meuric's professional comements. Best wishes to them and 961 their families in this special period. 963 12. References 965 12.1. Normative References 967 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 968 Requirement Levels", BCP 14, RFC 2119, 969 DOI 10.17487/RFC2119, March 1997, 970 . 972 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 973 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 974 DOI 10.17487/RFC5440, March 2009, 975 . 977 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 978 Writing an IANA Considerations Section in RFCs", BCP 26, 979 RFC 8126, DOI 10.17487/RFC8126, June 2017, 980 . 982 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 983 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 984 May 2017, . 986 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 987 Computation Element Communication Protocol (PCEP) 988 Extensions for Stateful PCE", RFC 8231, 989 DOI 10.17487/RFC8231, September 2017, 990 . 992 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 993 and D. Dhody, "Optimizations of Label Switched Path State 994 Synchronization Procedures for a Stateful PCE", RFC 8232, 995 DOI 10.17487/RFC8232, September 2017, 996 . 998 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 999 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1000 Path Computation Element Communication Protocol (PCEP)", 1001 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1002 . 1004 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1005 "Recommendations for Secure Use of Transport Layer 1006 Security (TLS) and Datagram Transport Layer Security 1007 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1008 2015, . 1010 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1011 Computation Element Communication Protocol (PCEP) 1012 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1013 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1014 . 1016 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1017 and J. Hardwick, "Path Computation Element Communication 1018 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1019 DOI 10.17487/RFC8664, December 2019, 1020 . 1022 [I-D.ietf-pce-segment-routing-ipv6] 1023 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 1024 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 1025 Routing leveraging the IPv6 data plane", draft-ietf-pce- 1026 segment-routing-ipv6-08 (work in progress), November 2020. 1028 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 1029 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1030 Procedures and Protocol Extensions for Using PCE as a 1031 Central Controller (PCECC) for Segment Routing (SR) MPLS 1032 Segment Identifier (SID) Allocation and Distribution.", 1033 draft-ietf-pce-pcep-extension-pce-controller-sr-00 (work 1034 in progress), December 2020. 1036 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1037 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1038 Procedures and Protocol Extensions for Using PCE as a 1039 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1040 extension-for-pce-controller-10 (work in progress), 1041 January 2021. 1043 [I-D.ietf-spring-mpls-path-segment] 1044 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1045 "Path Segment in MPLS Based Segment Routing Network", 1046 draft-ietf-spring-mpls-path-segment-03 (work in progress), 1047 September 2020. 1049 [I-D.ietf-spring-srv6-path-segment] 1050 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 1051 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 1052 ietf-spring-srv6-path-segment-00 (work in progress), 1053 November 2020. 1055 [I-D.ietf-pce-binding-label-sid] 1056 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1057 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1058 in PCE-based Networks.", draft-ietf-pce-binding-label- 1059 sid-05 (work in progress), October 2020. 1061 12.2. Informative References 1063 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1064 Element (PCE)-Based Architecture", RFC 4655, 1065 DOI 10.17487/RFC4655, August 2006, 1066 . 1068 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1069 Element (PCE) Communication Protocol Generic 1070 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1071 2006, . 1073 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1074 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1075 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1076 July 2018, . 1078 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1079 Code: The Implementation Status Section", BCP 205, 1080 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1081 . 1083 [I-D.li-pce-controlled-id-space] 1084 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1085 Controlled ID Space", draft-li-pce-controlled-id-space-07 1086 (work in progress), October 2020. 1088 [I-D.ietf-pce-pcep-yang] 1089 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1090 YANG Data Model for Path Computation Element 1091 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1092 yang-15 (work in progress), October 2020. 1094 Appendix A. Contributors 1096 The following people have substantially contributed to this document: 1098 Dhruv Dhody 1099 Huawei Technologies 1100 Divyashree Techno Park, Whitefield 1101 Bangalore, Karnataka 560066 1102 India 1104 Email: dhruv.ietf@gmail.com 1106 Jie Dong 1107 Huawei Technologies 1108 Huawei Campus, No. 156 Beiqing Rd. 1109 Beijing 100095 1110 China 1112 Email: jie.dong@huawei.com 1114 Zhenbin Li 1115 Huawei Technologies 1116 Huawei Campus, No. 156 Beiqing Rd. 1117 Beijing 100095 1118 China 1120 Email: lizhenbin@huawei.com 1122 Zafar Ali 1123 Cisco Systems, Inc. 1125 Email: zali@cisco.com 1127 Authors' Addresses 1128 Cheng Li 1129 Huawei Technologies 1130 Huawei Campus, No. 156 Beiqing Rd. 1131 Beijing 100095 1132 China 1134 Email: c.l@huawei.com 1136 Mach(Guoyi) Chen 1137 Huawei Technologies 1138 Huawei Campus, No. 156 Beiqing Rd. 1139 Beijing 100095 1140 China 1142 Email: Mach.chen@huawei.com 1144 Weiqiang Cheng 1145 China Mobile 1146 China 1148 Email: chengweiqiang@chinamobile.com 1150 Rakesh Gandhi 1151 Cisco Systems, Inc. 1152 Canada 1154 Email: rgandhi@cisco.com 1156 Quan Xiong 1157 ZTE Corporation 1158 China 1160 Email: xiong.quan@zte.com.cn