| Internet-Draft | PCE LSP validation Extensions in Path Co | October 2025 |
| Fizgeer | Expires 18 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). A Stateful PCE RFC8231 can instantiate LSPs on a PCC. In some cases, the PCC shall perform additional validations and/or actions. If some validations or actions fail, the LSP will not be created and established or updated. This document specifies PCEP extensions to handle this situation gracefully in case the problem can be resolved by some network changes (freeing up resources, restoring or changing the network, and so on). This draft defines common usage of the new flag and known use cases for using this flag. Each draft relevant to LSP creation can add a corresponding bit to the use case list.¶
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 4 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 specifies PCEP extensions to handle the situation when LSP validation is failed. The goal is to handle it gracefully in case the problem can be resolved by some network changes (freeing up resources, restoring or changing the network, and so on).¶
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 MPLS and GMPLS networks with LSPs instantiated using the 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 SRv6 path (still represented using the LSP Object as specified in [RFC8231]).¶
Initially defined in (draft-sidor-pce-binding-label-sid-extensions).¶
Indicates that the PCEP peer supports LSP creation and fall back to dynamic binding value allocation if the specific binding value is unavailable.¶
Indicates that the PCEP peer supports LSP creation if some ERO in the ERO list is unreachable, unknown.¶
The PCEP peer supports LSP creation when the LSP is initiated with S-BFD enabled. However, if S-BFD resources are currently exhausted or have reached their maximum allocation, the LSP can still be created but may remain in a down state until resources become available.¶
A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in Section 5.4 of [RFC8231]. Also referenced in the "PCEP Binding SID Extensions".¶
D (DOWN-CAPABILITY): If set, this flag indicates that the PCEP peer supports LSP creation even when certain validations or actions fail. In such cases, the LSP is instantiated but remains in a down state, allowing for potential recovery through network changes or further actions.¶
New optional TLV can be added to the SRP object, initially defined in [RFC8231].¶
0 1 2 3 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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Type | Length | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Bit String |D| | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
D flag: If set, indicates that LSP can be created even if specified validation or action cannot be passed, but LSP will be in down state.¶
Bit String (If flag D is 1):¶
bit 0 - if specified binding value is unavailable (draft-sidor-pce-binding-label-sid-extensions)¶
bit 1 - if specified path in ERO list is not passed resolution¶
bit 2 - S-BFD leak of resources.¶
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 D flag in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.¶
When a PCE wants to instantiate or update an LSP, in the PCInitiate or PCUpd message, the PCE can set the D flag in this TLV to control the PCC's behavior in case the requested LSP has some problem.¶
If the PCC receives this new TLV with the D flag set and the bit is set in the string with relevant use case, the PCC MUST instantiate the LSP but keep it in a down state in case of relevant failure.¶
Some failures can be resolved by the PCC. For example, ERO resolution may succeed after certain network changes (e.g., freeing up resources or restoring connectivity). In such cases, the PCC MUST update the state of the LSP and send a PCRpt message to the PCE.¶
Other failures, such as S-BFD resource exhaustion, may require rechecking initiated by the PCE. Each use case and its corresponding behavior shall be defined in the relevant draft that utilizes the new D flag.¶
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.¶
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 | +======+================================+===============+ | TBD1 | D (DOWN-CAPABILITY) | This document | +------+--------------------------------+---------------+
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:¶
+======+=========================+===============+
| N | Description | Reference |
+======+=========================+===============+
| TBD2 | New optional TLV in SRP | This document |
+------+-------------------------+---------------+
The author thanks for...¶