RFC 9863
Path Computation Element Protocol (PCEP) Extension for Color
Path Computation Element Protocol (PCEP) Extension for Color 🎀
Okay bestie, let's start with the header 💅 This is RFC 9863, published by the IETF in October 2025. It's a Standards Track document, so it's the real deal, not a draft idea 🔥 Its ISSN is 2070-1721.
The authors are B. Rajagopalan and V. Beeram from Juniper Networks, S. Peng from ZTE Corporation, M. Koldychev from Ciena Corporation, and G. Mishra from Verizon Communications Inc. 🫶 The header doesn't list anything this RFC obsoletes or updates.
Abstract ✨
Okay so color is a 32-bit numerical (unsigned integer) attribute 🌈 that lets you tag a Traffic Engineering (TE) tunnel or policy with an intent or objective. Picture a TE Tunnel built for low latency services, with a path optimized for delay. You can tag it with a color that means "low latency" and it's giving exactly what it says 🦋 This document specifies extensions to the Path Computation Element Protocol (PCEP) so that the color attribute can travel along with the tunnel.
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 it has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 ⭐
Info about the current status of this document, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc9863 💜
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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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, and they are provided without warranty as described in the Revised BSD License 🫶
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
2. Protocol Operation
3. Protocol Extensions
3.1. Color Capability
3.2. COLOR TLV
4. Security Considerations
5. Manageability Considerations
5.1. Control of Function through Configuration and Policy
5.2. Information and Data Models
5.3. Liveness Detection and Monitoring
5.4. Verifying Correct Operation
5.5. Requirements on Other Protocols
5.6. Impact on Network Operation
6. IANA Considerations
6.1. PCEP TLV Type Indicator
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
6.3. PCEP-Error Object
6.4. LSP-ERROR-CODE TLV Error Code Field
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🦋
Okay so a Traffic Engineering (TE) Tunnel [RFC3209] or a Segment Routing (SR) policy [RFC9256] can be linked to an intent or objective (e.g., low latency) just by tagging it with a color 🌈 That color is then used as a guiding criterion for mapping services onto the TE Tunnel [RFC9012] or the SR Policy [RFC9256]. ✨
Heads up: the word "color" in this document must not be interpreted as the "thread color" from [RFC3063], or the "resource color" (also called "link color") from [RFC3630], [RFC5329], [RFC5305], and [RFC7308]. Not the same vibe at all 🙈
[RFC8231] defines extensions to PCEP that enable a stateful Path Computation Element (PCE) model. These extensions let a Path Computation Client (PCC) delegate control of the Label Switched Paths (LSPs) tied to its TE Tunnels over to a stateful PCE 💅 [RFC8281] then adds extensions that let a PCE instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. And [RFC8664] adds extensions for stateful control of SR paths via PCEP 👑
This document brings PCEP extensions so a color tag can be assigned to any TE path operated under a stateful PCE model (including the ones set up using RSVP-TE [RFC8408] or Segment Routing [RFC8664]). The one exception is SR paths set up using the extensions in [RFC9862]. For those, the color is already baked into the SR Policy identifier encoding, so the extensions defined in this document MUST NOT be used to carry the color attribute 🚫
How the PCC maps services onto a TE path with a color attribute is outside the scope of this document. So is any other use of the color tag 🧚
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. Protocol Operation ✨
When a PCEP session gets 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]. Then the STATEFUL-PCE-CAPABILITY TLV Flag (see Section 3.1) gets introduced in this document so the speaker can advertise its color capability 🌸
In PCRpt, PCUpd, and PCInitiate messages, the LSP object [RFC8231] [RFC8281] is a mandatory inclusion. It carries info specific to the target LSP. This doc introduces a TLV called the COLOR TLV (see Section 3.2), which MAY be carried in the LSP object, to carry the color attribute tied to that LSP. Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV shows up in the LSP object more than once, only the first occurrence gets processed, and any others MUST be ignored 🙅♀️
A PCEP speaker that has advertised color capability MUST NOT send a COLOR TLV encoded in the LSP object to a PCEP Peer [RFC5440] that hasn't advertised color capability. A PCEP speaker that advertises both color capability and SR Policy Association [RFC9862] capability MUST NOT send a COLOR TLV encoded in the LSP object for SR Paths. If the COLOR TLV shows up in the LSP object of a message that carries an ASSOCIATION object of type SR Policy Association [RFC9862], it is ignored. In that case the color encoded in the SR Policy Association takes precedence 👑
If a PCC can't 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 when a PCC implementation doesn't 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 [RFC8745], they are all expected to have the same color attached. If a PCEP speaker spots an inconsistency in the color associated with LSPs in 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) 🚨
3. Protocol Extensions 🌸
3.1. Color Capability 🦋
Section 7.1.1 of [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV flags. This next flag tells everyone whether 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 💖
3.2. COLOR TLV 🎀
Here's the shape of the COLOR TLV. Look at it, it's giving architecture 😭
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: COLOR TLVThe fields are:
- Type:
67 - Length:
4 - Color: a 4-byte field that carries the actual color value (specified as an unsigned integer). A value of zero is allowed 🌈
4. Security Considerations 💀
Real talk, this part is serious, so we're keeping it dramatic 😤
This document defines a TLV for color and a flag for color capability negotiation. Those don't add any security concerns beyond the ones already 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 🛡️
5. Manageability Considerations 🧚
This section follows the advice and guidance of [RFC6123] 💜
5.1. Control of Function through Configuration and Policy ⚙️
An implementation supporting this document SHOULD allow the operator to turn the PCEP color capability advertisement on and off (Section 3.1). An implementation supporting this document SHOULD also allow color assignment to be configured for a TE Tunnel or an SR Policy. A PCC MAY have a local policy configuration that specifies how the color tag is used. That policy configuration is outside the scope of this document 🍓
5.2. Information and Data Models 📊
An implementation supporting this document SHOULD allow color to be included in the data model used to retrieve the operational state of a TE Tunnel or an SR Policy. The YANG model in [YANG-TE] could be used to retrieve the operational state of a TE Tunnel, and the YANG model in [SR-POLICY-YANG] could be used to retrieve the operational state of an SR Policy 🧠
5.3. Liveness Detection and Monitoring 👁️
The extensions defined in this document don't need any additional liveness detection and monitoring support. For more info, see [RFC5440] and [RFC5886] 💫
5.4. Verifying Correct Operation ✅
The operator MAY retrieve the operational state of TE Paths to verify whether they're tagged with the correct intended color 🔍
5.5. Requirements on Other Protocols 🫠
This document places no explicit requirements on other protocols. Easy 🌸
5.6. Impact on Network Operation 🌐
The impact on network operations depends on how the color tag gets used in the deployment. That's outside the scope of this document 🤷♀️
6. IANA Considerations 👑
6.1. 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 shown in Table 1 🦋
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 67 | Color | RFC 9863 |
+-------+-------------+-----------+
Table 16.2. STATEFUL-PCE-CAPABILITY TLV Flag Field 🎀
okay so IANA has given a bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry, which lives in the "Path Computation Element Protocol (PCEP) Numbers" registry group 💅 the bit is 20, it's called COLOR-CAPABILITY, and it points back to RFC 9863 🌈
+=======+==================+===========+
| Value | Description | Reference |
+=======+==================+===========+
| 20 | COLOR-CAPABILITY | RFC 9863 |
+-------+------------------+-----------+
Table 26.3. PCEP-Error Object 💌
so for Error-Type=19 (Invalid Operation) in the "PCEP-ERROR Object Error Types and Values" registry (same "Path Computation Element Protocol (PCEP) Numbers" group, obviously 🙈), IANA added two new Error-values 😭✨ they're 31: Invalid Color and 32: Inconsistent Color, both referencing RFC 9863
+============+===================+===================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+===================+===================+===========+
| 19 | Invalid Operation | 31: Invalid Color | RFC 9863 |
| | +-------------------+-----------+
| | | 32: Inconsistent | RFC 9863 |
| | | Color | |
+------------+-------------------+-------------------+-----------+
Table 36.4. LSP-ERROR-CODE TLV Error Code Field 🦋
this one is a little tea ☕ a draft version of this doc had added an error code to the "LSP-ERROR-CODE TLV Error Code Field" registry (also in the PCEP Numbers group), and IANA had early-allocated it. later on, though, IANA marked it as deprecated, so it's not something you should go looking to use 🙅♀️ here's the entry they kept around for the record:
+=======+================================+===========+
| Value | Meaning | Reference |
+=======+================================+===========+
| 9 | Deprecated (Unsupported Color) | RFC 9863 |
+-------+--------------------------------+-----------+
Table 47. References 📚
7.1. Normative References 🫶
these are the must-read ones the spec leans on (the ones that really matter, bestie) ✨
[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/info/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/info/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/info/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/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[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/info/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[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/info/rfc8664>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing (SR) Policy Candidate Paths", RFC 9862,
DOI 10.17487/RFC9862, October 2025,
<https://www.rfc-editor.org/info/rfc9862>.7.2. Informative References 🌸
these are the extra-credit reads, the background and related stuff that's nice to know but not required 🧚
[RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
Loop Prevention Mechanism", RFC 3063,
DOI 10.17487/RFC3063, February 2001,
<https://www.rfc-editor.org/info/rfc3063>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<https://www.rfc-editor.org/info/rfc5886>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[SR-POLICY-YANG]
Saleh, T., Raza, S. K., Zhuang, S., Matsushima, S., and V.
P. Beeram, "YANG Data Model for Segment Routing Policy",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
policy-yang-06, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-06>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths, and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-39, 17
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-39>.Acknowledgments 💖
the authors wanted to give a big shoutout to Kaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew Stone, Diego Achaval, and Narasimha Kommuri 🫶 thank you for reviewing and suggesting stuff, you're literally the reason this came together ✨
Contributors 🌈
the following person also contributed to this document 💜
Quan Xiong ZTE Corporation Email: xiong.quan@zte.com.cn
Authors' Addresses 🦋
here's who wrote it, plus where to find them 💅
Balaji Rajagopalan Juniper Networks Email: balajir@juniper.net
Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net
Shaofu Peng ZTE Corporation Email: peng.shaofu@zte.com.cn
Mike Koldychev Ciena Corporation Email: mkoldych@proton.me
Gyan Mishra Verizon Communications Inc. Email: gyan.s.mishra@verizon.com
📦 where this page comes from
- ietf: rfc9863 2025-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms