Amendments to Stateful PCE Communication Protocol (PCEP)

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 4 January 2027.¶

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

The PCEP protocol has evolved from a stateless protocol [RFC5440] to a stateful protocol [RFC8231], incorporating numerous extensions.¶

During interoperability testing it was observed that various implementations have implemented optimizations in the protocol. This document serves to optimize the original procedure in [RFC8231] to optionally drop the PCReq and PCReply exchange, which greatly simplifies implementation and optimizes the protocol.¶

In addition, [RFC8664] introduced extensions for Segment Routing and the encoding of segments in the ERO and RRO objects in PCEP. This document serves as an update to [RFC8664] to permit the exclusion of the RRO object for Segment Routed paths.¶

Lastly, [RFC8281] describes two mechanisms for handling orphaned LSPs, one of which requires a PCE to request delegation of the orphaned LSP. However, this mechanism is incompletely specified, which has led most implementations to follow PCC originated redelegation when an LSP becomes orphaned. This document updates [RFC8281] to clarify the ambiguity and promote interoperability by mandating that the PCC attempt to redelegate orphaned LSPs.¶

2. Terminology

The following terminologies are used in this document:¶

PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.¶

PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.¶

PCEP: Path Computation Element Protocol.¶

MBB: Make-Before-Break. A procedure during which the head-end of a traffic-engineered path wishes to move traffic to a new path without losing any traffic, by first "making" a new path and then "breaking" the old path.¶

ERO: Explicit Route Object is the path of the LSP encoded into a PCEP object. In this document, an empty ERO object, i.e., without any subobjects, is represented with notation "ERO={}". An ERO object containing a given sequence of subobjects is represented as "ERO={A}".¶

PCRPT-LSP-DB: PCEP Reported Label Switched Path Database. A logical datastore that captures the reported state information of Label Switched Paths (LSPs) within a PCEP speaker. This term is not defined in the PCE architecture; however, it is used in this document to describe how a PCEP speaker may internally maintain LSP-related state information reported via PCRpt messages.¶

EXTENDED-LSP-DB: Extended Label Switched Path Database. An implementation-specific logical datastore used to capture information related to a Label Switched Path. It may be keyed using the same identifiers as the PCRPT-LSP-DB. This term is not defined in the PCE architecture but is used in this document to refer to a conceptual datastore that can include additional attributes—such as desired state, telemetry data, and other information not defined within IETF PCE working group documents.¶

PLSP-ID (Path LSP Identifier): Introduced in [RFC8231]. A unique identifier used in PCEP to distinguish a specific LSP between a PCC and a PCE which is constant for the lifetime of a PCEP session.¶

3. Stateful Bringup

[RFC8231] Section 5.8.2 allows delegation of an LSP in an operationally down state, but at the same time mandates the use of PCReq before sending PCRpt. This document clarifies that sending PCReq is optional.¶

The process of sending PCReq before PCRpt is referred to in this document as "stateless bringup". In practice, stateless bringup introduces overhead and the PCRpt sent from PCC cannot be enforced by the PCE, because a stateless PCE is not required to maintain any per-LSP state about previous PCReq messages. It has been observed that many implementations choose to ignore this requirement and send the PCRpt directly, without first sending a PCReq. Although this behavior is not compliant with [RFC8231], it offers message processing advantages and simplifications. As a result, this document updates [RFC8231].¶

The adoption of stateful PCE does not eliminate the utility of stateless PCEP. A characteristic of stateless PCEP is that PCReq messages do not require altering the LSP path state information in the PCE. As a result, PCReq messages can be used in scenarios such as OAM functions (e.g., ping and traceroute), where it is necessary to probe the network topology without impacting existing LSPs and LSP state management in the PCE.¶

This document uses the concept of a PCRPT-LSP-DB to represent the database of actual LSP state in the network, as reported by PCCs. It is used to illustrate the internal state maintained by PCEP speakers in response to PCRpt messages. This datastore is modified only by PCRpt messages. In contrast, additional information that a PCE implementation may maintain such as desired state, policy metadata, or telemetry is considered part of the EXTENDED-LSP-DB. The EXTENDED-LSP-DB is an implementation-specific logical store which is outside the scope of this document.¶

Note that the term "LSP", which stands for "Label Switched Path", if taken too literally, would restrict the discussion to the MPLS dataplane only. In this document, the term "LSP" is applied to non-MPLS paths as well, to avoid renaming the term. Alternatively, the term "LSP" could be replaced with "Instance".¶

4. Updates to RFC 8664 - Use of SR-RRO and SRv6-RRO objects

