Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China c.l@huawei.com

Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Cisco

slitkows.ietf@gmail.com

RTG pce PCEP Stateful optional processing This document introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element (PCE) model can relax some constraints during path computation and setup. This document introduces this relaxation to stateful PCE, and it updates RFC 8231.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice 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 () 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

• .  Introduction
  • .  Requirements Language
• .  Overview
  • .  Usage Example
• .  PCEP Extension
  • .  STATEFUL-PCE-CAPABILITY TLV
  • .  Handling of the P Flag
    • .  The PCRpt Message
      • .  Delegation
    • .  The PCUpd Message and the PCInitiate Message
  • .  Handling of the I Flag
    • .  The PCUpd Message
    • .  The PCRpt Message
    • .  The PCInitiate Message
  • .  Unknown Object Handling
• .  Security Considerations
• .  IANA Considerations
  • .  STATEFUL-PCE-CAPABILITY TLV
• .  Manageability Considerations
  • .  Control of Function and Policy
  • .  Information and Data Models
  • .  Liveness Detection and Monitoring
  • .  Verify Correct Operations
  • .  Requirements on Other Protocols
  • .  Impact on Network Operations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Contributors
• Authors' Addresses

Introduction describes the Path Computation Element Communication Protocol (PCEP), which enables communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture . PCEP extensions for the stateful PCE model describes a set of extensions to PCEP to enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) tunnels. describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for dynamic control. defined the P flag (Processing-Rule) in the Common Object Header to allow a PCC to specify 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 indicate to a PCC whether or not an optional object was considered by the PCE during path computation. Stateful PCE specifies that the P and I flags of the PCEP objects are to be set to zero on transmission and ignored on receipt, since they are exclusively related to the path computation requests. This document defines a new flag, the R (RELAX) flag in STATEFUL-PCE-CAPABILITY TLV, in the PCEP common object header to indicate a PCE speaker supporting P and I flags processing, and it also specifies 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) , the Path Computation Update Request (PCUpd) , and the LSP Initiate Request (PCInitiate) messages. This document updates concerning usage of the P and I flags as well as the handling of unknown objects in stateful PCEP message exchange.

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 when, and only when, they appear in all capitals, as shown here.

Overview Setting the P flag in the PCReq message to handle unknown objects is as described in . Further, defined the usage of the LSP Error Code TLV in the PCRpt message in response to a failed LSP Update Request via the PCUpd message (for example, due to an unsupported object or TLV). This document specifies the procedure of marking some objects as 'optional to be processed' by the PCEP peer in the stateful PCEP messages. Furthermore, this document updates the procedure for handling unknown objects in stateful PCEP messages based on the P flag.

Usage Example The PCRpt message is used to report the current state of an LSP. As part of the message, both the <intended-attribute-list> and <actual-attribute-list> are encoded (see ). For example, the <intended-attribute-list> could include the METRIC object to indicate a limiting constraint (Bound 'B' flag set) for the Path Delay Variation metric . In some scenarios, it would be useful to indicate that this constraint can be relaxed by the PCE in case it cannot find a path. In these cases, it would be useful to mark the objects as 'optional' so they could be ignored by the PCEP peer. Also, it would be useful for the PCEP speaker to learn if the PCEP peer has relaxed the constraint and ignored the processing of the PCEP object. Thus, this document specifies how the already existing P and I flags in the PCEP common object header could be used during the stateful PCEP message exchange. The scope of how P and I flags are applied is defined in and is unchanged by this document. Therefore, these flags can only be applied to an entire PCEP object; they cannot be applied at the granularity of optional TLVs encoded in the PCEP object.

PCEP Extension

STATEFUL-PCE-CAPABILITY TLV A PCEP speaker indicates its ability to support the handling of the P and I flags in the stateful PCEP message exchange during the PCEP initialization phase, as follows. During the PCEP initialization phase, a PCC sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in . A new flag, the R (RELAX) flag, is added to this TLV to indicate support for relaxing the processing of some objects via the use of the P and I flags in the PCEP common object header. R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to handle the P and I flags in the PCEP common object header for the PCEP objects in the stateful PCEP messages. If the bit is unset, it indicates that the PCEP Speaker will not 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 indicate support for handling the P and I flags in the PCEP common object header to allow relaxing some constraints by marking objects as 'optional to process'. If the PCEP speaker does not set the R flag but receives PCEP objects with the P or I bits set, it MUST ignore the flags. states that P and I flags of the PCEP objects are set to 0 on transmission and ignored on receipt. It fails to mention the behaviour of objects defined outside of , leading to ambiguity.

