Juniper Networks

balajir@juniper.net

Juniper Networks

vbeeram@juniper.net

ZTE Corporation

peng.shaofu@zte.com.cn

Ciena Corporation

mkoldych@proton.me

Verizon Communications Inc.

gyan.s.mishra@verizon.com

RTG pce color Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute.

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
• .  Protocol Operation
• .  Protocol Extensions
  • .  Color Capability
  • .  COLOR TLV
• .  Security Considerations
• .  Manageability Considerations
  • .  Control of Function through Configuration and Policy
  • .  Information and Data Models
  • .  Liveness Detection and Monitoring
  • .  Verifying Correct Operation
  • .  Requirements on Other Protocols
  • .  Impact on Network Operation
• .  IANA Considerations
  • .  PCEP TLV Type Indicator
  • .  STATEFUL-PCE-CAPABILITY TLV Flag Field
  • .  PCEP-Error Object
  • .  LSP-ERROR-CODE TLV Error Code Field
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Contributors
• Authors' Addresses

Introduction A Traffic Engineering (TE) Tunnel or Segment Routing (SR) policy can be associated with an intent or objective (e.g., low latency) by tagging it with a color. This color attribute is used as a guiding criterion for mapping services onto the TE Tunnel or SR Policy . The term "color" used in this document must not be interpreted as the "thread color" specified in or the "resource color" (also referred to as "link color") specified in , , , and . specifies extensions to the Path Computation Element Protocol (PCEP) that enable the deployment of a stateful Path Computation Element (PCE) model. These extensions allow a Path Computation Client (PCC) to delegate control of the Label Switched Paths (LSPs) associated with its TE Tunnels to a stateful PCE. specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. specifies extensions that enable stateful control of SR paths via PCEP. This document introduces extensions to PCEP to allow a color tag to be assigned to any TE path operated under a stateful PCE model (including those set up using RSVP-TE or Segment Routing ). The only exception where the extensions defined in this document MUST NOT be used to carry the color attribute is for SR paths established using the extensions defined in . For these SR paths, the associated color is already included as part of the SR Policy identifier encoding. The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document, as is any other use of the color tag.

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.

Protocol Operation When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in . A STATEFUL-PCE-CAPABILITY TLV Flag (see ) is introduced in this document to enable the PCEP speaker to advertise color capability. In PCRpt, PCUpd, and PCInitiate messages, the LSP object is a mandatory inclusion and is used to carry information specific to the target LSP. A TLV called the COLOR TLV (see ), which MAY be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP. Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV appears in the LSP object more than once, only the first occurrence is processed, and any others MUST be ignored. A PCEP speaker that has advertised color capability MUST NOT send COLOR TLV encoded in the LSP object to a PCEP Peer that has not advertised color capability. A PCEP speaker that advertises both color capability and SR Policy Association capability MUST NOT send COLOR TLV encoded in the LSP object for SR Paths. The COLOR TLV is ignored if it shows up in the LSP object of a message that carries an ASSOCIATION object of type SR Policy Association . The color encoded in the SR Policy Association takes precedence in such a scenario. If a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCC MUST reject the message and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=31 (Invalid color). This is expected behavior in scenarios where a PCC implementation does not support a color value of zero for specific path setup types, and it receives that value in the COLOR TLV of a PCUpd or a PCInitiate message. When LSPs that belong to the same TE Tunnel are within the same Path Protection Association Group , they are all expected to have the same color attached to them. If a PCEP speaker determines inconsistency in the color associated with the LSPs belonging to the same Path Protection Association Group, it MUST reject the message carrying the inconsistent color and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=32 (Inconsistent color).

Protocol Extensions

Color Capability defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability:

C-bit (Bit 20):

A PCE/PCC indicates that it supports the color capability defined in this document by setting this bit.

COLOR TLV

COLOR TLV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

67

Length:

4

Color:

4-byte field that carries the actual color value (specified as an unsigned integer). A value of zero is allowed.

Security Considerations This document defines a TLV for color and a flag for color capability negotiation, which do not add any security concerns beyond those discussed in , , and . An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in and can be used to protect against this attack.

Manageability Considerations This section follows the advice and guidance of .

Control of Function through Configuration and Policy An implementation supporting this document SHOULD allow the operator to turn on and off the PCEP color capability advertisement (). An implementation supporting this document SHOULD allow the configuration of color assignment to a TE Tunnel or an SR Policy. A PCC MAY have a local policy configuration that specifies how the color tag is used. This policy configuration is outside the scope of this document.

Information and Data Models An implementation supporting this document SHOULD allow the inclusion of color in the data model used to retrieve the operational state of a TE Tunnel or an SR Policy. The YANG model in could be used to retrieve the operational state of a TE Tunnel, and the YANG model in could be used to retrieve the operational state of an SR Policy.

Liveness Detection and Monitoring The extensions defined in this document do not require any additional liveness detection and monitoring support. See and for more information.

Verifying Correct Operation The operator MAY retrieve the operational state of TE Paths to verify if they are tagged with the correct intended color.

Requirements on Other Protocols This document places no explicit requirements on other protocols.

Impact on Network Operation The impact on network operations depends on how the color tag is used in the deployment. This is outside the scope of this document.

IANA Considerations

PCEP TLV Type Indicator IANA has assigned a value in the "PCEP TLV Type Indicators" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:

Value	Description	Reference
67	Color	RFC 9863

STATEFUL-PCE-CAPABILITY TLV Flag Field IANA has assigned a bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:

Value	Description	Reference
20	COLOR-CAPABILITY	RFC 9863

PCEP-Error Object IANA has assigned two Error-values for Error-Type=19 (Invalid Operation) within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:

Error-Type	Meaning	Error-value	Reference
19	Invalid Operation	31: Invalid Color	RFC 9863
		32: Inconsistent Color	RFC 9863

LSP-ERROR-CODE TLV Error Code Field A draft version of this document added an error code in the "LSP-ERROR-CODE TLV Error Code Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group, which was also early allocated by the IANA. IANA has marked it as deprecated.

Value	Meaning	Reference
9	Deprecated (Unsupported Color)	RFC 9863

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. A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session. Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. 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. Ciena Corporation Ciena Corporation Cisco Systems, Inc. Juniper Networks, Inc. Huawei Technologies Nokia Informative References This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community. This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK] A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK] It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group. Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community. MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Cisco Systems Cisco Systems Huawei Technologies SoftBank Juniper Networks This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. Work in Progress Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Work in Progress

Acknowledgments The authors would like to thank , , , , , , , , and for their review and suggestions.

Contributors The following people have contributed to this document: ZTE Corporation

xiong.quan@zte.com.cn

Authors' Addresses Juniper Networks

balajir@juniper.net

Juniper Networks

vbeeram@juniper.net

ZTE Corporation

peng.shaofu@zte.com.cn

Ciena Corporation

mkoldych@proton.me

Verizon Communications Inc.

gyan.s.mishra@verizon.com