idnits 2.17.1 draft-ietf-pce-binding-label-sid-16.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 (27 March 2023) is 399 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) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-16 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-21 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-14 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft Ciena Corporation 4 Intended status: Standards Track C. Filsfils 5 Expires: 28 September 2023 Cisco Systems, Inc. 6 J. Tantsura 7 Nvidia 8 S. Previdi 9 C. Li, Ed. 10 Huawei Technologies 11 27 March 2023 13 Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. 14 draft-ietf-pce-binding-label-sid-16 16 Abstract 18 In order to provide greater scalability, network confidentiality, and 19 service independence, Segment Routing (SR) utilizes a Binding Segment 20 Identifier (SID) (called BSID) as described in RFC 8402. It is 21 possible to associate a BSID to an RSVP-TE-signaled Traffic 22 Engineering Label Switched Path or an SR Traffic Engineering path. 23 The BSID can be used by an upstream node for steering traffic into 24 the appropriate TE path to enforce SR policies. This document 25 specifies the concept of binding value, which can be either an MPLS 26 label or Segment Identifier. It further specifies an extension to 27 Path Computation Element (PCE) communication Protocol(PCEP) for 28 reporting the binding value by a Path Computation Client (PCC) to the 29 PCE to support PCE-based Traffic Engineering policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 28 September 2023. 48 Copyright Notice 50 Copyright (c) 2023 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Motivation and Example . . . . . . . . . . . . . . . . . 4 66 1.2. Summary of the Extension . . . . . . . . . . . . . . . . 5 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. SRv6 Endpoint Behavior and SID Structure . . . . . . . . 8 71 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Binding SID in SR-ERO . . . . . . . . . . . . . . . . . . . . 12 73 7. Binding SID in SRv6-ERO . . . . . . . . . . . . . . . . . . . 12 74 8. PCE Allocation of Binding label/SID . . . . . . . . . . . . . 12 75 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 9.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 11. Manageability Considerations . . . . . . . . . . . . . . . . 16 80 11.1. Control of Function and Policy . . . . . . . . . . . . . 17 81 11.2. Information and Data Models . . . . . . . . . . . . . . 17 82 11.3. Liveness Detection and Monitoring . . . . . . . . . . . 17 83 11.4. Verify Correct Operations . . . . . . . . . . . . . . . 17 84 11.5. Requirements On Other Protocols . . . . . . . . . . . . 17 85 11.6. Impact On Network Operations . . . . . . . . . . . . . . 17 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 12.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17 88 12.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . 18 89 12.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.3. PCEP Error Type and Value . . . . . . . . . . . . . . . 19 91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 14.2. Informative References . . . . . . . . . . . . . . . . . 22 95 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 A Path Computation Element (PCE) can compute Traffic Engineering 101 paths (TE paths) through a network where those paths are subject to 102 various constraints. Currently, TE paths are set up using either the 103 RSVP-TE signaling protocol or Segment Routing (SR). We refer to such 104 paths as RSVP-TE paths and SR-TE paths respectively in this document. 106 As per [RFC8402] SR allows a head-end node to steer a packet flow 107 along a given path via a Segment Routing Policy (SR Policy). As per 108 [RFC9256], an SR Policy is a framework that enables the instantiation 109 of an ordered list of segments on a node for implementing a source 110 routing policy with a specific intent for traffic steering from that 111 node. 113 As described in [RFC8402], a Binding Segment Identifier (BSID) is 114 bound to a Segment Routing (SR) Policy, instantiation of which may 115 involve a list of Segment Identifiers (SIDs). Any packets received 116 with an active segment equal to a BSID are steered onto the bound SR 117 Policy. A BSID may be either a local (SR Local Block (SRLB)) or a 118 global (SR Global Block (SRGB)) SID. As per Section 6.4 of [RFC9256] 119 a BSID can also be associated with any type of interface or tunnel to 120 enable the use of a non-SR interface or tunnel as a segment in a SID 121 list. In this document, the term 'binding label/SID' is used to 122 generalize the allocation of binding value for both SR and non-SR 123 paths. 125 [RFC5440] describes the PCEP for communication between a Path 126 Computation Client (PCC) and a PCE or between a pair of PCEs as per 127 [RFC4655]. [RFC8231] specifies extensions to PCEP that allow a PCC 128 to delegate its Label Switched Paths (LSPs) to a stateful PCE. A 129 stateful PCE can then update the state of LSPs delegated to it. 130 [RFC8281] specifies a mechanism allowing a PCE to dynamically 131 instantiate an LSP on a PCC by sending the path and characteristics. 132 This document specifies an extension to PCEP to manage the binding of 133 label/SID that can be applied to SR, RSVP-TE, and other path setup 134 types. 136 [RFC8664] provides a mechanism for a PCE (acting as a network 137 controller) to instantiate SR-TE paths (candidate paths) for an SR 138 Policy onto a head-end node (acting as a PCC) using PCEP. For more 139 information on the SR Policy Architecture, see [RFC9256]. 141 1.1. Motivation and Example 143 A binding label/SID has local significance to the ingress node of the 144 corresponding TE path. When a stateful PCE is deployed for setting 145 up TE paths, a binding label/SID reported from the PCC to the 146 stateful PCE is useful for the purpose of enforcing end-to-end TE/SR 147 policy. A sample Data Center (DC) and IP/MPLS WAN use-case is 148 illustrated in Figure 1 with a multi-domain PCE. In the IP/MPLS WAN, 149 an SR-TE LSP is set up using the PCE. The list of SIDs of the SR-TE 150 LSP is {A, B, C, D}. The gateway node 1 (which is the PCC) allocates 151 a binding SID X and reports it to the PCE. In the MPLS DC network, 152 an end-to-end SR-TE LSP is established. In order for the access node 153 to steer the traffic towards Node-1 and over the SR-TE path in WAN, 154 the PCE passes the SID stack {Y, X} where Y is the node SID of the 155 gateway node-1 to the access node and X is the BSID. In the absence 156 of the BSID X, the PCE would need to pass the SID stack {Y, A, B, C, 157 D} to the access node. This example also illustrates the additional 158 benefit of using the binding label/SID to reduce the number of SIDs 159 imposed by the access nodes with a limited forwarding capacity. 161 SID stack 162 {Y, X} +--------------+ 163 | Multi-domain | 164 _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | 165 | +--------------+ 166 | ^ 167 | | Binding 168 | .-----. | SID (X) .-----. 169 | ( ) | ( ) 170 V .--( )--. | .--( )--. 171 +------+ ( ) +-------+ ( ) +-------+ 172 |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| 173 | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | 174 +------+ ( SR-TE path ) +-------+ ( SR-TE path ) +-------+ 175 '--( )--' Node '--( )--' 176 ( ) SID of ( ) 177 '-----' Node-1 '-----' 178 is Y SIDs for SR-TE LSP: 179 {A, B, C, D} 181 Figure 1: A Sample Use-case of Binding SID 183 Using the extension defined in this document, a PCC could report to 184 the stateful PCE the binding label/SID it allocated via a Path 185 Computation LSP State Report (PCRpt) message. It is also possible 186 for a stateful PCE to request a PCC to allocate a specific binding 187 label/SID by sending a Path Computation LSP Update Request (PCUpd) 188 message. If the PCC can successfully allocate the specified binding 189 value, it reports the binding value to the PCE. Otherwise, the PCC 190 sends an error message to the PCE indicating the cause of the 191 failure. A local policy or configuration at the PCC SHOULD dictate 192 if the binding label/SID needs to be assigned. 194 1.2. Summary of the Extension 196 To implement the needed changes to PCEP, in this document, we 197 introduce a new OPTIONAL TLV that a PCC can use in order to report 198 the binding label/SID associated with a TE LSP, or a PCE to request a 199 PCC to allocate any or a specific binding label/SID value. This TLV 200 is intended for TE LSPs established using RSVP-TE, SR-TE, or any 201 other future method. In the case of SR-TE LSPs, the TLV can carry a 202 binding label (for SR-TE path with MPLS data-plane) or a binding IPv6 203 SID (e.g., IPv6 address for SR-TE paths with IPv6 data-plane). 204 Throughout this document, the term "binding value" means either an 205 MPLS label or a SID. 207 As another way to use the extension specified in this document, to 208 support the PCE-based central controller [RFC8283] operation where 209 the PCE would take responsibility for managing some part of the MPLS 210 label space for each of the routers that it controls, the PCE could 211 directly make the binding label/SID allocation and inform the PCC. 212 See Section 8 for details. 214 In addition to specifying a new TLV, this document specifies how and 215 when a PCC and PCE can use this TLV, how they can allocate a binding 216 label/SID, and associated error handling. 218 2. Requirements Language 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in BCP 223 14 [RFC2119] [RFC8174] when, and only when, they appear in all 224 capitals, as shown here. 226 3. Terminology 228 The following terminologies are used in this document: 230 BSID: Binding Segment Identifier. 232 binding label/SID: a generic term used for the binding segment for 233 both SR and non-SR paths. 235 binding value: a generic term used for the binding segment as it can 236 be encoded in various formats (as per the binding type(BT)). 238 LSP: Label Switched Path. 240 PCC: Path Computation Client. 242 PCEP: Path Computation Element communication Protocol. 244 RSVP-TE: Resource ReserVation Protocol-Traffic Engineering. 246 SID: Segment Identifier. 248 SR: Segment Routing. 250 4. Path Binding TLV 252 The new optional TLV called "TE-PATH-BINDING TLV" (whose format is 253 shown in Figure 2) is defined to carry the binding label/SID for a TE 254 path. This TLV is associated with the LSP object specified in 255 [RFC8231]. This TLV can also be carried in the PCEP-ERROR object 256 [RFC5440] in case of error. Multiple instances of TE-PATH-BINDING 257 TLVs MAY be present in the LSP and PCEP-ERROR object. The type of 258 this TLV is 55 (early allocated by IANA). The length is variable. 260 [Note to RFC Editor: Please remove "(early allocated by IANA)" before 261 publication] 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 = 55 | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | BT | Flags | Reserved | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ Binding Value (variable length) ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: TE-PATH-BINDING TLV 275 TE-PATH-BINDING TLV is a generic TLV such that it is able to carry 276 binding label/SID (i.e. MPLS label or SRv6 SID). It is formatted 277 according to the rules specified in [RFC5440]. The value portion of 278 the TLV comprises: 280 Binding Type (BT): A one-octet field that identifies the type of 281 binding included in the TLV. This document specifies the following 282 BT values: 284 * BT = 0: The binding value is a 20-bit MPLS label value. The TLV 285 is padded to 4-bytes alignment. The Length MUST be set to 7 (the 286 padding is not included in the length, as per [RFC5440] 287 Section 7.1) and the first 20 bits are used to encode the MPLS 288 label value. 290 * BT = 1: The binding value is a 32-bit MPLS label stack entry as 291 per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded. 292 Note that the receiver MAY choose to override TC, S, and TTL 293 values according to its local policy. The Length MUST be set to 294 8. 296 * BT = 2: The binding value is an SRv6 SID with the format of a 297 16-octet IPv6 address, representing the binding SID for SRv6. The 298 Length MUST be set to 20. 300 * BT = 3: The binding value is a 24 octet field, defined in 301 Section 4.1, that contains the SRv6 SID as well as its Behavior 302 and Structure. The Length MUST be set to 28. 304 Section 12.1.1 defines the IANA registry used to maintain all these 305 binding types as well as any future ones. Note that multiple TE- 306 PATH-BINDING TLVs with same or different Binding Types MAY be present 307 for the same LSP. A PCEP speaker could allocate multiple TE-PATH- 308 BINDING TLVs (of the same BT), and use different binding values in 309 different domains or use-cases based on a local policy. 311 Flags: 1 octet of flags. The following flag is defined in the new 312 registry "TE-PATH-BINDING TLV Flag field" as described in 313 Section 12.1.1: 315 0 1 2 3 4 5 6 7 316 +-+-+-+-+-+-+-+-+ 317 |R| | 318 +-+-+-+-+-+-+-+-+ 320 Figure 3: Flags 322 where: 324 * R (Removal - 1 bit): When set, the requesting PCEP peer requires 325 the removal of the binding value for the LSP. When unset, the 326 PCEP peer indicates that the binding value is added or retained 327 for the LSP. This flag is used in the PCRpt and PCUpd messages. 328 It is ignored in other PCEP messages. 330 * The unassigned flags MUST be set to 0 while sending and ignored on 331 receipt. 333 Reserved: MUST be set to 0 while sending and ignored on receipt. 335 Binding Value: A variable-length field, padded with trailing zeros to 336 a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS 337 label. When the BT is 1, the 32 bits represent the MPLS label stack 338 entry as per [RFC3032]. When the BT is 2, the 128 bits represent the 339 SRv6 SID. When the BT is 3, the Binding Value also contains the SRv6 340 Endpoint Behavior and SID Structure, defined in Section 4.1. In this 341 document, the TE-PATH-BINDING TLV is considered to be empty if no 342 Binding Value is present. Note that the length of the TLV would be 4 343 in such a case. 345 4.1. SRv6 Endpoint Behavior and SID Structure 347 This section specifies the format of the Binding Value in the TE- 348 PATH-BINDING TLV when the BT is set to 3 for the SRv6 Binding SIDs 349 [RFC8986]. The format is shown in Figure 4. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 | SRv6 Binding SID (16 octets) | 356 | | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Reserved | Endpoint Behavior | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | LB Length | LN Length | Fun. Length | Arg. Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 4: SRv6 Endpoint Behavior and SID Structure 366 The Binding Value consists of: 368 * SRv6 Binding SID: 16 octets. The 128-bit IPv6 address, 369 representing the binding SID for SRv6. 371 * Reserved: 2 octets. It MUST be set to 0 on transmit and ignored 372 on receipt. 374 * Endpoint Behavior: 2 octets. The Endpoint Behavior code point for 375 this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint 376 Behaviors", created by [RFC8986]. When the field is set with the 377 value 0, the endpoint behavior is considered unknown. 379 * [RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, 380 where a locator (LOC) is encoded in the L most significant bits of 381 the SID, followed by F bits of function (FUNCT) and A bits of 382 arguments (ARG). A locator may be represented as B:N where B is 383 the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by 384 the operator) and N is the identifier of the parent node 385 instantiating the SID called locator node. The following fields 386 are used to advertise the length of each individual part of the 387 SRv6 SID as defined in : 389 - LB Length: 1 octet. SRv6 SID Locator Block length in bits. 391 - LN Length: 1 octet. SRv6 SID Locator Node length in bits. 393 - Function Length: 1 octet. SRv6 SID Function length in bits. 395 - Argument Length: 1 octet. SRv6 SID Arguments length in bits. 397 The total of the locator block, locator node, function, and argument 398 lengths MUST be lower or equal to 128 bits. If this condition is not 399 met, the corresponding TE-PATH-BINDING TLV is considered invalid. 400 Also, if the Endpoint Behavior is found to be unknown or 401 inconsistent, it is considered invalid. A PCErr message with Error- 402 Type = 10 ("Reception of an invalid object") and Error-Value = 37 403 ("Invalid SRv6 SID Structure") MUST be sent in such cases. 405 The SRv6 SID Structure could be used by the PCE for ease of 406 operations and monitoring. For example, this information could be 407 used for validation of SRv6 SIDs being instantiated in the network 408 and checked for conformance to the SRv6 SID allocation scheme chosen 409 by the operator as described in Section 3.2 of [RFC8986]. In the 410 future, PCE could also be used for verification and the automation 411 for securing the SRv6 domain by provisioning filtering rules at SR 412 domain boundaries as described in Section 5 of [RFC8754]. The 413 details of these potential applications are outside the scope of this 414 document. 416 5. Operation 418 The binding value is usually allocated by the PCC and reported to a 419 PCE via a PCRpt message (see Section 8 where PCE does the 420 allocation). If a PCE does not recognize the TE-PATH-BINDING TLV, it 421 would ignore the TLV in accordance with [RFC5440]. If a PCE 422 recognizes the TLV but does not support the TLV, it MUST send a PCErr 423 with Error-Type = 2 (Capability not supported). 425 Multiple TE-PATH-BINDING TLVs are allowed to be present in the same 426 LSP object. This signifies the presence of multiple binding SIDs for 427 the given LSP. In the case of multiple TE-PATH-BINDING TLVs, the 428 existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP 429 object. In case of an error condition, the whole message is rejected 430 and the resulting PCErr message MAY include the offending TE-PATH- 431 BINDING TLV in the PCEP-ERROR object. 433 If a PCE recognizes an invalid binding value (e.g., label value from 434 the reserved MPLS label space), it MUST send a PCErr message with 435 Error-Type = 10 ("Reception of an invalid object") and Error Value = 436 2 ("Bad label value") as specified in [RFC8664]. 438 For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the 439 SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV 440 by setting the BT (Binding Type) to 3. This can enable the sender to 441 have control of the SRv6 Endpoint Behavior and SID Structure. A 442 sender MAY choose to set the BT to 2, in which case the receiving 443 implementation chooses how to interpret the SRv6 Endpoint Behavior 444 and SID Structure according to local policy. 446 If a PCC wishes to withdraw a previously reported binding value, it 447 MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with 448 R flag set to 1. If a PCC wishes to modify a previously reported 449 binding, it MUST withdraw the former binding value (with R flag set 450 in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING 451 TLV containing the new binding value. Note that other instances of 452 TE-PATH-BINDING TLVs that are unchanged MAY also be included. If the 453 unchanged instances are not included, they will remain associated 454 with the LSP. 456 If a PCE requires a PCC to allocate a (or several) specific binding 457 value(s), it may do so by sending a PCUpd or PCInitiate message 458 containing a TE-PATH-BINDING TLV(s). If the value(s) can be 459 successfully allocated, the PCC reports the binding value(s) to the 460 PCE. If the PCC considers the binding value specified by the PCE 461 invalid, it MUST send a PCErr message with Error-Type = TBD2 462 ("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID"). 463 If the binding value is valid, but the PCC is unable to allocate the 464 binding value, it MUST send a PCErr message with Error-Type = TBD2 465 ("Binding label/SID failure") and Error Value = TBD4 ("Unable to 466 allocate the specified binding value"). Note that, in case of an 467 error, the PCC rejects the PCUpd or PCInitiate message in its 468 entirety and can include the offending TE-PATH-BINDING TLV in the 469 PCEP-ERROR object. 471 If a PCE wishes to request the withdrawal of a previously reported 472 binding value, it MUST send a PCUpd message with the specific TE- 473 PATH-BINDING TLV with R flag set to 1. If a PCE wishes to modify a 474 previously requested binding value, it MUST request the withdrawal of 475 the former binding value (with R flag set in the former TE-PATH- 476 BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new 477 binding value. If a PCC receives a PCUpd message with TE-PATH- 478 BINDING TLV where the R flag is set to 1, but either the binding 479 value is missing (empty TE-PATH-BINDING TLV) or the binding value is 480 incorrect, it MUST send a PCErr message with Error-Type = TBD2 481 ("Binding label/SID failure") and Error Value = TBD6 ("Unable to 482 remove the binding value"). 484 In some cases, a stateful PCE may want to request that the PCC 485 allocate a binding value of the PCC's own choosing. It instructs the 486 PCC by sending a PCUpd message containing an empty TE-PATH-BINDING 487 TLV, i.e., no binding value is specified (bringing the Length field 488 of the TLV to 4). A PCE can also request a PCC to allocate a binding 489 value at the time of initiation by sending a PCInitiate message with 490 an empty TE-PATH-BINDING TLV. Only one such instance of empty TE- 491 PATH-BINDING TLV, per BT, SHOULD be included in the LSP object and 492 others ignored on receipt. If the PCC is unable to allocate a new 493 binding value as per the specified BT, it MUST send a PCErr message 494 with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value 495 = TBD5 ("Unable to allocate a new binding label/SID"). 497 As previously noted, if a message contains an invalid TE-PATH-BINDING 498 TLV that leads to an error condition, the whole message is rejected 499 including any other valid instances of TE-PATH-BINDING TLVs, if any. 500 The resulting error message MAY include the offending TE-PATH-BINDING 501 TLV in the PCEP-ERROR object. 503 If a PCC receives a TE-PATH-BINDING TLV in any message other than 504 PCUpd or PCInitiate, it MUST close the corresponding PCEP session 505 with the reason "Reception of a malformed PCEP message" (according to 506 [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in 507 any message other than a PCRpt or if the TE-PATH-BINDING TLV is 508 associated with any object other than an LSP or PCEP-ERROR object, 509 the PCE MUST close the corresponding PCEP session with the reason 510 "Reception of a malformed PCEP message" (according to [RFC5440]). 512 If a TE-PATH-BINDING TLV is absent in the PCRpt message and no 513 binding values were reported before, the PCE MUST assume that the 514 corresponding LSP does not have any binding. Similarly, if TE-PATH- 515 BINDING TLV is absent in the PCUpd message and no binding values were 516 reported before, the PCC's local policy dictates how the binding 517 allocations are made for a given LSP. 519 Note that some binding types have similar information but different 520 binding value formats. For example, BT=(2 or 3) is used for the SRv6 521 SID and BT=(0 or 1) is used for the MPLS Label. In case a PCEP 522 speaker receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID 523 or MPLS Label but different BT values, it MUST send a PCErr message 524 with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value 525 = TBD7 ("Inconsistent binding types"). 527 6. Binding SID in SR-ERO 529 In PCEP messages, LSP route information is carried in the Explicit 530 Route Object (ERO), which consists of a sequence of subobjects. 531 [RFC8664] defines the "SR-ERO subobject" capable of carrying a SID as 532 well as the identity of the node/adjacency (NAI) represented by the 533 SID. The NAI Type (NT) field indicates the type and format of the 534 NAI contained in the SR-ERO. In case of binding SID, the NAI MUST 535 NOT be included and NT MUST be set to zero. [RFC8664] Section 5.2.1 536 specifies bit settings and error handling in the case when NT=0. 538 7. Binding SID in SRv6-ERO 540 [I-D.ietf-pce-segment-routing-ipv6] defines the "SRv6-ERO subobject" 541 for an SRv6 SID. Similarly to SR-ERO (Section 6), the NAI MUST NOT 542 be included and the NT MUST be set to zero. [RFC8664] Section 5.2.1 543 specifies bit settings and error handling in the case when NT=0. 545 8. PCE Allocation of Binding label/SID 547 Section 5 already includes the scenario where a PCE requires a PCC to 548 allocate a specified binding value by sending a PCUpd or PCInitiate 549 message containing a TE-PATH-BINDING TLV. This section specifies an 550 OPTIONAL feature for the PCE to allocate the binding label/SID of its 551 own accord in the case where the PCE also controls the label space of 552 the PCC and can make the label allocation on its own as described in 553 [RFC8283]. Note that the act of requesting a specific binding value 554 (Section 5) is different from the act of allocating a binding label/ 555 SID as described in this section. 557 [RFC8283] introduces the architecture for PCE as a central controller 558 as an extension of the architecture described in [RFC4655] and 559 assumes the continued use of PCEP as the protocol used between PCE 560 and PCC. [RFC9050] specifies the procedures and PCEP extensions for 561 using the PCE as the central controller. It assumes that the 562 exclusive label range to be used by a PCE is known and set on both 563 PCEP peers. A future extension could add the capability to advertise 564 this range via a possible PCEP extension as well (see 565 [I-D.li-pce-controlled-id-space]). 567 When PCECC operations are supported as per [RFC9050], the binding 568 label/SID MAY also be allocated by the PCE itself. Both peers need 569 to exchange the PCECC capability as described in [RFC9050] before the 570 PCE can allocate the binding label/SID on its own. 572 A new P flag in the LSP object [RFC8231] is introduced to indicate 573 that the allocation needs to be made by the PCE. Note that the P 574 flag could be used for other types of allocations (such as path 575 segments [I-D.ietf-pce-sr-path-segment]) in future. 577 * P (PCE-allocation): If the bit is set to 1, it indicates that the 578 PCC requests PCE to make allocations for this LSP. The TE-PATH- 579 BINDING TLV in the LSP object identifies that the allocation is 580 for a binding label/SID. A PCC MUST set this bit to 1 and include 581 a TE-PATH-BINDING TLV in the LSP object if it wishes to request 582 for allocation of binding label/SID by the PCE in the PCEP 583 message. A PCE MUST also set this bit to 1 and include a TE-PATH- 584 BINDING TLV to indicate that the binding label/SID is allocated by 585 PCE and encoded in the PCEP message towards the PCC. Further, if 586 the binding label/SID is allocated by the PCC, the PCE MUST set 587 this bit to 0 and follow the procedure described in Section 5. 589 Note that - 591 * A PCE could allocate the binding label/SID of its own accord for a 592 PCE-initiated or delegated LSP, and inform the PCC in the 593 PCInitiate message or PCUpd message by setting P=1 and including 594 TE-PATH-BINDING TLV in the LSP object. 596 * To let the PCC allocate the binding label/SID, a PCE MUST set P=0 597 and include an empty TE-PATH-BINDING TLV ( i.e., no binding value 598 is specified) in the LSP object in PCInitiate/PCUpd message. 600 * To request that the PCE allocate the binding label/SID, a PCC MUST 601 set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt 602 message. The PCE will attempt to allocate it and respond to the 603 PCC with PCUpd message including the allocated binding label/SID 604 in the TE-PATH-BINDING TLV and P=1, D=1 in the LSP object. If the 605 PCE is unable to allocate, it MUST send a PCErr message with 606 Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = 607 TBD5 ("Unable to allocate a new binding label/SID"). 609 * If one or both speakers (PCE and PCC) have not indicated support 610 and willingness to use the PCEP extensions for the PCECC as per 611 [RFC9050] and a PCEP peer receives P=1 in the LSP object, it MUST: 613 - send a PCErr message with Error-Type=19 (Invalid Operation) and 614 Error-value=16 (Attempted PCECC operations when PCECC 615 capability was not advertised) and 617 - terminate the PCEP session. 619 * A legacy PCEP speaker that does not recognize the P flag in the 620 LSP object would ignore it in accordance with [RFC8231]. 622 It is assumed that the label range to be used by a PCE is known and 623 set on both PCEP peers. The exact mechanism is out of the scope of 624 [RFC9050] or this document. Note that the specific BSID could be 625 from the PCE-controlled or the PCC-controlled label space. The PCE 626 can directly allocate the label from the PCE-controlled label space 627 using P=1 as described above, whereas the PCE can request the 628 allocation of a specific BSID from the PCC-controlled label space 629 with P=0 as described in Section 5. 631 Note that, the P-Flag in the LSP object SHOULD NOT be set to 1 632 without the presence of TE-PATH-BINDING TLV or any other future TLV 633 defined for PCE allocation. On receipt of such an LSP object, the 634 P-Flag is ignored. The presence of TE-PATH-BINDING TLV with P=1 635 indicates the allocation is for the binding label/SID. In the 636 future, some other TLV (such as one defined in 637 [I-D.ietf-pce-sr-path-segment]) could also be used alongside P=1 to 638 indicate allocation of a different attribute. A future document 639 should not attempt to assign semantics to P=1 without limiting its 640 scope that both PCEP peers could agree on. 642 9. Implementation Status 644 [Note to the RFC Editor - remove this section before publication, as 645 well as remove the reference to RFC 7942.] 646 This section records the status of known implementations of the 647 protocol defined by this specification at the time of posting of this 648 Internet-Draft, and is based on a proposal described in [RFC7942]. 649 The description of implementations in this section is intended to 650 assist the IETF in its decision processes in progressing drafts to 651 RFCs. Please note that the listing of any individual implementation 652 here does not imply endorsement by the IETF. Furthermore, no effort 653 has been spent to verify the information presented here that was 654 supplied by IETF contributors. This is not intended as, and must not 655 be construed to be, a catalog of available implementations or their 656 features. Readers are advised to note that other implementations may 657 exist. 659 According to [RFC7942], "this will allow reviewers and working groups 660 to assign due consideration to documents that have the benefit of 661 running code, which may serve as evidence of valuable experimentation 662 and feedback that have made the implemented protocols more mature. 663 It is up to the individual working groups to use this information as 664 they see fit". 666 9.1. Huawei 668 * Organization: Huawei 670 * Implementation: Huawei's Router and Controller 672 * Description: An experimental code-point is used and will be 673 modified to the value allocated in this document. 675 * Maturity Level: Production 677 * Coverage: Full 679 * Contact: c.l@huawei.com 681 9.2. Cisco 683 * Organization: Cisco Systems 685 * Implementation: Head-end and controller. 687 * Description: An experimental code-point is used and will be 688 modified to the value allocated in this document. 690 * Maturity Level: Production 692 * Coverage: Full 693 * Contact: mkoldych@cisco.com 695 10. Security Considerations 697 The security considerations described in [RFC5440], [RFC8231], 698 [RFC8281], [RFC8664], and [RFC9050] are applicable to this 699 specification. No additional security measure is required. 701 As described in [RFC8402] and [RFC8664], SR intrinsically involves an 702 entity (whether head-end or a central network controller) controlling 703 and instantiating paths in the network without the involvement of 704 (other) nodes along those paths. Binding SIDs are in effect 705 shorthand aliases for longer path representations, and the alias 706 expansion is in principle known only by the node that acts on it. In 707 this document, the expansion of the alias is shared between PCC and 708 PCE, and rogue actions by either PCC or PCE could result in shifting 709 or misdirecting traffic in ways that are hard for other nodes to 710 detect. In particular, when a PCE propagates paths of the form {A, 711 B, BSID} to other entities, the BSID values are opaque, and a rogue 712 PCE can substitute a BSID from a different LSP in such paths to move 713 traffic without the recipient of the path knowing the ultimate 714 destination. 716 The case of BT=3 provides additional opportunities for malfeasance, 717 as it purports to convey information about internal SRv6 SID 718 structure. There is no mechanism defined to validate this internal 719 structure information, and mischaracterizing the division of bits 720 into locator block, locator node, function, and argument can result 721 in different interpretation of the bits by PCC and PCE. Most 722 notably, shifting bits into or out of the "argument" is a direct 723 vector for affecting processing, but other attacks are also possible. 725 Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions 726 only be activated on authenticated and encrypted sessions across PCEs 727 and PCCs belonging to the same administrative authority, using 728 Transport Layer Security (TLS) [RFC8253], as per the recommendations 729 and best current practices in BCP195 [RFC9325] (unless explicitly set 730 aside in [RFC8253]). 732 11. Manageability Considerations 734 All manageability requirements and considerations listed in 735 [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions 736 defined in this document. In addition, requirements and 737 considerations listed in this section apply. 739 11.1. Control of Function and Policy 741 A PCC implementation SHOULD allow the operator to configure the 742 policy the PCC needs to apply when allocating the binding label/SID. 744 If BT is set to 2, the operator needs to have local policy set to 745 decide the SID structure and the SRv6 Endpoint Behavior of the BSID. 747 11.2. Information and Data Models 749 The PCEP YANG module [I-D.ietf-pce-pcep-yang] will be extended to 750 include policy configuration for binding label/SID allocation. 752 11.3. Liveness Detection and Monitoring 754 The mechanisms defined in this document do not imply any new liveness 755 detection and monitoring requirements in addition to those already 756 listed in [RFC5440]. 758 11.4. Verify Correct Operations 760 The mechanisms defined in this document do not imply any new 761 operation verification requirements in addition to those already 762 listed in [RFC5440], [RFC8231], and [RFC8664]. 764 11.5. Requirements On Other Protocols 766 The mechanisms defined in this document do not imply any new 767 requirements on other protocols. 769 11.6. Impact On Network Operations 771 The mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also 772 apply to the PCEP extensions defined in this document. 774 12. IANA Considerations 776 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 777 registry. This document requests IANA actions to allocate code 778 points for the protocol elements defined in this document. 780 12.1. PCEP TLV Type Indicators 782 This document defines a new PCEP TLV; IANA is requested to confirm 783 the following early allocations from the "PCEP TLV Type Indicators" 784 subregistry of the PCEP Numbers registry, as follows: 786 +=======+=================+===============+ 787 | Value | Description | Reference | 788 +=======+=================+===============+ 789 +-------+-----------------+---------------+ 790 | 55 | TE-PATH-BINDING | This document | 791 +-------+-----------------+---------------+ 793 Table 1 795 12.1.1. TE-PATH-BINDING TLV 797 IANA is requested to create a new subregistry "TE-PATH-BINDING TLV BT 798 field" to manage the value of the Binding Type field in the TE-PATH- 799 BINDING TLV. Initial values for the subregistry are given below. 800 New values are assigned by Standards Action [RFC8126]. 802 +=======+======================================+===============+ 803 | Value | Description | Reference | 804 +=======+======================================+===============+ 805 +-------+--------------------------------------+---------------+ 806 | 0 | MPLS Label | This document | 807 +-------+--------------------------------------+---------------+ 808 | 1 | MPLS Label Stack Entry | This document | 809 +-------+--------------------------------------+---------------+ 810 | 2 | SRv6 SID | This document | 811 +-------+--------------------------------------+---------------+ 812 | 3 | SRv6 SID with Behavior and Structure | This document | 813 +-------+--------------------------------------+---------------+ 814 | 4-255 | Unassigned | This document | 815 +-------+--------------------------------------+---------------+ 817 Table 2 819 IANA is requested to create a new subregistry "TE-PATH-BINDING TLV 820 Flag field" to manage the Flag field in the TE-PATH-BINDING TLV. New 821 values are to be assigned by Standards Action [RFC8126]. Each bit 822 should be tracked with the following qualities: 824 * Bit number (count from 0 as the most significant bit) 826 * Description 828 * Reference 829 +=====+=============+===============+ 830 | Bit | Description | Reference | 831 +=====+=============+===============+ 832 +-----+-------------+---------------+ 833 | 0 | R (Removal) | This document | 834 +-----+-------------+---------------+ 835 | 1-7 | Unassigned | This document | 836 +-----+-------------+---------------+ 838 Table 3 840 12.2. LSP Object 842 IANA is requested to confirm the early allocation for a new code- 843 point in the "LSP Object Flag Field" sub-registry for the new P flag 844 as follows: 846 +=====+================+===============+ 847 | Bit | Description | Reference | 848 +=====+================+===============+ 849 +-----+----------------+---------------+ 850 | 0 | PCE-allocation | This document | 851 +-----+----------------+---------------+ 853 Table 4 855 12.3. PCEP Error Type and Value 857 This document defines a new Error-type and associated Error-Values 858 for the PCErr message. IANA is requested to allocate new error-type 859 and error-values within the "PCEP-ERROR Object Error Types and 860 Values" subregistry of the PCEP Numbers registry, as follows: 862 +============+================+========================+===========+ 863 | Error-Type | Meaning | Error-value | Reference | 864 +============+================+========================+===========+ 865 +------------+----------------+------------------------+-----------+ 866 | TBD2 | Binding label/ | 0: Unassigned | This | 867 | | SID failure | | document | 868 +------------+----------------+------------------------+-----------+ 869 | | | TBD3: Invalid SID | This | 870 | | | | document | 871 +------------+----------------+------------------------+-----------+ 872 | | | TBD4: Unable to | This | 873 | | | allocate the specified | document | 874 | | | binding value | | 875 +------------+----------------+------------------------+-----------+ 876 | | | TBD5: Unable to | This | 877 | | | allocate a new binding | document | 878 | | | label/SID | | 879 +------------+----------------+------------------------+-----------+ 880 | | | TBD6: Unable to remove | This | 881 | | | the binding value | document | 882 +------------+----------------+------------------------+-----------+ 883 | | | TBD7: Inconsistent | This | 884 | | | binding types | document | 885 +------------+----------------+------------------------+-----------+ 887 Table 5 889 13. Acknowledgements 891 We would like to thank Milos Fabian, Mrinmoy Das, Andrew Stone, Tom 892 Petch, Aijun Wang, Olivier Dugeon, and Adrian Farrel for their 893 valuable comments. 895 Thanks to Julien Meuric for shepherding. Thanks to John Scudder for 896 the AD review. 898 Thanks to Theresa Enghardt for the GENART review. 900 Thanks to Martin Vigoureux, Benjamin Kaduk, Eric Vyncke, Lars Eggert, 901 Murray Kucherawy, and Erik Kline for the IESG reviews. 903 14. References 905 14.1. Normative References 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, 909 DOI 10.17487/RFC2119, March 1997, 910 . 912 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 913 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 914 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 915 . 917 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 918 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 919 DOI 10.17487/RFC5440, March 2009, 920 . 922 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 923 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 924 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 925 2009, . 927 [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, 928 "Recommendations for Secure Use of Transport Layer 929 Security (TLS) and Datagram Transport Layer Security 930 (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 931 2022, . 933 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 934 Code: The Implementation Status Section", BCP 205, 935 RFC 7942, DOI 10.17487/RFC7942, July 2016, 936 . 938 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 939 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 940 May 2017, . 942 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 943 Computation Element Communication Protocol (PCEP) 944 Extensions for Stateful PCE", RFC 8231, 945 DOI 10.17487/RFC8231, September 2017, 946 . 948 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 949 "PCEPS: Usage of TLS to Provide a Secure Transport for the 950 Path Computation Element Communication Protocol (PCEP)", 951 RFC 8253, DOI 10.17487/RFC8253, October 2017, 952 . 954 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 955 Computation Element Communication Protocol (PCEP) 956 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 957 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 958 . 960 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 961 Decraene, B., Litkowski, S., and R. Shakir, "Segment 962 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 963 July 2018, . 965 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 966 and J. Hardwick, "Path Computation Element Communication 967 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 968 DOI 10.17487/RFC8664, December 2019, 969 . 971 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 972 Writing an IANA Considerations Section in RFCs", BCP 26, 973 RFC 8126, DOI 10.17487/RFC8126, June 2017, 974 . 976 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 977 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 978 (SRv6) Network Programming", RFC 8986, 979 DOI 10.17487/RFC8986, February 2021, 980 . 982 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 983 Computation Element Communication Protocol (PCEP) 984 Procedures and Extensions for Using the PCE as a Central 985 Controller (PCECC) of LSPs", RFC 9050, 986 DOI 10.17487/RFC9050, July 2021, 987 . 989 [I-D.ietf-pce-segment-routing-ipv6] 990 Li, C., Negi, M. S., Sivabalan, S., Koldychev, M., 991 Kaladharan, P., and Y. Zhu, "Path Computation Element 992 Communication Protocol (PCEP) Extensions for Segment 993 Routing leveraging the IPv6 dataplane", Work in Progress, 994 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-16, 6 995 March 2023, . 998 14.2. Informative References 1000 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1001 Computation Element (PCE)-Based Architecture", RFC 4655, 1002 DOI 10.17487/RFC4655, August 2006, 1003 . 1005 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1006 Architecture for Use of PCE and the PCE Communication 1007 Protocol (PCEP) in a Network with Central Control", 1008 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1009 . 1011 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1012 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1013 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1014 . 1016 [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, 1017 A., and P. Mattes, "Segment Routing Policy Architecture", 1018 RFC 9256, DOI 10.17487/RFC9256, July 2022, 1019 . 1021 [I-D.ietf-pce-pcep-yang] 1022 Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura, 1023 "A YANG Data Model for Path Computation Element 1024 Communications Protocol (PCEP)", Work in Progress, 1025 Internet-Draft, draft-ietf-pce-pcep-yang-21, 6 March 2023, 1026 . 1029 [I-D.li-pce-controlled-id-space] 1030 Li, C., Shi, H., Wang, A., Cheng, W., and C. Zhou, "Path 1031 Computation Element Communication Protocol (PCEP) 1032 extension to advertise the PCE Controlled Identifier 1033 Space", Work in Progress, Internet-Draft, draft-li-pce- 1034 controlled-id-space-14, 10 November 2022, 1035 . 1038 [I-D.ietf-pce-sr-path-segment] 1039 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1040 "Path Computation Element Communication Protocol (PCEP) 1041 Extension for Path Segment in Segment Routing (SR)", Work 1042 in Progress, Internet-Draft, draft-ietf-pce-sr-path- 1043 segment-07, 20 February 2023, 1044 . 1047 Appendix A. Contributor Addresses 1049 Jonathan Hardwick 1050 Microsoft 1051 United Kingdom 1053 EMail: jonhardwick@microsoft.com 1055 Dhruv Dhody 1056 Huawei Technologies 1057 Divyashree Techno Park, Whitefield 1058 Bangalore, Karnataka 560066 1059 India 1061 EMail: dhruv.ietf@gmail.com 1063 Mahendra Singh Negi 1064 RtBrick India 1065 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 1066 Bangalore, Karnataka 560102 1067 India 1069 EMail: mahend.ietf@gmail.com 1071 Mike Koldychev 1072 Cisco Systems, Inc. 1073 2000 Innovation Drive 1074 Kanata, Ontario K2K 3E8 1075 Canada 1077 Email: mkoldych@cisco.com 1079 Zafar Ali 1080 Cisco Systems, Inc. 1082 Email: zali@cisco.com 1084 Authors' Addresses 1086 Siva Sivabalan 1087 Ciena Corporation 1088 Email: msiva282@gmail.com 1089 Clarence Filsfils 1090 Cisco Systems, Inc. 1091 Pegasus Parc 1092 BRABANT 1831 De kleetlaan 6a 1093 Belgium 1094 Email: cfilsfil@cisco.com 1096 Jeff Tantsura 1097 Nvidia 1098 Email: jefftant.ietf@gmail.com 1100 Stefano Previdi 1101 Huawei Technologies 1102 Email: stefano@previdi.net 1104 Cheng Li (editor) 1105 Huawei Technologies 1106 Huawei Campus, No. 156 Beiqing Rd. 1107 Beijing 1108 100095 1109 China 1110 Email: c.l@huawei.com