Handling of the P Flag

The PCRpt Message The P flag in the PCRpt message allows a PCC to specify to 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 the PCRpt message received on a PCEP session on which the R bit is set by both peers, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE can ignore it. The P flag for the mandatory objects, such as the LSP and the ERO (Explicit Route Object) object (intended path), MUST be set in the PCRpt message. If a mandatory object is received with the P flag set incorrectly according to the rules stated 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 on which the R bit was set by both peers, the PCC SHOULD set the P flag by default, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCE or the object itself conveys informational parameters that can be safely ignored.

Delegation Delegation is an operation to grant a PCE temporary rights to modify a subset of parameters on one or more LSPs by a PCC as described in . Note that for the delegated LSPs, the PCE can update and mark some objects as ignored even when the PCC has set the P flag during the delegation. Similarly, the PCE can update and mark some objects as a 'must to process' even when the PCC has not set the P flag during delegation. The PCC MUST acknowledge this by sending the PCRpt message with the P flag set as per the PCE expectation for the corresponding object. If the PCC cannot accept the update message, it MUST react as per the processing rules of unacceptable update in .

The PCUpd Message and the PCInitiate Message The P flag in the PCUpd message and the PCInitiate message allows a PCE to specify to a PCC whether the object must be taken into account by the PCC (during path setup) or is optional to process. When the P flag is set in the PCUpd/PCInitiate message received on a PCEP session on which the R bit was set by both peers, the object MUST be taken into account by the PCC. Conversely, when the P flag is cleared, the object is optional and the PCC can ignore it. The P flag for the mandatory objects -- such as the SRP (Stateful PCE Request Parameters), the LSP, and the ERO -- MUST be set in the PCUpd/PCInitiate message. If a mandatory object is received with the P flag set incorrectly according to the rules stated 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 in which both peers set the R bit, the PCE SHOULD set the P flag by default unless a local configuration/policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and can be ignored by the PCC or the object itself conveys informational parameters that can be safely ignored.

Handling of the I Flag

The PCUpd Message The I flag in the PCUpd message allows a PCE to indicate to 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 indicate that the optional object was ignored. When the I flag is cleared, the PCE indicates that the optional object was processed. Note that when a PCE is unable to find the path that meets all the constraints as per the PCEP object that cannot be ignored (i.e. the P flag is set), the PCUpd message MAY optionally include the PCEP objects that caused the path computation to fail along with the empty ERO.

The PCRpt Message The I flag in the PCRpt message allows a PCC to indicate to 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 indicate that the optional object was ignored at PCC. When the I flag is cleared, the PCC indicates that the optional object was processed. The I flag has no meaning if the PCRpt message is not in response to a PCUpd or PCInitiate message (i.e., without the SRP object in the PCRpt message). Note that when a PCC is unable to set up a path that meets all the parameters as per the PCEP object that cannot be ignored (i.e., 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 indicating the reason for the failure.

The PCInitiate Message The I flag has no meaning in the PCInitiate message , so the I flag MUST set to 0 on transmission and ignored on receipt.

Unknown Object Handling This document updates the handling of unknown objects in the stateful PCEP messages by setting the P flag in the common object header in a similar way as described in . That is, if a PCEP speaker does not understand an object with the P flag set, or if the PCEP speaker understands the object but decides to ignore the object, 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" . If the P flag is not set, the PCEP speaker can ignore the object and continue with the message processing as defined. 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.

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 do not add any new security concerns. The security considerations identified in , , and continue to apply. As per , 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) as per the recommendations and best current practices described in .

IANA Considerations

STATEFUL-PCE-CAPABILITY TLV 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

Manageability Considerations

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.

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 could be extended in the future.

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 .

Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in .

Requirements on Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols.

Impact on Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. Informative References Huawei Juniper Networks Nvidia Work in Progress Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.

Acknowledgments Thanks to for the discussion and suggestions around this document. Thanks to , , , and for their review comments.

Contributors Huawei

India dhruv.ietf@gmail.com

Authors' Addresses Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China c.l@huawei.com

Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Cisco

slitkows.ietf@gmail.com