idnits 2.17.1 draft-ietf-pce-sr-path-segment-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 February 2022) is 795 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-11 == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-07 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-13 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-09 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-18 Summary: 1 error (**), 0 flaws (~~), 8 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: 18 August 2022 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 14 February 2022 13 Path Computation Element Communication Protocol (PCEP) Extension for 14 Path Segment in Segment Routing (SR) 15 draft-ietf-pce-sr-path-segment-05 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 18 August 2022. 54 Copyright Notice 56 Copyright (c) 2022 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 (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 73 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 74 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1.1. SR PCE Capability sub-TLV . . . . . . . . . . . . . . 5 77 4.1.2. SRv6 PCE Capability sub-TLV . . . . . . . . . . . . . 6 78 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 7 79 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 81 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 82 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.1. Stateful PCE Operation . . . . . . . . . . . . . . . . . 10 85 5.1.1. Ingress PCC-Initiated Path Segment Allocation . . . . 11 86 5.1.2. PCE Initiated Path Segment Allocation . . . . . . . . 13 87 5.2. PCECC Based Operation . . . . . . . . . . . . . . . . . . 14 88 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 14 89 5.2.2. PCECC based Path Segment Allocation . . . . . . . . . 14 90 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 16 91 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 92 7.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 17 93 7.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 18 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 8.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 96 8.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 97 8.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 19 98 8.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 99 8.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 100 8.5. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 101 8.6. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 103 10. Manageability Considerations . . . . . . . . . . . . . . . . 21 104 10.1. Control of Function and Policy . . . . . . . . . . . . . 21 105 10.2. Information and Data Models . . . . . . . . . . . . . . 21 106 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 21 107 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 21 108 10.5. Requirements On Other Protocols . . . . . . . . . . . . 21 109 10.6. Impact On Network Operations . . . . . . . . . . . . . . 21 110 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 113 12.2. Informative References . . . . . . . . . . . . . . . . . 24 114 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 117 1. Introduction 119 [RFC5440] describes the Path Computation Element (PCE) Communication 120 Protocol (PCEP). PCEP enables the communication between a Path 121 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 122 purpose of computation of Multiprotocol Label Switching (MPLS) as 123 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 124 Path (TE LSP) characteristics. 126 [RFC8231] specifies a set of extensions to PCEP to enable stateful 127 control of TE LSPs within and across PCEP sessions in compliance with 128 [RFC4657]. It includes mechanisms to effect LSP State 129 Synchronization between PCCs and PCEs, delegation of control over 130 LSPs to PCEs, and PCE control of timing and sequence of path 131 computations within and across PCEP sessions. The model of operation 132 where LSPs are initiated from the PCE is described in [RFC8281]. 134 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 135 procedures and PCEP protocol extensions for using the PCE as the 136 central controller for static LSPs, where LSPs can be provisioned as 137 explicit label instructions at each hop on the end-to-end path. 139 Segment routing (SR) [RFC8402] leverages the source routing and 140 tunneling paradigms and supports steering packets into an explicit 141 forwarding path at the ingress node. 143 An SR path needs to be identified in some use cases such as 144 performance measurement. In order to identify an SR path, SR-MPLS 145 Path Segment is identified in [I-D.ietf-spring-mpls-path-segment] 146 while the SRv6 Path Segment is identified in 147 [I-D.ietf-spring-srv6-path-segment]. 149 [RFC8664] specifies extensions to the Path Computation Element 150 Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE 151 to compute and initiate SR-TE paths, as well as a PCC to request, 152 report or delegate SR paths. 154 [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the 155 procedures and PCEP protocol extensions when a PCE-based controller 156 is also responsible for configuring the forwarding actions on the 157 routers (SR SID distribution in this case), in addition to computing 158 the paths for packet flows in a segment routing network and telling 159 the edge routers what instructions to attach to packets as they enter 160 the network. 162 This document specifies a mechanism to carry the SR path 163 identification information in PCEP messages [RFC5440] [RFC8231] 164 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 165 [I-D.ietf-spring-mpls-path-segment] and SRv6 166 [I-D.ietf-spring-srv6-path-segment], or other IDs that can identify 167 an SR path. This document also extends the PCECC-SR mechanism to 168 inform the Path Segment to the egress PCC. 170 2. Terminology 172 This memo makes use of the terms defined in [RFC4655], [RFC8664], and 173 [RFC8402]. 175 2.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 3. Overview of Path Segment Extensions in PCEP 185 This document specifies a mechanism of allocating Path Segment and 186 extends PCEP to encode it in PCEP messages. For supporting Path 187 Segment in PCEP, several TLVs and flags are defined. The formats of 188 the objects and TLVs are described in Section 4. The procedures of 189 Path Segment allocation are described in Section 5. 191 There are various modes of operations, such as - 193 * The Path Segment can be allocated by Egress PCC. The PCE should 194 request the Path Segment from Egress PCC. 196 * The PCE can allocate a Path Segment on its own accord and inform 197 the ingress/egress PCC, useful for PCE-initiated LSPs. 199 * Ingress PCC can also request PCE to allocate the Path Segment, in 200 this case, the PCE would either allocate and inform the assigned 201 Path Segment to the ingress/egress PCC using PCEP messages, or 202 first request egress PCC for Path Segment and then inform it to 203 the ingress PCC. 205 The path information to the ingress PCC and PCE is exchanged via an 206 extension to [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6]. The 207 Path Segment information (for SR-MPLS) to the egress PCC can be 208 informed via an extension to the PCECC-SR procedures 209 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 211 For the PCE to allocate a Path Segment on its own, the PCE needs to 212 be aware of the MPLS label space from the PCCs. This is done via 213 mechanism as described in [I-D.li-pce-controlled-id-space]. 214 Otherwise, the PCE should request the egress PCC for Path Segment 215 allocation. 217 4. Objects and TLVs 219 4.1. OPEN Object 221 4.1.1. SR PCE Capability sub-TLV 223 [RFC8664] defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY 224 sub-TLV for SR-MPLS. PCEP speakers use this sub-TLV to exchange 225 information about their SR capability. The TLV defines a Flags field 226 [RFC8664]. 228 This document adds an additional flag for Path Segment allocation, as 229 follows - 231 * P (Path Segment Identification bit): A PCEP speaker sets this flag 232 to 1 to indicate that it has the capability to encode SR path 233 identification (Path Segment, as per 234 [I-D.ietf-spring-mpls-path-segment]). 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type=TBD11 | Length=4 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Reserved | Flags |P|N|X| MSD | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 246 The figure is included for the ease of the reader and will be removed 247 at the time of publication. 249 4.1.2. SRv6 PCE Capability sub-TLV 251 [I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type 252 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 253 this sub-TLV to exchange information about their SRv6 capability. 255 This document adds an additional flag for Path Segment allocation, as 256 follows - 258 * P (Path Segment Identification bit): A PCEP speaker sets this flag 259 to 1 to indicate that it has the capability to encode SRv6 Path 260 Segment [I-D.ietf-spring-srv6-path-segment]). 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type=TBD1 | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Reserved | Flags |P| | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 // ... // 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | MSD-Type | MSD-Value | Padding | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV 278 The figure is included for the ease of the reader and can be removed 279 at the time of publication. 281 4.1.3. PCECC-CAPABILITY sub-TLV 283 Along with the SR sub-TLVs, the PCECC Capability as per 284 [I-D.ietf-pce-pcep-extension-pce-controller-sr] should be advertised 285 if the PCE allocates the Path Segment and acts as a Central 286 Controller that manages the Label space. 288 The PCECC Capability should be advertised on the egress PCEP session, 289 along with the SR sub-TLVs. This is needed to ensure that the PCE 290 can use the PCECC objects/mechanism to request/inform the egress PCC 291 of the Path Segment as described in Section 5.2. 293 4.2. LSP Object 295 The LSP Object is defined in Section 7.3 of [RFC8231]. 296 [I-D.ietf-pce-binding-label-sid] defines a new P flag in the LSP 297 object for the PCE-allocated binding label/SID. The same flag can 298 also be used for the Path Segment as described here - 300 * A PCC would set this bit to 1 and include a PATH-SEGMENT TLV in 301 the LSP object to request for allocation of Path Segment by the 302 PCE in the PCEP message. A PCE would also set this bit to 1 and 303 include a PATH-SEGMENT TLV to indicate that the Path Segment is 304 allocated by PCE and encoded in the PCEP message towards PCC. 305 Further, a PCE would set this bit to 0 and include a PATH-SEGMENT 306 TLV in the LSP object to indicate that the Path Segment should be 307 allocated by the PCC as described in Section 5.1.1. 309 4.2.1. Path Segment TLV 311 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 312 Path Segment allocation. The type of this TLV is to be allocated by 313 IANA (TBA4). The format is as shown below. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | ST | Flag |L| Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ~ (Variable length) Path Segment ~ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 3: The PATH-SEGMENT TLV Format 327 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 328 length (16-bit) has a variable length. The value contains the 329 following fields: 331 * ST (The Segment type - 8 bits): The ST field specifies the type of 332 the Path Segment field, which carries a Path Segment corresponding 333 to the SR path. 335 - 0: MPLS Path Segment, which is an MPLS label as defined in 336 [I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set 337 to SR (MPLS). 339 - 1: SRv6 Path Segment, which is a 16-octet value as defined in 340 [I-D.ietf-spring-srv6-path-segment]. The PST type MUST be set 341 to SRv6. 343 - 2-255: Reserved for future use. 345 * Flags (8 bits): One flag is currently defined: 347 - L-Bit (Local/Global - 1 bit): If set, then the Path Segment 348 carried by the PATH-SEGMENT TLV has local significance. If not 349 set, then the Path Segment carried by this TLV has global 350 significance (i.e. Path Segment is global within an SR 351 domain). 353 - The unassigned bits MUST be set to 0 and MUST be ignored at 354 receipt. 356 * Reserved (16 bits): MUST be set to 0 and MUST be ignored at 357 receipt. 359 * Path Segment: The Path Segment of an SR path. The Path Segment 360 type is indicated by the ST field. When the ST is 0, it is a MPLS 361 Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label 362 format. When the ST is 1, the path segment is a 16-octet value. 364 In general, only one instance of PATH-SEGMENT TLV will be included in 365 LSP object. If more than one PATH-SEGMENT TLV is included, the first 366 one is processed and others MUST be ignored. Multiple Path Segment 367 allocation for use cases like alternate-making will be considered in 368 future version of this draft. 370 When the Path Segment allocation is enabled, a PATH-SEGMENT TLV MUST 371 be included in the LSP object. 373 If the label space is maintained by PCC itself, and the Path Segment 374 is allocated by Egress PCC, then the PCE should request the Path 375 Segment from Egress PCC as described in Section 5.1.1. In this case, 376 the PCE should send a PCUpdate or PCInitiate message to the egress 377 PCC to request the Path Segment. The P-flag in LSP should be unset 378 in this case. 380 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 381 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 382 node recognizes the TLV but does not support the TLV, it MUST send 383 PCErr with Error-Type = 2 (Capability not supported). 385 4.3. FEC Object 387 The FEC Object [I-D.ietf-pce-pcep-extension-pce-controller-sr] is 388 used to specify the FEC information and carried within PCInitiate or 389 PCRpt message for the PCECC-SR operations. The PCE MUST inform the 390 Path Identification information to the Egress PCC. To do this, this 391 document extends the procedures of 392 [I-D.ietf-pce-pcep-extension-pce-controller-sr] by defining a new FEC 393 object type for Path. 395 FEC Object-Type is TBA6 'Path'. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 // TLV(s) // 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 4: The path FEC object Format 407 One or more following TLV(s) are allowed in the 'path' FEC object - 409 * SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 410 readable string that identifies an LSP in the network. 412 * LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 413 SR, but could be used to encode the source, destination and other 414 identification information for the path. 416 * SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 417 identifier for the PCEP speaker, it is used to identify the 418 Ingress PCC. 420 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 421 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 422 each TLV is processed, if more than one TLV of each type is included, 423 the first one is processed and others MUST be ignored. 425 4.4. CCI Object 427 The Central Control Instructions (CCI) Object is used by the PCE to 428 specify the forwarding instructions is defined in 429 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further 430 [I-D.ietf-pce-pcep-extension-pce-controller-sr] defined a CCI object 431 type for SR. 433 The Path Segment information is encoded directly in the CCI SR 434 object. The Path Segment TLV as described in the Section 4.2.1, MUST 435 also be included in the CCI SR object as the TLV (as it includes 436 additional information regarding the Path Segment identifier). The C 437 flag in CCI object is used to indicate if the allocation needs to be 438 done by the PCC. 440 5. Operations 442 The Path Segment allocation and encoding is as per the Stateful PCE 443 operations for segment routing. The procedures are as per the 444 corresponding extensions defined in [RFC8664] and 445 [I-D.ietf-pce-segment-routing-ipv6] (which are further based on 446 [RFC8231] and [RFC8281]). The additional operations for Path Segment 447 are defined in this section. 449 To notify (or request) the Path Segment to the Egress PCC, the 450 procedures are as per the PCECC-SR 451 [I-D.ietf-pce-pcep-extension-pce-controller-sr] (which is based on 452 [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional 453 operations are defined in this section. 455 5.1. Stateful PCE Operation 457 As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can 458 be allocated by the egress PCC. In this case, the label space is 459 maintained on the PCC itself. 461 This section describes the mechanism of Path Segment allocation by 462 using PCInitiate and PCUpd message in Stateful PCE model. 464 5.1.1. Ingress PCC-Initiated Path Segment Allocation 466 The ingress PCC could request the Path Segment to be allocated by the 467 PCE via PCRpt message. The delegate flag (D-flag) MUST also be set 468 for this LSP. Also, the P-flag in the LSP object MUST be set. 470 On receiving a delegation request with Path Segment allocation 471 request from an ingress PCC, a stateful PCE requests the egress PCC 472 to allocate a Path Segment. 474 The PATH-SEGMENT TLV MUST be included in an LSP object in the 475 PCInitiate message sent from the PCE to the egress to request Path 476 Segment allocation by the egress PCC. The P flag in LSP object MUST 477 be set to 0. This PCInitiate message to egress PCC would be the 478 similar to the one sent to ingress PCC as per [RFC8664], but the 479 egress PCC would only allocate the Path Segment and would not trigger 480 the LSP initiation operation (as it would be the egress for this 481 LSP). 483 If the value of Path Segment is 0x0, it indicates that the PCE is 484 requesting a Path Segment for this LSP. If the Path Segment is set 485 to a value 'n' and the P flag is unset in the LSP object, it 486 indicates that the PCE requests a specific value 'n' of Path Segment. 487 If the Path Segment is allocated successfully, the egress PCC reports 488 the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP 489 object. Else, it MUST send a PCErr message with Error-Type = TBA7 490 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the 491 value of Path Segment is valid, but the PCC is unable to allocate the 492 Path Segment, it MUST send a PCErr message with Error-Type = TBA7 493 ("Path SID failure") and Error Value = 2 ("Unable to allocate the 494 specified label/SID"). 496 Once the PCE receives the PCRpt message, it can obtain the Path 497 Segment information from the egress PCC and then update the path with 498 Path Segment by sending PCUpd message to the ingress PCC. 500 If the Path Segment is updated successfully, the ingress PCC will 501 acknowledge with a PCRpt message to the PCE. In case of error, an 502 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 503 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 504 roll back the Path Segment value to the previous value (if any) by 505 sending a PCUpd message to synchronize with the egress PCC. 507 Ingress Egress 508 +-+-+ +-+-+ +-+-+ 509 |PCC| |PCE| |PCC| 510 +-+-+ +-+-+ +-+-+ 511 1) LSP State | ---- PCRpt ----> | | 512 Delegate | Delegate=1 | | 513 | P=1 |2) PCE update | 514 | | the LSP-DB and | 515 | | request Path SID | 516 | | | 517 | | --- PCInitiate ---> | Egress 518 | | PATH-SEGMENT | allocates 519 | | TLV in LSP | a Path-SID 520 | | | from its 521 | | <----- PCRpt ------ | space 522 | | Path SID | 523 | | | 524 |<---- PCUpd ---- |3)Paths update with | 525 | PATH-SEGMENT TLV | Path SID | 526 | | | 527 4) LSP State | ----- PCRpt ---> | | 528 Report | | | 529 | | | 531 Figure 5: Ingress PCC-Initiated Path Segment Allocation 533 If the ingress PCC wishes to withdraw or modify a previously reported 534 Path Segment value, it MUST send a PCRpt message without any PATH- 535 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 536 Segment respectively. In this case, the PCE should synchronize with 537 egress PCC via PCUpd message. 539 The Path Segment MUST be withdrawn when the corresponding LSP is 540 removed. When the LSP is deleted, the PCE MUST request the egress 541 PCC to withdraw the LSP and associated Path Segment via PCInitiate 542 message with the R flag is set in the SRP object. 544 If an egress PCC receives a valid Path Segment value from a PCE which 545 is different than the current Path Segment, it MUST try to allocate 546 the new value. If the new Path Segment is successfully allocated, 547 the egress PCC MUST report the new value to the PCE. Otherwise, it 548 MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 549 failure") and Error Value = 2 ("Unable to allocate the specified 550 label/SID"). 552 5.1.2. PCE Initiated Path Segment Allocation 554 A stateful PCE also can initiate or update an LSP with Path Segment 555 actively via requesting the egress PCC to allocate a Path Segment. 557 If a PCE wishes to modify a previously requested Path Segment value 558 or allocate a Path Segment for an PCE-Initiated LSP, it MUST request 559 the egress PCC to allocate a new value by sending a PCUpd message to 560 the egress PCC with PATH-SEGMENT TLV containing the new Path Segment 561 value. Also, the P flag in LSP object is unset. Absence of the 562 PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 563 withdraw the Path Segment. 565 The mechanism of requesting Path Segment is as per Section 5.1.1. 567 Once the PCE receives the PCRpt message, it can obtain the Path 568 Segment information from the egress PCC and then update or initiate 569 an LSP with Path Segment. 571 If the SR-Path is setup, the ingress PCC will acknowledge with a 572 PCRpt message to the PCE. In case of error, as described in 573 [RFC8664], an PCErr message will be sent back to the PCE. The PCE 574 MUST request the egress PCC to withdraw the LSP and associated Path 575 Segment via PCInitiate message with the R flag is set in the SRP 576 object. 578 If the Path Segment is updated successfully, the ingress PCC will 579 acknowledge with a PCRpt message to the PCE. In case of error, an 580 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 581 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 582 roll back the Path Segment value to the previous value (if any) by 583 sending a PCUpd message to synchronize with the egress PCC. 585 Ingress Egress 586 +-+-+ +-+-+ +-+-+ 587 |PCC| |PCE| |PCC| 588 +-+-+ +-+-+ +-+-+ 589 1) LSP State | ---- PCRpt ----> | | 590 Delegate if| Delegate=1 | | 591 the LSP exists| |2)PCE actively update| 592 | | the LSP-DB and | 593 | | request Path SID | 594 | | | 595 | | --- PCInitiate ---> | Egress 596 | | PATH-SEGMENT | allocates 597 | | TLV in LSP | a Path-SID 598 | | | from its 599 | | <----- PCRpt ------ | space 600 | | Path SID | 601 | | | 602 |<-- PCUpd/PCInit -- |3)Paths update with | 603 | PATH-SEGMENT TLV | Path SID | 604 | | | 605 4) LSP State | ----- PCRpt ---> | | 606 Report | | | 607 | | | 609 Figure 6: Stateful PCE-Initiated Path Segment Allocation 611 5.2. PCECC Based Operation 613 5.2.1. PCE Controlled Label Spaces Advertisement 615 For allocating the Path Segments to SR paths by the PCEs, the PCE 616 controlled label space MUST be known at PCEs via configurations or 617 any other mechanisms. The PCE controlled label spaces MAY be 618 advertised as described in [I-D.li-pce-controlled-id-space]. 620 5.2.2. PCECC based Path Segment Allocation 622 5.2.2.1. PCECC-Initiated 624 The PCE could allocate the Path Segment on its own for a PCE- 625 Initiated (or delegated LSP). The allocated Path Segment needs to be 626 informed to the Ingress and Egress PCC. The PCE would use the 627 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 628 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 629 The PCE would further inform the egress PCC about the Path Segment 630 allocated by the PCE using the PCInitiate message as described in 631 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 633 Ingress Egress 634 +-+-+ +-+-+ +-+-+ 635 |PCC| |PCE| |PCC| 636 +-+-+ +-+-+ +-+-+ 637 | | | 638 | <--PCInitiate--- |1)Initiate LSP with | 639 | PATH-SEGMENT TLV | Path SID | 640 | | | 641 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 642 | | | 643 |3) PCE informs the | --- PCInitiate ---> | 644 | Path SID to Egress| FEC=Path | 645 | | | 646 | | <-------- PCRpt --- | 647 | | | 649 Figure 7: PCE allocated Path Segment on its own 651 5.2.2.2. Ingress PCC-Initiated PCECC 653 The ingress PCC could request the Path Segment to be allocated by the 654 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 655 MUST also be set for this LSP. Also, the P-flag in the LSP object 656 MUST be set. 658 A PATH-SEGMENT TLV MUST be included in the LSP object. If the value 659 of Path Segment is 0x0, it indicates that the Ingress PCC is 660 requesting a Path Segment for this LSP. If the Path Segment is set 661 to a value 'n', it indicates that the ingress PCC requests a specific 662 value 'n' of Path Segment. 664 If the Path Segment is allocated successfully, the PCE would further 665 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 666 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 667 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 668 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 669 but the PCC is unable to allocate the Path Segment, it MUST send a 670 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 671 Value = 2 ("Unable to allocate the specified label/SID"). 673 The active PCE would allocate the Path Segment as per the PATH- 674 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 675 act based on the local policy. 677 The PCE would further inform the egress PCC about the Path Segment 678 allocated by the PCE using the PCInitiate message as described in 679 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 681 Ingress Egress 682 +-+-+ +-+-+ +-+-+ 683 |PCC| |PCE| |PCC| 684 +-+-+ +-+-+ +-+-+ 685 1) LSP State | ---- PCRpt ----> | | 686 Delegate | Delegate=1 | | 687 | P=1 |2) PCE update | 688 | | the LSP-DB and | 689 | | allocate Path SID | 690 |<---- PCUpd ---- |3)Paths update with | 691 | PATH-SEGMENT TLV | Path SID | 692 | | | 693 4) LSP State Report | ----- PCRpt ---> | | 694 | | | 695 |5) PCE informs the | --- PCInitiate ---> | 696 | Path SID to Egress| FEC=Path | 697 | | | 698 | | <-------- PCRpt --- | 699 | | | 701 Figure 8: Ingress PCC request Path Segment to PCE 703 6. Dataplane Considerations 705 As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS 706 network, when a packet is transmitted along an SR path, the labels in 707 the MPLS label stack will be swapped or popped. So that no label or 708 only the last label may be left in the MPLS label stack when the 709 packet reaches the egress node. Thus, the egress node cannot 710 determine from which SR path the packet comes. For this reason, it 711 introduces the Path Segment. 713 Apart from allocation and encoding of the Path Segment (described in 714 this document) for the LSP, it would also be included in the SID/ 715 Label stack of the LSP (usually for processing by the egress). To 716 support this, the Path Segment MAY also be a part of SR-ERO as 717 prepared by the PCE as per [RFC8664]. The PCC MAY also include the 718 Path Segment while preparing the label stack based on the local 719 policy and use-case. 721 It is important that the PCE learns the Maximum SID Depth (MSD) that 722 can be imposed at each node/link of a given SR path to ensure that 723 the SID stack depth does not exceed the number of SIDs the node is 724 capable of imposing. As a new type of segment, Path Segment will be 725 inserted in the SID list just like other SIDs. Thus, the PCE needs 726 to consider the affect of Path Segment when computing a LSP with Path 727 Segment allocation. 729 Similar to SR-MPLS, when SRv6 Path Segment is implemented, SRv6 730 dataplane is required to be supported on PCCs. 732 7. Implementation Status 734 [Note to the RFC Editor - remove this section before publication, as 735 well as remove the reference to [RFC7942]. 737 This section records the status of known implementations of the 738 protocol defined by this specification at the time of posting of this 739 Internet-Draft, and is based on a proposal described in [RFC7942]. 740 The description of implementations in this section is intended to 741 assist the IETF in its decision processes in progressing drafts to 742 RFCs. Please note that the listing of any individual implementation 743 here does not imply endorsement by the IETF. Furthermore, no effort 744 has been spent to verify the information presented here that was 745 supplied by IETF contributors. This is not intended as, and must not 746 be construed to be, a catalog of available implementations or their 747 features. Readers are advised to note that other implementations may 748 exist. 750 According to [RFC7942], "this will allow reviewers and working groups 751 to assign due consideration to documents that have the benefit of 752 running code, which may serve as evidence of valuable experimentation 753 and feedback that have made the implemented protocols more mature. 754 It is up to the individual working groups to use this information as 755 they see fit". 757 7.1. Huawei's Commercial Delivery 759 The feature of SR-MPLS Path Segment has been developed based on 760 Huawei VRP8. 762 * Organization: Huawei 764 * Implementation: Huawei's Commercial Delivery implementation based 765 on VRP8. 767 * Description: The implementation is under development and follows 768 the mechanism as defined in section-5.1.1. 770 * Maturity Level: Product 772 * Contact: tanren@huawei.com 774 7.2. ZTE's Commercial Delivery 776 The feature of SR-MPLS Path Segment has been developed based on Rosng 777 v8. 779 * Organization: ZTE 781 * Implementation: ZTE's Commercial Delivery implementation based on 782 Rosng v8. 784 * Description: The implementation is under development and follows 785 the mechanism as defined in section-5.1.1. 787 * Maturity Level: Product 789 * Contact: zhan.shuangping@zte.com.cn 791 8. IANA Considerations 793 8.1. SR PCE Capability Flags 795 SR PCE Capability TLV is defined in [RFC8664], and the registry to 796 manage the Flag field of the SR PCE Capability TLV is requested in 797 [RFC8664]. IANA is requested to make the following allocation in the 798 "SR Capability Flag Field" sub-registry. 800 Bit Description Reference 802 TBA1 Path Segment Allocation is supported(P) This document 804 8.2. SRv6 PCE Capability Flags 806 SRv6 PCE Capability TLV is defined in defined in 807 [I-D.ietf-pce-segment-routing-ipv6], and the registry to manage the 808 Flag field of the SRv6 PCE Capability Flags is requested in 809 [I-D.ietf-pce-segment-routing-ipv6]. IANA is requested to make the 810 following allocation in the aforementioned registry. 812 Bit Description Reference 814 TBA2 Path Segment Allocation is supported(P) This document 816 8.3. New LSP Flag Registry 818 [RFC8231] defines the LSP object; per that RFC, IANA created a 819 registry to manage the value of the LSP object's Flag field. IANA 820 has allocated a new bit in the "LSP Object Flag Field" sub-registry, 821 as follows: 823 Bit Description Reference 825 TBA3 Request for Path Segment Allocation(P) This document 827 8.4. New PCEP TLV 829 IANA is requested to add the assignment of a new allocation in the 830 existing "PCEP TLV Type Indicators" sub-registry as follows: 832 Value Description Reference 834 TBA4 PATH-SEGMENT TLV This document 836 8.4.1. Path Segment TLV 838 This document requests that a new sub-registry named "PATH-SEGMENT 839 TLV Segment Type (ST) Field" to be created to manage the value of the 840 ST field in the PATH-SEGMENT TLV. 842 Value Description Reference 844 0 MPLS Path Segment(MPLS label) This document 845 1 SRv6 Path Segment (IPv6 addr) This document 846 2-255 Reserved for future use This document 848 Further, this document also requests that a new sub-registry named 849 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 850 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 851 [RFC8126]. Each bit should be tracked with the following qualities: 853 * Bit number (counting from bit 0 as the most significant bit) 855 * Capability description 857 * 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 also should be applied. 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", Work in Progress, 1026 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10 1027 January 2022, . 1030 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 1031 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 1032 "PCEP Procedures and Protocol Extensions for Using PCE as 1033 a Central Controller (PCECC) for Segment Routing (SR) MPLS 1034 Segment Identifier (SID) Allocation and Distribution.", 1035 Work in Progress, Internet-Draft, draft-ietf-pce-pcep- 1036 extension-pce-controller-sr-03, 30 September 2021, 1037 . 1040 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1041 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 1042 "Path Computation Element Communication Protocol (PCEP) 1043 Procedures and Extensions for Using the PCE as a Central 1044 Controller (PCECC) of LSPs", Work in Progress, Internet- 1045 Draft, draft-ietf-pce-pcep-extension-for-pce-controller- 1046 14, 5 March 2021, . 1049 [I-D.ietf-spring-mpls-path-segment] 1050 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1051 "Path Segment in MPLS Based Segment Routing Network", Work 1052 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 1053 segment-07, 20 December 2021, 1054 . 1057 [I-D.ietf-spring-srv6-path-segment] 1058 Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path 1059 Segment for SRv6 (Segment Routing in IPv6)", Work in 1060 Progress, Internet-Draft, draft-ietf-spring-srv6-path- 1061 segment-03, 27 November 2021, 1062 . 1065 [I-D.ietf-pce-binding-label-sid] 1066 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1067 and C. L. (editor), "Carrying Binding Label/Segment 1068 Identifier (SID) in PCE-based Networks.", Work in 1069 Progress, Internet-Draft, draft-ietf-pce-binding-label- 1070 sid-13, 10 February 2022, 1071 . 1074 12.2. Informative References 1076 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1077 Computation Element (PCE)-Based Architecture", RFC 4655, 1078 DOI 10.17487/RFC4655, August 2006, 1079 . 1081 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 1082 Element (PCE) Communication Protocol Generic 1083 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1084 2006, . 1086 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1087 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1088 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1089 July 2018, . 1091 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1092 Code: The Implementation Status Section", BCP 205, 1093 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1094 . 1096 [I-D.li-pce-controlled-id-space] 1097 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1098 Controlled ID Space", Work in Progress, Internet-Draft, 1099 draft-li-pce-controlled-id-space-09, 22 August 2021, 1100 . 1103 [I-D.ietf-pce-pcep-yang] 1104 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1105 "A YANG Data Model for Path Computation Element 1106 Communications Protocol (PCEP)", Work in Progress, 1107 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 1108 2022, . 1111 Appendix A. Contributors 1113 The following people have substantially contributed to this document: 1115 Dhruv Dhody 1116 Huawei Technologies 1117 Divyashree Techno Park, Whitefield 1118 Bangalore, Karnataka 560066 1119 India 1121 Email: dhruv.ietf@gmail.com 1123 Jie Dong 1124 Huawei Technologies 1125 Huawei Campus, No. 156 Beiqing Rd. 1126 Beijing 100095 1127 China 1129 Email: jie.dong@huawei.com 1131 Zhenbin Li 1132 Huawei Technologies 1133 Huawei Campus, No. 156 Beiqing Rd. 1134 Beijing 100095 1135 China 1137 Email: lizhenbin@huawei.com 1139 Zafar Ali 1140 Cisco Systems, Inc. 1142 Email: zali@cisco.com 1144 Authors' Addresses 1146 Cheng Li 1147 Huawei Technologies 1148 Huawei Campus, No. 156 Beiqing Rd. 1149 Beijing 1150 100095 1151 China 1153 Email: c.l@huawei.com 1154 Mach(Guoyi) Chen 1155 Huawei Technologies 1156 Huawei Campus, No. 156 Beiqing Rd. 1157 Beijing 1158 100095 1159 China 1161 Email: Mach.chen@huawei.com 1163 Weiqiang Cheng 1164 China Mobile 1165 China 1167 Email: chengweiqiang@chinamobile.com 1169 Rakesh Gandhi 1170 Cisco Systems, Inc. 1171 Canada 1173 Email: rgandhi@cisco.com 1175 Quan Xiong 1176 ZTE Corporation 1177 China 1179 Email: xiong.quan@zte.com.cn