[RFC8231] defines a PCRpt message which contains <intended-path> known as the ERO object and <actual-path> known as the RRO object. [RFC8664] defines SR-ERO and SR-RRO sub-objects for SR-TE LSPs. [RFC9603] further defines SRv6-ERO and SRv6-RRO sub-objects for SRv6-TE paths.¶

In practice RRO data is the result of signaling via a protocol such as RSVP-TE, which allows collection of per-hop information along the path. The ERO and RRO values may be different as the path encoded in the ERO may differ from the RRO such as during protection conditions or if the ERO contains loose hops which are expanded upon. As a Segment Routing LSP does not perform any signaling, the values of an SR-ERO/SRv6-ERO and SR-RRO/SRv6-RRO (respectively) are in practice the same, therefore some implementations have omitted the RRO when reporting a SR-TE LSP while others continue to send both ERO and RRO values.¶

This document updates [RFC8664] by clarifying and relaxing the requirement for both an ERO and RRO object to exist for SR-TE paths. If both ERO and RRO are present for the same LSP, it SHOULD be interpreted as the RRO being the actual path the LSP is taking but MAY interpret only the ERO as the actual path. In the absence of RRO a PCE MUST interpret the ERO as the actual path for the LSP. Until SR-TE introduces some form of signaling similar to RSVP-TE, the use of RRO is discouraged for SR-TE LSPs.¶

5. Updates to RFC 8231 and RFC 8281 - Orphaned LSP redelegation

[RFC8281] Section 6, describes two mechanisms for handling the case when an LSP becomes orphaned. The relevant text is as follows:¶

"The PCC MAY attempt to redelegate an orphaned LSP by following the procedures of [RFC8231]. Alternatively, if the orphaned LSP was PCE-initiated, then a PCE MAY obtain control over it, as follows"¶

The first mechanism is based on the redelegation procedures defined in [RFC8231] Section 5.7.5. [RFC8231] describes how delegation returns to the PCC after the Redelegation Timeout Interval expires, and how the LSP may be redelegated to another PCE. In the standby-PCE case, [RFC8231] also allows the Redelegation Timeout Interval to be set to 0, causing the LSP to be redelegated immediately to the standby PCE. This document updates that behavior by making the PCC attempt to redelegate an orphaned LSP.¶

The second mechanism goes on to describe the messaging procedures by which a PCE may obtain control of an orphaned PCE-initiated LSP. However, [RFC8281] does not define how a PCE determines whether a PCC expects it to take action to obtain control, nor does it specify when such action should be taken. This ambiguity is problematic in deployments with backup or redundant PCEs, as a PCE may be unaware of the current delegation status of an LSP with respect to another PCE.¶

For example, when the PCE to which an LSP was delegated fails, the PCC detects the loss of the PCEP session. After the Redelegation Timeout Interval expires, delegation returns to the PCC and the LSP becomes orphaned until the State Timeout Interval expires. A backup PCE with an active session to the same PCC cannot know whether the PCC will redelegate the LSP or whether the backup PCE should initiate the [RFC8281] procedure to request delegation. Without clear guidance, backup PCE implementations may differ in behavior, which can result in duplicate control attempts, delayed takeover, or no takeover at all.¶

To address this issue, this document updates [RFC8231] Section 5.7.5 and the previously quoted text in [RFC8281] as follows:¶

"PCC MUST attempt to redelegate an orphaned LSP to a connected PCE by following the procedures of [RFC8231] and in accordance with local policy."¶

Mandating PCC-initiated redelegation establishes a single, interoperable behavior that both the PCC and any connected PCE can rely upon. This document does not deprecate the [RFC8281] procedure by which a PCE explicitly requests delegation of an orphaned PCE-initiated LSP. A PCE MAY apply local policy to decide when to use that procedure, for example when the PCC is a legacy implementation that does not redelegate the orphaned LSP. Furthermore, this specification does not preclude future extensions or impose constraints on alternative solutions.¶

6. Operational Considerations

This section provides operational guidance for deployments implementing the updates in this document.¶

7. Security Considerations

The security considerations described in [RFC8231], [RFC8281] and [RFC8664] apply to this document.¶

8. IANA Considerations

This document has no IANA actions.¶

9. References

Acknowledgments

The authors would like to thank Adrian Farrel for useful review comments on [I-D.draft-koldychev-pce-operational] which have been carried over and have been applied into this document. The authors would also like to thank Dhruv Dhody for content discussion and review. Thanks to Marina Fizgeer for bringing the orphaned LSP without delegation problem to the attention of the PCE WG.¶

Authors' Addresses