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 24 July 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

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.¶

Association parameters: As described in [RFC8697], the combination of the mandatory fields Association type, Association ID and Association Source in the ASSOCIATION object uniquely identify the association group. If the optional TLVs - Global Association Source or Extended Association ID are included, then they are included in combination with mandatory fields to uniquely identify the association group.¶

Association information: As described in [RFC8697], the ASSOCIATION object could also include other optional TLVs based on the association types, that provides 'information' related to the association type.¶

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 does 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 signalling 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 than the RRO such as during protection conditions or if the ERO contains loose hops which are expanded upon. As Segment Routing LSP does not perform any signalling, 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 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 8281 - Orphaned LSP without delegation

[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 second mechanism goes on to describe the messaging procedures by which a PCE may obtain control of an orphaned PCE-initiated LSP. However, the document 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 completely unaware of the current delegation status of an LSP with respect to another PCE.¶

To address this issue, this document updates 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."¶

6. Security Considerations

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

7. Managability Considerations

TODO¶

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.¶

Authors' Addresses