RFC 9753

Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects

📅 published April 2025, from ietf

RFC 9753: Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects ✨

Okay bestie, let's do the vibe check first 💅 This is RFC 9753, and it's on the Standards Track 🔥. It's dated April 2025 🌸 and the authors are C. Li and H. Zheng from Huawei Technologies, plus S. Litkowski from Cisco 🫶. It updates RFC 8231 🦋. There's no Obsoletes line in the header, so nothing gets replaced. The ISSN is 2070-1721 💜.

Abstract 🎀

This doc introduces a way to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange 🧚. That means the stateful Path Computation Element (PCE) model can relax some constraints during path computation and setup. It brings this relaxation to stateful PCE, and it updates RFC 8231 💖.

Status of This Memo 📜

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🌈.

Info about the current status of this document, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9753 🍓.

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 carefully, because 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. They're provided without warranty, as described in the Revised BSD License 💜.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
2.  Overview
  2.1.  Usage Example
3.  PCEP Extension
  3.1.  STATEFUL-PCE-CAPABILITY TLV
  3.2.  Handling of the P Flag
    3.2.1.  The PCRpt Message
      3.2.1.1.  Delegation
    3.2.2.  The PCUpd Message and the PCInitiate Message
  3.3.  Handling of the I Flag
    3.3.1.  The PCUpd Message
    3.3.2.  The PCRpt Message
    3.3.3.  The PCInitiate Message
  3.4.  Unknown Object Handling
4.  Security Considerations
5.  IANA Considerations
  5.1.  STATEFUL-PCE-CAPABILITY TLV
6.  Manageability Considerations
  6.1.  Control of Function and Policy
  6.2.  Information and Data Models
  6.3.  Liveness Detection and Monitoring
  6.4.  Verify Correct Operations
  6.5.  Requirements on Other Protocols
  6.6.  Impact on Network Operations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🌷

[RFC5440] describes the Path Computation Element Communication Protocol (PCEP). It lets a Path Computation Client (PCC) talk to a Path Control Element (PCE), or lets two PCEs talk to each other, based on the PCE architecture in [RFC4655] 🤝.

PCEP extensions for the stateful PCE model [RFC8231] are a set of extensions to PCEP that enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) tunnels 🔥. [RFC8281] covers setting up and tearing down PCE-initiated LSPs under the active stateful PCE model. That works without local configuration on the PCC, so it allows dynamic control 💅.

[RFC5440] defined the P flag (Processing-Rule) in the Common Object Header. It lets a PCC say, in a Path Computation Request (PCReq) message sent to a PCE, whether the object must be taken into account by the PCE during path computation or is optional 🦋. The I flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) message to tell a PCC whether or not an optional object was considered during path computation 👑.

Stateful PCE [RFC8231] says the P and I flags of PCEP objects are set to zero on transmission and ignored on receipt. The reason is that they're only related to path computation requests 🙈. This document adds a new flag, the R (RELAX) flag in the STATEFUL-PCE-CAPABILITY TLV, in the PCEP common object header. It shows that a PCE speaker supports P and I flag processing ✨. It also explains how the P and I flags could be used in the stateful PCE model to identify optional objects in the Path Computation State Report (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] messages 🧚.

This document updates [RFC8231] on how the P and I flags are used, and on how unknown objects are handled in stateful PCEP message exchange 💜.

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. Overview 🌸

Setting the P flag in the PCReq message to handle unknown objects works the way Section 7.2 of [RFC5440] describes 💖. [RFC8231] also defined how the LSP Error Code TLV is used in the PCRpt message, as a response to a failed LSP Update Request sent via the PCUpd message. An example of a failure is an unsupported object or TLV 🙈.

This document describes how to mark some objects as 'optional to be processed' by the PCEP peer in stateful PCEP messages ✨. It also updates how unknown objects are handled in stateful PCEP messages, based on the P flag 🦋.

2.1. Usage Example 🍓

The PCRpt message reports the current state of an LSP 📡. Part of the message encodes both the <intended-attribute-list> and the <actual-attribute-list> (see [RFC8231]). For example, the <intended-attribute-list> could include the METRIC object to show a limiting constraint (Bound 'B' flag set) for the Path Delay Variation metric [RFC8233] 🌈. In some scenarios, it's useful to say this constraint can be relaxed by the PCE if it can't find a path 💅. In those cases, it's useful to mark the objects as 'optional' so the PCEP peer can ignore them 🫶. It's also useful for the PCEP speaker to learn whether the PCEP peer relaxed the constraint and skipped processing the PCEP object 👑.

So this document specifies how the P and I flags that already exist in the PCEP common object header can be used during stateful PCEP message exchange 🔥. How the P and I flags are applied is defined in [RFC5440], and this document doesn't change that 💜. That means these flags can only be applied to an entire PCEP object. They can't be applied to optional TLVs inside the PCEP object 🙈.

3. PCEP Extension 🧚

3.1. STATEFUL-PCE-CAPABILITY TLV 💖

A PCEP speaker shows that it can handle the P and I flags in stateful PCEP message exchange during the PCEP initialization phase. Here's how 🦋. During that phase, a PCC sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. This document adds a new flag to that TLV, the R (RELAX) flag, to show support for relaxing the processing of some objects through the P and I flags in the PCEP common object header ✨.

R (RELAX bit - 17): If a PCEP Speaker sets this to 1, the R flag means that PCEP Speaker is willing to handle the P and I flags in the PCEP common object header for PCEP objects in stateful PCEP messages 🌈. If the bit is unset, the PCEP Speaker won't handle the P and I flags in the PCEP common object header for stateful PCE messages 🙈.

The R flag MUST be set by both the PCC and PCE to show support for handling the P and I flags in the PCEP common object header, so some constraints can be relaxed by marking objects as 'optional to process' 🔥. If a PCEP speaker doesn't set the R flag but receives PCEP objects with the P or I bits set, it MUST ignore the flags 💅. [RFC8231] says the P and I flags of PCEP objects are set to 0 on transmission and ignored on receipt. It doesn't say what happens with objects defined outside of [RFC8231], which creates ambiguity 👑.

3.2. Handling of the P Flag 🎀

3.2.1. The PCRpt Message 📡

The P flag in the PCRpt message [RFC8231] lets a PCC tell a PCE whether the object must be taken into account by the PCE (during state maintenance, path computation, or re-optimisation) or is optional to process 🦋. When the P flag is set in a PCRpt message received on a PCEP session where both peers set the R bit, the object MUST be taken into account by the PCE 💖. On the flip side, when the P flag is cleared, the object is optional and the PCE can ignore it 🫶.

The P flag for mandatory objects, like the LSP and the ERO (Explicit Route Object) object (intended path), MUST be set in the PCRpt message 🌸. If a mandatory object comes in with the P flag set incorrectly, based on the rules above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (Reception of an object with P flag not set) 🚨. On a PCEP session where both peers set the R bit, the PCC SHOULD set the P flag by default. The exception is when a local configuration or local policy says some constraints (corresponding PCEP objects) can be marked as optional and ignored by the PCE, or when the object itself carries informational parameters that can be safely ignored 🌈.

3.2.1.1. Delegation 👑

Delegation is when a PCC grants a PCE temporary rights to modify a subset of parameters on one or more LSPs, as described in [RFC8051] 🤝. For delegated LSPs, the PCE can update and mark some objects as ignored, even when the PCC set the P flag during delegation. Similarly, the PCE can update and mark some objects as 'must to process' even when the PCC didn't set the P flag during delegation 🔥.

The PCC MUST acknowledge this by sending a PCRpt message with the P flag set as the PCE expects for the corresponding object 💅. If the PCC can't accept the update message, it MUST react according to the processing rules for unacceptable updates in Section 5.8.3 of [RFC8231] 🙈.

3.2.2. The PCUpd Message and the PCInitiate Message ✨

okay so the P flag also shows up in the PCUpd message [RFC8231] and the PCInitiate message [RFC8281], and it's how a PCE tells a PCC whether an object has to be taken into account during path setup or is just optional to process 💅. When the P flag is set in a PCUpd/PCInitiate message received on a PCEP session where both peers set the R bit, the object MUST be taken into account by the PCC. When the P flag is cleared, the object is optional and the PCC can ignore it 🙈.

The P flag for the mandatory objects, like the SRP (Stateful PCE Request Parameters), the LSP, and the ERO, MUST be set in the PCUpd/PCInitiate message 🔥. If a mandatory object shows up with the P flag set incorrectly by the rules above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (Reception of an object with P flag not set) 😭.

On a PCEP session where both peers set the R bit, the PCE SHOULD set the P flag by default. The exception is when a local configuration or policy says some constraints (the matching PCEP objects) can be marked optional and ignored by the PCC, or when the object itself just carries informational parameters that can be safely ignored 🌸.

3.3. Handling of the I Flag 🌈

3.3.1. The PCUpd Message

The I flag in the PCUpd message [RFC8231] lets a PCE tell a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its update request and set the I flag to show the object was ignored. When the I flag is cleared, the PCE is saying the optional object was processed ✨.

Note that when a PCE can't find a path that meets all the constraints from a PCEP object that can't be ignored (aka the P flag is set), the PCUpd message MAY optionally include the PCEP objects that made the path computation fail, along with the empty ERO 🙈.

3.3.2. The PCRpt Message

The I flag in the PCRpt message [RFC8231] lets a PCC tell a PCE whether or not an optional object was processed in response to a PCUpd or PCInitiate message. The PCC MAY include the ignored optional object in its report and set the I flag to show the object was ignored at the PCC. When the I flag is cleared, the PCC is saying the object was processed. The I flag has no meaning if the PCRpt message isn't in response to a PCUpd or PCInitiate message, aka there's no SRP object in the PCRpt message 🧚.

Note that when a PCC can't set up a path that meets all the parameters from a PCEP object that can't be ignored (the P flag is set), the PCRpt message MAY optionally include the PCEP objects that caused the path setup to fail, along with the LSP-ERROR-CODE TLV [RFC8231] showing the reason for the failure 💔.

3.3.3. The PCInitiate Message

The I flag has no meaning in the PCInitiate message [RFC8281], so the I flag MUST set to 0 on transmission and be ignored on receipt 🍓.

3.4. Unknown Object Handling 🧩

This document updates the handling of unknown objects in stateful PCEP messages by setting the P flag in the common object header, in a similar way to what's described in [RFC5440]. So if a PCEP speaker doesn't understand an object with the P flag set, or it understands the object but decides to ignore it, the entire stateful PCEP message MUST be rejected, and the PCE MUST send a PCErr message with Error- Type="Unknown Object" or "Not supported object" [RFC5440]. If the P flag is not set, the PCEP speaker can ignore the object and carry on processing the message as defined 💖.

[RFC8231] defined the LSP Error Code TLV to be carried in the PCRpt message, in the LSP object, to convey error information. This document does not change that procedure 🎀.

4. Security Considerations 🛡

This document specifies how the already existing P and I flags in the PCEP common object header could be used during stateful PCEP exchanges. It updates the unknown object error handling in stateful PCEP message exchange. On their own, these changes don't add any new security concerns. The security considerations identified in [RFC5440], [RFC8231], and [RFC8281] continue to apply 🔐.

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 described in [RFC9325].

Security is NOT the place for vibes, bestie 😭 keep your sessions authenticated AND encrypted, periodt 💅

5. IANA Considerations 📋

5.1. STATEFUL-PCE-CAPABILITY TLV

[RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV, and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA has allocated a new bit in the registry, as follows:

+=====+=============+===========+
| Bit | Description | Reference |
+=====+=============+===========+
| 17  | RELAX       | RFC 9753  |
+-----+-------------+-----------+

Table 1

6. Manageability Considerations 🛠

6.1. Control of Function and Policy

An implementation supporting this document SHOULD allow configuration of the capability to support relaxation of constraints in the stateful PCEP message exchange. They SHOULD also allow configuration of related LSP constraints (or parameters) that are optional to process 🎛.

6.2. Information and Data Models

An implementation supporting this document SHOULD allow the operator to view the capability defined in this document. To serve this purpose, the PCEP YANG module [PCEP-YANG] could be extended in the future 👀.

6.3. Liveness Detection and Monitoring

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440] 💓.

6.4. Verify Correct Operations

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] ✅.

6.5. Requirements on Other Protocols

Mechanisms defined in this document do not imply any new requirements on other protocols 🌍.

6.6. Impact on Network Operations

Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440] 🌙.

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgments ✨

Thanks to Jonathan Hardwick for the discussion and suggestions around this document 💜.

Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and Peng Shaofu for their review comments 🫶.

Contributors 💜

Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com

Authors' Addresses 🦋

Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com


Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com


Stephane Litkowski
Cisco
Email: slitkows.ietf@gmail.com
📦 where this page comes from