Internet-Draft | PCEP Color | January 2025 |
Rajagopalan, et al. | Expires 27 July 2025 | [Page] |
Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g., low latency). This document specifies extensions to Path Computation Element Protocol (PCEP) to carry the color attribute.¶
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 27 July 2025.¶
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 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.¶
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 ([RFC9012]) or SR policy ([RFC9256]). The term color used in this document is not to be interpreted as the 'thread color' specified in [RFC3063] or the 'resource color' (or 'link color') specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308].¶
[RFC8231] 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. [RFC8281] specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. [RFC8664] specifies extensions that enable stateful control of SR paths via PCEP.¶
This document introduces extensions to PCEP to carry the color attribute tagged with TE paths that are setup using RSVP-TE ([RFC8408]) or Segment Routing (SR) ([RFC8664]) or any other path setup type supported under the stateful PCE model. The only exception where the extensions defined in this document are not used for carrying the color attribute is when an SR path is setup using the extensions defined in [I-D.ietf-pce-segment-routing-policy-cp]. For these SR paths, the associated color is already included as part of the SR policy identifier encoding.¶
The mechanism used at the PCC for appropriately mapping services onto a TE path that is tagged with a color attribute is outside the scope of this document.¶
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.¶
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 [RFC8231]. A STATEFUL-PCE-CAPABILITY TLV Flag (See Section 3.1) is introduced in this document to enable the PCEP speaker to advertise color capability.¶
In PCRpt, PCUpd, and PCInitiate messages, the LSP object ([RFC8231], [RFC8281]) is a mandatory inclusion and is used to carry information specific to the target LSP. A TLV called the Color TLV (see Section 3.2), which MAY be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP.¶
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 ([I-D.ietf-pce-segment-routing-policy-cp]) SHOULD 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 which carries an ASSOCIATION object of type SR Policy Association ([I-D.ietf-pce-segment-routing-policy-cp]). 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=TBD1 (Invalid color).¶
When LSPs that belong to the same TE tunnel are within the same Path Protection Association Group [RFC8745], 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=TB2 (Inconsistent color).¶
Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability:¶
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports color capability must turn on this bit.¶
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 [RFC5440], [RFC8231] and [RFC8281].¶
An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in [RFC8253] and [RFC9325] can be used to protect against this attack.¶
This document introduces a value in the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers registry as follows:¶
Value Description Reference ---------------------------------------------- 67 Color This document¶
Note: The code point specified for the TLV Type Indicator is an early allocation by IANA.¶
This document introduces a bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry of the PCEP Numbers registry as follows:¶
Value Description Reference ---------------------------------------------- 20 COLOR-CAPABILITY This document¶
Note: The code point specified for the STATEFUL-PCE-CAPABILITY TLV Flag is an early allocation by IANA.¶
This document introduces 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- Meaning Error-value Reference Type ------------------------------------------------------------------ 19 Invalid Operation TBD1: Invalid Color This document TBD2: Inconsistent Color This document¶
An earlier version of this document added an error code in the "LSP-ERROR-CODE TLV Error Code Field" registry of the PCEP Numbers registry group, which was also early allocated by the IANA.¶
IANA is requested to cancel the early allocation made which is not needed anymore. As per the instructions from the chairs, please mark it as deprecated.¶
Value Meaning Reference ------------------------------------------------------ 9 Deprecated (Unsupported Color) This document¶
[Note to the RFC-Editor: Please remove this section before publication.]¶
[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.]¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
At the time of publication of this version, there are no known implementations. Juniper Networks has plans to implement the extensions defined in this document.¶
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew Stone, Diego Achaval, and Narasimha Kommuri for their review and suggestions.¶
The following people have contributed to this document:¶