PCE Working Group S. Sidor Internet-Draft Z. Ali Intended status: Standards Track Cisco Systems, Inc. Expires: 22 April 2027 C. Li Huawei Technologies M. Koldychev Ciena Corporation 19 October 2026 Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) draft-sidor-pce-binding-label-sid-extensions-04 Abstract The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or the entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic pool if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 April 2027. Sidor, et al. Expires 22 April 2027 [Page 1] Internet-Draft PCEP Binding SID Extensions October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4 4.2. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . . . . 4 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Capability Negotiation and Flag Validation . . . . . . . 5 5.2. PCC Handling of Unavailable Binding Values . . . . . . . 6 5.3. Reporting and Reconciliation of Binding Values . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 6.1. Interoperability with Legacy Implementations . . . . . . 9 6.2. Coexistence with RFC 9604 Procedures . . . . . . . . . . 9 7. Operational Considerations . . . . . . . . . . . . . . . . . 10 7.1. Control of Function and Policy . . . . . . . . . . . . . 10 7.2. Information and Data Models . . . . . . . . . . . . . . . 11 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 7.5. Requirements on Other Protocols . . . . . . . . . . . . . 12 7.6. Fault Management . . . . . . . . . . . . . . . . . . . . 12 7.7. Impact on Network Operations . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. STATEFUL-PCE-CAPABILITY TLV Flag Field . . . . . . . . . 14 9.2. TE-PATH-BINDING TLV Flag Field . . . . . . . . . . . . . 14 9.3. PCEP-ERROR Object Error Types and Values . . . . . . . . 14 9.4. LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Sidor, et al. Expires 22 April 2027 [Page 2] Internet-Draft PCEP Binding SID Extensions October 2026 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document proposes extensions to the Path Computation Element Communication Protocol (PCEP) to enhance the management of Binding Segment Identifiers (SIDs) for Label Switched Paths (LSPs). Specifically, it defines mechanisms for a Path Computation Client (PCC) to handle situations where a Binding SID (BSID) requested by a Path Computation Element (PCE) is unavailable, allowing for fallback allocation and subsequent reporting of the allocated values back to the PCE. The ability for a PCE to specify a Binding SID for an LSP is defined in [RFC9604]. These extensions aim to improve the robustness and flexibility of LSP instantiation and management in PCEP-controlled networks. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker. The PCE-based architecture [RFC4655] originally defined the use of the PCE for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks with Label Switched Paths (LSPs) instantiated using the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol. Over time, support for additional path setup types, such as SRv6, has been introduced [RFC9603]. The term "LSP" is used extensively in PCEP specifications and, in the context of this document, refers to a path of any path setup type, including an SR Policy Candidate Path, which may be a Segment Routing over IPv6 (SRv6) path (still represented using the LSP Object as specified in [RFC8231]). It also uses the term Binding Segment Identifier (BSID), as defined in [RFC9604], which refers to a local label or SID that represents a TE path, such as an SR Policy, an SR-TE LSP, or an RSVP-TE LSP. Sidor, et al. Expires 22 April 2027 [Page 3] Internet-Draft PCEP Binding SID Extensions October 2026 3. Motivation The PCEP provides mechanisms for PCEs to instantiate and manage LSPs on a PCC. A Stateful PCE [RFC8231] can instantiate LSPs on a PCC [RFC8281]. When instantiating a Segment Routing Traffic Engineering (SR-TE) LSP [RFC8664], the PCE may request a specific BSID to be associated with the LSP using the TE-PATH-BINDING Type-Length-Value (TLV) [RFC9604]. A significant operational challenge arises when the BSID requested by the PCE is already in use, falls outside the valid range, or is otherwise unavailable on the PCC. In the current PCEP specification, such a conflict or unavailability typically results in an LSP instantiation failure. This "hard failure" approach can be disruptive, requiring manual steps from an operator or complex retry logic at the PCE, and can have negative impact on automated provisioning capabilities that PCEP aims to provide. It can also lead to entire PCEP messages being rejected, forcing the PCE to re- evaluate and re-initiate the entire LSP setup process. To improve network resilience and operational efficiency, it is desirable to have more flexible mechanisms for handling BSID unavailability scenarios. Instead of failure, a PCC should ideally be able to gracefully handle such situations, for instance, by allocating a Binding SID from its local dynamic pool. Furthermore, the PCE needs to be aware of the actual BSID allocated by the PCC to maintain an accurate view of the network state. This document defines extensions to PCEP to address these operational needs. 4. PCEP Extensions 4.1. STATEFUL-PCE-CAPABILITY TLV A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in Section 5.4 of [RFC8231]. * E (BSID-FALLBACK-CAPABILITY): If set, indicates that the PCEP peer supports the binding value handling extensions defined in this document, including the A, D, and F flags in the TE-PATH-BINDING TLV and the associated procedures for handling an unavailable binding value (fallback to dynamic allocation, keeping the LSP in a down state, and reporting requested versus allocated binding values), as detailed in Section 5. 4.2. TE-PATH-BINDING TLV New flags are proposed in the TE-PATH-BINDING TLV, which was originally defined in Section 4 of [RFC9604]. Sidor, et al. Expires 22 April 2027 [Page 4] Internet-Draft PCEP Binding SID Extensions October 2026 * A (Allocated): If set, indicates that the binding value encoded in the TLV represents an allocated binding value. * D (Down on BSID Unavailability): If set, indicates that the LSP can be created even if the specified binding value is unavailable, but the LSP will be in a down state. * F (Fallback): If set, indicates that a binding value will be allocated from the dynamic pool if the specified binding value is unavailable. These flags apply to all Binding Types (BT) defined for the TE-PATH- BINDING TLV in [RFC9604]. 5. Operation 5.1. Capability Negotiation and Flag Validation The PCEP protocol extensions defined in this document MUST NOT be used unless both PCEP speakers have indicated support for the extensions by setting the E flag (BSID-FALLBACK-CAPABILITY) in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages. A PCEP speaker that has not received the BSID-FALLBACK-CAPABILITY from its peer MUST NOT send any of the elements defined in this document to that peer. The A, D, and F flags in the TE-PATH-BINDING TLV MUST NOT be used unless both PCEP speakers have set the BSID-FALLBACK-CAPABILITY in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages. If a PCEP speaker receives a PCEP message containing the A, D, or F flags in the TE-PATH-BINDING TLV, or any other element specific to these extensions, from a peer that has not advertised the BSID- FALLBACK-CAPABILITY in its OPEN message, the receiving PCEP speaker MUST send a PCErr message with Error-Type 19 (Invalid Operation) and Error-Value TBD8 (Attempted use of BSID fallback extensions when the BSID-FALLBACK-CAPABILITY was not advertised). When a PCE wants to instantiate or update an LSP and suggest a binding value, it includes the TE-PATH-BINDING TLV in the Path Computation LSP Initiate Request (PCInitiate) message [RFC8281] or Path Computation LSP Update Request (PCUpd) message [RFC8231]. The PCE can set the F flag or the D flag in this TLV to control the PCC's behavior in case the requested binding value is unavailable. The F and D flags are mutually exclusive. If a PCEP speaker receives a TE- PATH-BINDING TLV where both the F flag and the D flag are set, the PCEP speaker MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD5 (Mutually exclusive F and D flags are both set). The LSP instantiation or update request associated with this malformed TLV MUST be rejected. Sidor, et al. Expires 22 April 2027 [Page 5] Internet-Draft PCEP Binding SID Extensions October 2026 When both F=0 and D=0, the current behavior as specified in [RFC9604] applies: the LSP instantiation fails if the requested binding value is unavailable. If a PCEP speaker receives a TE-PATH-BINDING TLV with the A flag set in a PCInitiate or PCUpd message, the PCEP speaker MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD6 (A flag incorrectly set by PCE). The LSP instantiation or update request associated with this malformed TLV MUST be rejected. The behaviors controlled by the F flag and the D flag defined in this document apply only when the binding value is allocated by the PCC. They are not applicable when the PCE allocates the binding value itself, as indicated by the PCE-allocation (P) flag in the LSP object [RFC9604]: when the PCE controls the label space and performs the allocation, no PCC-side fallback is needed. Therefore, the F and D flags MUST NOT be set in a TE-PATH-BINDING TLV carried in an LSP object that also has the P flag set. If a PCEP speaker receives a TE-PATH-BINDING TLV with the F or D flag set in an LSP object that has the P flag set, the PCEP speaker MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD7 (F or D flag set together with the PCE-allocation (P) flag). The LSP instantiation or update request associated with this malformed TLV MUST be rejected. 5.2. PCC Handling of Unavailable Binding Values If the PCC receives a TE-PATH-BINDING TLV with the F flag set and the requested binding value is unavailable, the PCC MUST attempt to allocate a new binding value from its dynamic pool. If successful, the LSP is brought up with the new binding value. When the binding value being allocated is an SRv6 SID (Binding Type 2 or 3 as defined in [RFC9604]), dynamic allocation follows the same procedure a PCC already uses when it allocates a binding SID of its own choosing per [RFC9604]: the PCC allocates the SRv6 binding SID from an SRv6 locator configured for dynamic binding-SID allocation and selects the SRv6 Endpoint Behavior and SID Structure according to local policy. The dynamically allocated binding value MUST be of the same Binding Type as the value originally requested by the PCE. When reporting the allocated SRv6 binding SID, the PCC SHOULD use Binding Type 3 so that the selected SRv6 Endpoint Behavior and SID Structure are conveyed to the PCE, as RECOMMENDED in [RFC9604]; Binding Type 2 MAY be used, in which case the PCE interprets them according to local policy. Sidor, et al. Expires 22 April 2027 [Page 6] Internet-Draft PCEP Binding SID Extensions October 2026 If the PCC receives a TE-PATH-BINDING TLV with the D flag set and the requested binding value is unavailable, the PCC MUST instantiate the LSP but keep it in a down state. In this case, the PCC SHOULD include the LSP-ERROR-CODE TLV [RFC8231] with LSP Error Code TBD9 (Requested binding value is unavailable) in the PCRpt message to indicate that the LSP is down because the requested binding value is unavailable. While the LSP is held in the down state for this reason, the PCC MUST monitor the availability of the requested binding value and, once it becomes available, allocate it, bring the LSP up, and report the updated state in a subsequent PCRpt message with the allocated binding value carried in a TE-PATH-BINDING TLV with the A flag set and without the LSP-ERROR-CODE TLV. If the PCC attempts to allocate a binding value from its dynamic pool (when the F flag is set) but the allocation fails due to pool exhaustion or other reasons, the PCC MUST report the LSP in a down state and SHOULD include the LSP-ERROR-CODE TLV [RFC8231] with LSP Error Code TBD9 (Requested binding value is unavailable) in the PCRpt message to indicate the reason for the failure. 5.3. Reporting and Reconciliation of Binding Values In its Path Computation LSP State Report (PCRpt) message [RFC8231], the PCC reports the status of the binding value allocation. If the originally requested binding value and the allocated binding value differ, two instances of the TE-PATH-BINDING TLV MUST be included in the PCRpt message in the following order: * First, a TLV instance with the originally requested binding value with the A flag cleared. * Second, a TLV instance with the actually allocated binding value with the A flag set. The instance carrying the originally requested binding value MUST be encoded before the instance carrying the actually allocated binding value. The A flag remains the authoritative means of identifying which binding value was allocated. For example, if the PCE requested BSID value 100 with the F flag set, but value 100 was unavailable and the PCC allocated BSID value 200 from its dynamic pool, the PCRpt message would contain: * TE-PATH-BINDING TLV with binding value 100, A flag = 0, F flag = 1 * TE-PATH-BINDING TLV with binding value 200, A flag = 1, F flag = 1 This allows the PCE to correlate what it requested with what was actually allocated. Sidor, et al. Expires 22 April 2027 [Page 7] Internet-Draft PCEP Binding SID Extensions October 2026 PCE PCC | | | PCInitiate | | TE-PATH-BINDING (BSID=100, F=1, A=0) | | --------------------------------------------------> | | | | BSID 100 unavailable on the PCC; | | PCC allocates BSID 200 from its | | local dynamic pool | | | | PCRpt (LSP operational state = UP) | | TE-PATH-BINDING (BSID=100, F=1, A=0) | | TE-PATH-BINDING (BSID=200, F=1, A=1) | | <-------------------------------------------------- | | | | PCE correlates requested BSID 100 with the | | allocated BSID 200 | | | PCE PCC Figure 1: Message flow for LSP creation when a BSID conflict occurs (F flag set) If the requested binding value was successfully allocated, only a single instance of the TE-PATH-BINDING TLV with the A flag set MUST be included in the PCEP message. Reporting both the originally requested binding value (with the A flag cleared) and the allocated fallback binding value (with the A flag set) allows the PCE to reconcile its intent with the state on the PCC. The PCE has two options: * Accept the fallback binding value: the PCE adopts the allocated binding value as the intended value for the LSP and requests that value in subsequent PCUpd or PCInitiate messages. The requested and allocated binding values then match, a single TE-PATH-BINDING TLV with the A flag set is reported, and the binding value does not change unless the PCE later requests a different value. * Retain the originally requested binding value as preferred: the PCE continues to request the originally requested binding value (e.g., BSID 100 in the example above). While that value remains unavailable, the PCC keeps the LSP on the fallback binding value and continues to report both binding values. When the originally requested binding value becomes available, the PCC allocates it, migrates the LSP to it, and reports the updated allocation. To avoid traffic loss, this migration SHOULD be performed in a make- before-break manner, installing the originally requested binding value before removing the fallback binding value. Sidor, et al. Expires 22 April 2027 [Page 8] Internet-Draft PCEP Binding SID Extensions October 2026 Thus, whether the binding value is realigned to the originally requested value is controlled by the PCE through the value it requests: the PCC honors the currently requested binding value and reclaims it as soon as it becomes available, whereas a PCE that prefers to keep the fallback binding value adopts it as the requested value. For PCC-initiated LSPs, the PCC MAY set the F or D flags in the TE- PATH-BINDING TLV included in PCRpt messages to indicate the desired fallback behavior for the binding value. For PCE-initiated LSPs, the PCC MUST reflect the D and F flag values from the PCE's PCInitiate or PCUpd message in all TE-PATH-BINDING TLV instances included in PCRpt messages. This reflection ensures that the binding value allocation policy is propagated to all PCEs in redundant PCE deployments. 6. Backward Compatibility This section describes how the extensions defined in this document interoperate with implementations of [RFC9604] that do not support them, and how they coexist with mechanisms already defined in [RFC9604]. As these extensions operate on the TE-PATH-BINDING TLV carried in the LSP object, they apply to the stateful PCE model [RFC8231] [RFC8281], consistent with [RFC9604]. 6.1. Interoperability with Legacy Implementations The extensions defined in this document are backward compatible with implementations of [RFC9604] that do not support the BSID-FALLBACK- CAPABILITY. A PCEP speaker makes use of the A, D, and F flags and the associated fallback procedures only when both PCEP speakers have advertised the BSID-FALLBACK-CAPABILITY (E flag) in the STATEFUL-PCE- CAPABILITY TLV, as described in Section 5. If either PCEP speaker has not advertised the BSID-FALLBACK- CAPABILITY, the behavior specified in [RFC9604] applies unchanged, and a binding value that is unavailable on the PCC results in the failure behavior defined therein. This ensures that the introduction of these extensions does not affect existing deployments. 6.2. Coexistence with RFC 9604 Procedures Preserved default behavior: Even when the BSID-FALLBACK-CAPABILITY has been negotiated, the procedures of [RFC9604] apply unchanged whenever neither the F flag nor the D flag is set (F=0, D=0). In particular, if the requested binding value is unavailable, the PCC rejects the request as specified in [RFC9604], reporting Error-Type 32 (Binding label/SID failure) with Error-value 2 (Unable to allocate the specified binding value). The F and D flags only modify this Sidor, et al. Expires 22 April 2027 [Page 9] Internet-Draft PCEP Binding SID Extensions October 2026 default behavior; they do not replace it. Relationship to PCC-selected allocation: [RFC9604] already allows a PCE to request that the PCC allocate a binding value of the PCC's own choosing by including a TE-PATH-BINDING TLV with no binding value (an empty TLV), which expresses no preference for a particular value. The F flag is distinct: it is used when the PCE does have a preferred binding value but permits the PCC to fall back to a dynamically allocated value if the preferred value is unavailable. A PCE that has no preference continues to use the empty-TLV mechanism of [RFC9604] rather than the F flag. Relationship to multiple TE-PATH-BINDING TLVs: [RFC9604] specifies that multiple instances of the TE-PATH-BINDING TLV in the LSP object represent multiple distinct binding SIDs for the LSP. The requested- versus-allocated reporting defined in Section 5 does not change that rule: the two TLV instances reported for a single binding carry the same Binding Type and are distinguished solely by the A flag, where the instance with the A flag set is the single authoritative (allocated) binding value and the instance with the A flag cleared conveys the originally requested value for correlation only. A receiver MUST use the A flag to determine the active binding value and MUST NOT treat the requested/allocated pair as two independent binding SIDs. Use of the LSP-ERROR-CODE TLV: When the D flag is set, or when fallback allocation under the F flag fails, the LSP is instantiated but kept in a down state rather than the request being rejected. Because no PCEP message is being rejected in this case, the condition is reported using the LSP-ERROR-CODE TLV [RFC8231] in the PCRpt message (LSP Error Code TBD9) rather than the Error-Type 32 (Binding label/SID failure) PCErr defined in [RFC9604], which continues to apply to the request-rejection cases. 7. Operational Considerations All operational requirements and considerations listed in [RFC5440], [RFC8231], and [RFC9604] apply to the PCEP extensions defined in this document. 7.1. Control of Function and Policy A PCE or PCC implementation SHOULD allow the BSID fallback capability to be enabled or disabled through configuration, either globally or on a per-LSP basis. An implementation SHOULD allow the operator to view the advertised and received BSID-FALLBACK-CAPABILITY flags. Implementations SHOULD provide configuration options to: Sidor, et al. Expires 22 April 2027 [Page 10] Internet-Draft PCEP Binding SID Extensions October 2026 * Enable or disable the BSID-FALLBACK-CAPABILITY advertisement * Configure the range of binding values available for dynamic allocation (for example, an MPLS label range, or an SRv6 locator for SRv6 binding SIDs) * Set policies for when to use fallback allocation (F flag) versus keeping LSP down (D flag) * Define priority or preference for BSID allocation from the dynamic pool 7.2. Information and Data Models Implementations SHOULD provide operational state information including: * Whether BSID-FALLBACK-CAPABILITY is enabled and advertised * List of LSPs with binding values, showing both requested and allocated values when they differ * History of binding value allocation failures The PCEP YANG data model MAY be extended to include: * Capability advertisement of BSID-FALLBACK-CAPABILITY * Operational state showing requested versus allocated binding values * Configuration parameters for dynamic binding value pool management 7.3. Liveness Detection and Monitoring Operators SHOULD monitor binding value allocation events and configure alerts for: * Binding value allocation failures due to unavailability * Dynamic binding value pool utilization exceeding configured thresholds * Frequent fallback allocations indicating potential BSID conflicts * LSPs in down state due to D flag with unavailable binding values Implementations SHOULD provide logging for binding value allocation events, including requested values, allocated values, and reasons for any allocation failures. Sidor, et al. Expires 22 April 2027 [Page 11] Internet-Draft PCEP Binding SID Extensions October 2026 7.4. Verify Correct Operations Implementations SHOULD provide means to verify that a binding value requested by the PCE has been correctly allocated by the PCC, by comparing the requested binding value (reported with the A flag cleared) against the allocated binding value (reported with the A flag set) as described in Section 5. Counters such as the number of successful allocations of the requested value, the number of fallback allocations (F flag), and the number of LSPs held down due to an unavailable binding value (D flag) SHOULD be available to the operator to confirm correct operation of the mechanism. 7.5. Requirements on Other Protocols The extensions defined in this document do not impose any new requirements on other protocols beyond those already specified in [RFC9604]. 7.6. Fault Management As specified in Section 5, when BSID fallback allocation fails (for example, due to dynamic pool exhaustion), the LSP is reported as down with appropriate error indication. Implementations should provide clear diagnostic information to help operators identify the root cause of allocation failures, such as pool exhaustion, configuration errors, or BSID conflicts. Operators need to be aware that: * Binding value conflicts can occur due to configuration errors, race conditions, or pool exhaustion * The D flag behavior (LSP down when requested BSID unavailable) may impact service availability and requires monitoring * In redundant PCE deployments, binding value allocation state should be synchronized or coordinated to avoid conflicts 7.7. Impact on Network Operations The mechanisms defined in this document do not introduce additional PCEP messages and reuse the existing TE-PATH-BINDING TLV, so they are not expected to significantly change the frequency or volume of PCEP messages exchanged. Operators need to be aware that enabling the fallback behavior (F flag) may cause the binding value actually in use to differ from the value originally requested, and that the strict behavior (D flag) may leave an LSP in a down state when the requested binding value is unavailable. The configuration and monitoring recommendations in the preceding subsections help operators manage these effects. Sidor, et al. Expires 22 April 2027 [Page 12] Internet-Draft PCEP Binding SID Extensions October 2026 8. Security Considerations The security considerations described in [RFC5440], [RFC8231], and [RFC9604] are applicable to this document. The extensions defined in this document introduce new operational behaviors that require careful security consideration: * Binding Value Allocation: The fallback mechanism allows a PCC to allocate binding values from its dynamic pool when requested values are unavailable. Implementations MUST ensure that the dynamic allocation process includes proper validation and does not allow unauthorized binding value usage. An attacker attempting to exhaust the dynamic pool through repeated requests with unavailable values could cause a denial-of-service condition. Implementations SHOULD implement rate limiting and monitoring of allocation failures. * State Reporting: The mechanism for reporting both requested and allocated binding values provides visibility into binding value allocation. This information MUST be protected to prevent unauthorized correlation of network state. Implementations MUST validate that reported binding values in PCRpt messages accurately reflect the actual allocated values. * LSP Down State: The D flag allows LSPs to be created in a down state when binding values are unavailable. Implementations need to ensure that this does not create opportunities for denial-of- service attacks where an attacker forces numerous LSPs into down state by requesting unavailable binding values. * Flag Manipulation: The A, D, and F flags control critical allocation behavior. Implementations MUST enforce the rules for flag usage, including rejecting messages with the A flag set by a PCE and properly handling mutually exclusive F and D flags, as specified in Section 5. It is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as updated by [RFC9916], as per the recommendations and best current practices in [RFC9325]. This is particularly important given the sensitivity of binding value allocation and the potential for denial-of-service attacks through pool exhaustion. Operators SHOULD carefully review and configure the dynamic binding value pool ranges to ensure adequate capacity while preventing overlap with statically configured binding values. Regular monitoring of binding value allocation patterns can help detect potential security issues or misconfigurations. Sidor, et al. Expires 22 April 2027 [Page 13] Internet-Draft PCEP Binding SID Extensions October 2026 9. IANA Considerations 9.1. STATEFUL-PCE-CAPABILITY TLV Flag Field IANA maintains the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. See https://www.iana.org/assignments/pcep/ pcep.xhtml#stateful-pce-capability-tlv-flag-field IANA is requested to make the following assignment: +======+==============================+===============+ | Bit | Description | Reference | +======+==============================+===============+ | TBA1 | E (BSID-FALLBACK-CAPABILITY) | This document | +------+------------------------------+---------------+ Table 1 9.2. TE-PATH-BINDING TLV Flag Field IANA maintains the "TE-PATH-BINDING TLV Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. See https://www.iana.org/assignments/pcep/pcep.xhtml#te-path- binding-tlv-flag-field IANA is requested to make the following assignments: +======+=================================+===============+ | Bit | Description | Reference | +======+=================================+===============+ | TBA2 | A (Allocated) | This document | +------+---------------------------------+---------------+ | TBA3 | D (Down on BSID Unavailability) | This document | +------+---------------------------------+---------------+ | TBA4 | F (Fallback) | This document | +------+---------------------------------+---------------+ Table 2 9.3. PCEP-ERROR Object Error Types and Values IANA maintains the "PCEP-ERROR Object Error Types and Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. See https://www.iana.org/assignments/pcep/ pcep.xhtml#pcep-error-object IANA is requested to make the following assignments: Sidor, et al. Expires 22 April 2027 [Page 14] Internet-Draft PCEP Binding SID Extensions October 2026 +============+===========+==============================+===========+ | Error-Type | Meaning | Error-value | Reference | +============+===========+==============================+===========+ | 10 | Reception | TBD5: Mutually exclusive | This | | | of an | F and D flags are both | document | | | invalid | set | | | | object | | | +------------+-----------+------------------------------+-----------+ | | | TBD6: A flag incorrectly | This | | | | set by PCE | document | +------------+-----------+------------------------------+-----------+ | | | TBD7: F or D flag set | This | | | | together with the PCE- | document | | | | allocation (P) flag | | +------------+-----------+------------------------------+-----------+ | 19 | Invalid | TBD8: Attempted use of | This | | | Operation | BSID fallback extensions | document | | | | when the BSID-FALLBACK- | | | | | CAPABILITY was not | | | | | advertised | | +------------+-----------+------------------------------+-----------+ Table 3 9.4. LSP-ERROR-CODE TLV Error Code Field IANA maintains the "LSP-ERROR-CODE TLV Error Code Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. See https://www.iana.org/assignments/pcep/ pcep.xhtml#lsp-error-code-tlv-error-code-field IANA is requested to make the following assignment: +=======+========================================+===============+ | Value | Description | Reference | +=======+========================================+===============+ | TBD9 | Requested binding value is unavailable | This document | +-------+----------------------------------------+---------------+ Table 4 10. References 10.1. Normative References Sidor, et al. Expires 22 April 2027 [Page 15] Internet-Draft PCEP Binding SID Extensions October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . [RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024, . Sidor, et al. Expires 22 April 2027 [Page 16] Internet-Draft PCEP Binding SID Extensions October 2026 [RFC9916] Dhody, D., Turner, S., and R. Housley, "Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 9916, DOI 10.17487/RFC9916, July 2026, . 10.2. Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, . Appendix A. Acknowledgements The authors would like to thank Rajesh Melarcode Venkateswaran for their contributions to this document. Authors' Addresses Samuel Sidor Cisco Systems, Inc. Eurovea Central 3 Pribinova 10 811 09 Bratislava Slovakia Email: ssidor@cisco.com Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com Sidor, et al. Expires 22 April 2027 [Page 17] Internet-Draft PCEP Binding SID Extensions October 2026 Mike Koldychev Ciena Corporation 385 Terry Fox Dr. Kanata Ontario K2K 0L1 Canada Email: mkoldych@proton.me Sidor, et al. Expires 22 April 2027 [Page 18]