Amendments to Stateful PCE Communication Protocol (PCEP)
draft-many-pce-stateful-amendment-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Andrew Stone , Mike Koldychev , Siva Sivabalan , Diego Achaval , Shuping Peng , Hari Kotni , Samuel Sidor | ||
| Last updated | 2026-01-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-pce-stateful-amendment-03
PCE Working Group A. S. (Editor)
Internet-Draft Nokia
Updates: 8231, 8664, 8281 (if approved) M. Koldychev
Intended status: Standards Track S. Sivabalan
Expires: 24 July 2026 Ciena
D. Achavel
Nokia
S. Peng
Huawei Technologies
H. Kotni
Juniper Networks, Inc
S. Sidor
Cisco
20 January 2026
Amendments to Stateful PCE Communication Protocol (PCEP)
draft-many-pce-stateful-amendment-03
Abstract
This document updates RFC8231, RFC8664 and RFC8281 to reflect
operationalized implementations and define optimizations in the PCEP
protocol.
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.
(Editor), et al. Expires 24 July 2026 [Page 1]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Stateful Bringup . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Updates to RFC 8231 - Stateful bringup . . . . . . . . . 5
3.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 6
4. Updates to RFC 8664 - Use of SR-RRO and SRv6-RRO objects . . 6
4.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 7
5. Updates to RFC 8281 - Orphaned LSP without delegation . . . . 7
5.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Managability Considerations . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
(Editor), et al. Expires 24 July 2026 [Page 2]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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.
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
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.
(Editor), et al. Expires 24 July 2026 [Page 3]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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
(Editor), et al. Expires 24 July 2026 [Page 4]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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".
3.1. Updates to RFC 8231 - Stateful bringup
[RFC8231] Section 5.8.2, says "The only explicit way for a PCC to
request a path from the PCE is to send a PCReq message. The PCRpt
message MUST NOT be used by the PCC to attempt to request a path from
the PCE." This document updates [RFC8231] to remove the quoted text.
As part of the new bringup procedure, the PCC MAY delegate an empty
LSP (no ERO or empty ERO) to the PCE and then wait for the PCE to
send a PCUpd, without first sending a PCReq. This process is
referred to as "stateful bringup". The PCE MUST support the original
stateless bringup for backward compatibility.
An example of stateful bringup follows. In this example, the PCC
starts by using an LSP-ID of 0. The value 0 does not hold any
special meaning; any other 16-bit value could have been used.
PCC has no LSP yet, but wants to establish a path. PCC sends
PCRpt(R-FLAG=0, D-flag=1, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=0,
ERO={}).
+=============+========================================+
| TUNNEL | LSP |
+=============+========================================+
| PLSP-ID=100 | OLSP-ID=0, D-flag=1, OPER=DOWN, ERO={} |
+-------------+----------------------------------------+
Table 1: Content of LSP DB after first PcRpt
(Editor), et al. Expires 24 July 2026 [Page 5]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
PCC received a PCUpd from the PCE and has decided to install the
ERO={A} from that PCUpd. PCC sends PCRpt(R-FLAG=0, D-flag=1, OPER-
FLAG=UP, PLSP-ID=100, LSP-ID=0, ERO={A}).
+=============+======================================+
| TUNNEL | LSP |
+=============+======================================+
| PLSP-ID=100 | LSP-ID=0, D-flag=1, OPER=UP, ERO={A} |
+-------------+--------------------------------------+
Table 2: Content of LSP DB after PcUpd
3.2. Backwards Compatibility
The stateful bringup mechanism is compatible with legacy PCEP
implementations. The PCE continues to support stateless bringup (via
PCReq) for legacy PCCs. Supporting stateful bringup does not require
introducing new behavior on the PCE, since, as previously noted, a
PCE implementation only modifies the conceptual PCRPT-LSP-DB state
based on PcRpt messages. Therefore, regardless of whether a PCReq
has been received, the PCE processes the PCRpt in the same manner.
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.
(Editor), et al. Expires 24 July 2026 [Page 6]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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.
4.1. Backwards Compatibility
The update to [RFC8664] permitting PCC to omit carrying SR-RRO/
SRv6-RRO may create interoperability problems between different
implementations of newer PCC and a legacy PCE. It is possible that
an implementation of PCE which requires reading the SR-RRO/SRv6-RRO,
may result with incomplete data processing on the PCE for the LSP.
However, as this document is attempting to reflect operationalized
implementations, PCE implementations are likely already capable of
falling back to processing the SR-ERO/SRv6-ERO objects.
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."
(Editor), et al. Expires 24 July 2026 [Page 7]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
5.1. Backwards Compatibility
The update to [RFC8281] mandating that a PCC MUST attempt to
redelegate orphaned LSPs introduces considerations for
interoperability between updated and legacy implementations.
PCC Perspective: A PCC implementing this document MUST attempt to
redelegate orphaned LSPs to an active PCE. From the perspective of a
legacy PCE, these redelegations will appear as standard [RFC8231]
procedures. Since legacy PCEs are already capable of processing
redelegation of LSPs driven from PCC, this update is backwards
compatible.
PCE Perspective: For a PCE implementing this document, the primary
change is the shift in expectation regarding PCC behavior. A PCE
operates with the expectation that the PCC will initiate
redelegation. However, if the PCC is a legacy implementation that
does not perform the redelegation, the PCE MAY apply local policy to
decide when to revert to [RFC8281] procedures and explicitly request
delegation of orphaned LSPs.
Capability Advertisement: A capability mechanism to indicate support
for this document may be defined in a future revision. This
capability is currently informational; it serves to notify the PCE
that the PCC explicitly supports the mandated redelegation behavior.
This allows the PCE to distinguish between a PCC that is expected to
redelegate (per this document) and a legacy PCC, requiring the PCE to
follow local policy and therefore MAY explicitly request delegation
of orphaned LSPs.
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
9.1. Normative References
(Editor), et al. Expires 24 July 2026 [Page 8]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8231>.
[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,
<https://www.rfc-editor.org/rfc/rfc8281>.
[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,
<https://www.rfc-editor.org/rfc/rfc8664>.
9.2. Informative References
[I-D.draft-koldychev-pce-operational]
Koldychev, M., Sivabalan, S., Peng, S., Achaval, D.,
Kotni, H., and A. Stone, "PCEP Operational Clarification",
Work in Progress, Internet-Draft, draft-koldychev-pce-
operational-09, 28 March 2025,
<https://datatracker.ietf.org/doc/html/draft-koldychev-
pce-operational-09>.
[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,
<https://www.rfc-editor.org/rfc/rfc9603>.
(Editor), et al. Expires 24 July 2026 [Page 9]
Internet-Draft PCEP-STATEFUL-AMEND January 2026
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
Andrew Stone (Editor)
Nokia
Email: andrew.stone@nokia.com
Mike Koldychev
Ciena
Email: mkoldych@proton.me
Siva Sivabalan
Ciena
Email: ssivabal@ciena.com
Diego Achavel
Nokia
Email: diego.achaval@nokia.com
Shuping Peng
Huawei Technologies
Email: pengshuping@huawei.com
Hari Kotni
Juniper Networks, Inc
Email: hkotni@juniper.net
Samuel Sidor
Cisco
Email: ssidor@cisco.com
(Editor), et al. Expires 24 July 2026 [Page 10]