| Internet-Draft | PCEP Binding SID Extensions | October 2025 |
| Sidor, et al. | Expires 13 April 2026 | [Page] |
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 as described in RFC9604.¶
A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or 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 range 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.¶
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 13 April 2026.¶
Copyright (c) 2025 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.¶
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. These extensions aim to improve the robustness and flexibility of LSP instantiation and management in PCEP-controlled networks.¶
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.¶
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker.¶
The base PCEP specification [RFC4655] originally defined the use of the PCE architecture 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 Candidate Path within an SR Policy, which may be an 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 an SR Policy or an SR-TE LSP.¶
The PCEP provides mechanisms for PCEs to instantiate and manage LSPs on a PCC. A Stateful PCE [RFC8231] can instantiate LSPs on a PCC. When instantiating a SR-TE LSP [RFC8664], the PCE may request a specific BSID to be associated with the LSP using the TE-PATH-BINDING 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 range. 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.¶
A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in Section 5.4 of [RFC8231].¶
New flags are proposed in the TE-PATH-BINDING TLV, which was originally defined in Section 4 of [RFC9604].¶
The PCEP protocol extensions defined in this document MUST NOT be used if one or both PCEP speakers have not indicated support for the extensions by setting the F flag (BSID-FALLBACK-CAPABILITY) in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.¶
When a PCE wants to instantiate or update an LSP and suggest a binding value, it includes the TE-PATH-BINDING TLV in the PCInitiate or PCUpd message. 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.¶
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.¶
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 its PCRpt message, 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:¶
If the requested binding value was successfully allocated, only a single instance of the TE-PATH-BINDING TLV with the A flag set SHOULD be included in the PCEP message.¶
The A, D and F flags in the TE-PATH-BINDING TLV MUST NOT be used if one or both PCEP speakers have not 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 10 (Reception of an invalid object) and Error-Value TBD6 (Unsupported Binding SID Extension Flags).¶
All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC9604] apply to the PCEP extensions defined in this document.¶
A PCE or PCC implementation MAY allow the capability of supporting PCEP extensions introduced in this document to be enabled/disabled as part of the global configuration. An implementation SHOULD allow the operator to view the advertised and received capabilities.¶
The security considerations described in [RFC5440], [RFC8231], and [RFC9604] are applicable to this document. No additional security measures are required.¶
As per [RFC8231], it is RECOMMENDED that these PCEP extensions can 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 per the recommendations and best current practices in [RFC9325].¶
IANA maintains a registry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignment:¶
| Bit | Description | Reference |
|---|---|---|
| TBA1 | F (BSID-FALLBACK-CAPABILITY) | This document |
IANA maintains a registry, named "TE-PATH-BINDING TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. 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 |
IANA maintains a registry, named "PCEP-ERROR Object Error Types and Values", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignments:¶
| Error-Type | Meaning | Error-value | Reference |
|---|---|---|---|
| 10 | Reception of an invalid object | TBD5: Mutually exclusive F and D flags are both set | This document |
| TBD6: Unsupported Binding SID Extension Flags | This document |
The authors would like to thank Rajesh Melarcode Venkateswaran for their contributions to this document.¶