<?xmlversion="1.0"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3063 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3063.xml"> <!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> <!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml"> <!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"> <!ENTITY RFC5329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5329.xml"> <!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"> <!ENTITY RFC5886 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5886.xml"> <!ENTITY RFC6123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6123.xml"> <!ENTITY RFC7308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7308.xml"> <!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"> <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml"> <!ENTITY RFC8253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253.xml"> <!ENTITY RFC8281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xml"> <!ENTITY RFC8408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8408.xml"><!ENTITYRFC8664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xml">nbsp " "> <!ENTITYRFC8745 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8745.xml">zwsp "​"> <!ENTITYRFC9012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9012.xml">nbhy "‑"> <!ENTITYRFC9256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml"> <!ENTITY RFC9325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9325.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-pce-pcep-color-12" number="9863" updates="" obsoletes="" ipr="trust200902" submissionType="IETF"consensus="true">consensus="true" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" xml:lang="en"> <front> <title abbrev="PCEP Color">Path Computation Element Protocol (PCEP) Extension for Color</title> <seriesInfo name="RFC" value="9863"/> <author initials="B." surname="Rajagopalan" fullname="Balaji Rajagopalan"> <organization>Juniper Networks</organization> <address> <email>balajir@juniper.net</email> </address> </author> <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram"> <organization>Juniper Networks</organization> <address> <email>vbeeram@juniper.net</email> </address> </author> <author initials="S." surname="Peng" fullname="Shaofu Peng"> <organization>ZTE Corporation</organization> <address> <email>peng.shaofu@zte.com.cn</email> </address> </author> <author fullname="Mike Koldychev" initials="M." surname="Koldychev"> <organization>Ciena Corporation</organization> <address> <email>mkoldych@proton.me</email> </address> </author> <author fullname="Gyan Mishra" initials="G." surname="Mishra"> <organization>Verizon Communications Inc.</organization> <address> <email>gyan.s.mishra@verizon.com</email> </address> </author> <date month="September" year="2025"/><area>Routing</area> <workgroup>PCE Working Group</workgroup><area>RTG</area> <workgroup>pce</workgroup> <keyword>color</keyword> <abstract> <t> 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. </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor='intro'>anchor="intro"> <name>Introduction</name> <t> A Traffic Engineering (TE) tunnel(<xref target="RFC3209"/>)<xref target="RFC3209"/> or Segment Routing (SR) policy(<xref target="RFC9256"/>)<xref target="RFC9256"/> 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(<xref target="RFC9012"/>)<xref target="RFC9012"/> or SR policy(<xref target="RFC9256"/>).<xref target="RFC9256"/>. The termcolor"color" used in this document must not be interpreted as the'thread color'"thread color" specified in <xref target="RFC3063"/> or the'resource color'"resource color" (also referred to as'link color')"link color") specified in <xref target="RFC3630"/>, <xref target="RFC5329"/>, <xreftarget ="RFC5305"/>target="RFC5305"/>, and <xref target="RFC7308"/>. </t> <t> <xref target="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. <xref target="RFC8281"/> specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. <xref target="RFC8664"/> specifies extensions that enable stateful control of SR paths via PCEP. </t> <t> 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 <xref target="RFC8408"/> or Segment Routing <xreftarget ="RFC8664"/>).target="RFC8664"/>). The only exception where the extensions defined in this documentMUST NOT<bcp14>MUST NOT</bcp14> be used to carry the color attribute is for SR paths established using the extensions defined in <xreftarget="I-D.ietf-pce-segment-routing-policy-cp"/>.target="RFC9862"/>. For these SR paths, the associated color is already included as part of the SR policy identifier encoding. </t> <t> 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. </t><section title="Requirements Language"> <t>The<section> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section><section title="Protocol Operation"><section> <name>Protocol Operation</name> <t> 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 <xref target="RFC8231"/>. A STATEFUL-PCE-CAPABILITY TLV Flag(See(see <xref target="Color-Cap"/>) is introduced in this document to enable the PCEP speaker to advertise color capability. </t> <t> In PCRpt, PCUpd, and PCInitiate messages, the LSP object(<xref target="RFC8231"/>,<xreftarget="RFC8281"/>)target="RFC8231"/> <xref target="RFC8281"/> is a mandatory inclusion and is used to carry information specific to the target LSP. A TLV called the Color TLV (see <xref target="TLV-Format"/>), whichMAY<bcp14>MAY</bcp14> be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP. Only one COLOR TLVSHOULD<bcp14>SHOULD</bcp14> 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 othersMUST<bcp14>MUST</bcp14> be ignored. </t> <!--[rfced] We note that this document uses terms such as "PCEP Peer", "TE Tunnel", and "SR Policy" with the second word capitalized. If the intention is to use these terms with a specific meaning, would you like to add a sentence stating where to find that definition? For example: Perhaps: This document uses the following terms: PCEP Peer as defined in [RFC5440] SR Policy as defined in [RFC8402] --> <t> A PCEP speaker that has advertised color capabilityMUST NOT<bcp14>MUST NOT</bcp14> 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 <xref target="RFC9862"/> capability(<xref target="I-D.ietf-pce-segment-routing-policy-cp"/>) MUST NOT<bcp14>MUST NOT</bcp14> 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 messagewhichthat carries an ASSOCIATION object of type SR Policy Association(<xref target="I-D.ietf-pce-segment-routing-policy-cp"/>).<xref target="RFC9862"/>. The color encoded in the SR Policy Association takes precedence in such a scenario. </t> <t> If a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCCMUST<bcp14>MUST</bcp14> reject the message and send a PCErr message withError-type=19Error-Type=19 (Invalid Operation) anderror-value=TBD1Error-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. </t> <t> When LSPs that belong to the same TE tunnel are within the same Path Protection Association Group <xref target="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, itMUST<bcp14>MUST</bcp14> reject the message carrying the inconsistent color and send a PCErr message withError-type=19Error-Type=19 (Invalid Operation) anderror-value=TBD2Error-value=32 (Inconsistent color). </t> </section> <sectiontitle="Protocol Extensions"anchor="Proto-Ext"> <name>Protocol Extensions</name> <sectiontitle="Color Capability"anchor="Color-Cap"> <name>Color Capability</name> <t>Section 7.1.1 of<xreftarget="RFC8231"/>target="RFC8231" sectionFormat="of" section="7.1.1"/> defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability: </t><t> <list> <t> C-bit<dl spacing="normal" newline="false"> <dt>C-bit (Bit20): A20):</dt><dd>A PCE/PCC indicates that it supports the color capability defined in this document by setting thisbit. </t> </list> </t>bit.</dd> </dl> </section> <sectiontitle="Color TLV"anchor="TLV-Format"> <name>Color TLV</name> <figureanchor="color-tlv" title="Color TLV">anchor="color-tlv"> <name>Color TLV</name> <artworkxml:space="preserve" align="left">align="left"><![CDATA[ 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t><!-- [rfced] In many RFCs, the text following a TLV diagram is a definition list rather than a paragraph. Would you like to update this as follows? Current: Type has the value 67. Length carries a value of 4. The'color'"color" field is4-bytes long,4 bytes long and carries the actual color value (specified as an unsigned integer). A color value of zero is allowed. Perhaps: 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. --> <t> Type has the value 67. Length carries a value of 4. The "Color" field is 4 bytes long and carries the actual color value (specified as an unsigned integer). A Color value of zero is allowed. </t> </section> </section> <sectiontitle='Security Considerations' anchor='sec-con'>anchor="sec-con"> <name>Security Considerations</name> <t> 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 <xreftarget='RFC5440'/>,target="RFC5440"/>, <xreftarget='RFC8231'/>target="RFC8231"/>, and <xreftarget='RFC8281'/>.target="RFC8281"/>. </t> <t> An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in <xreftarget='RFC8253'/>target="RFC8253"/> and <xreftarget='RFC9325'/>target="RFC9325"/> can be used to protect against this attack. </t> </section> <sectiontitle='Manageability Considerations' anchor='mgmt-con'>anchor="mgmt-con"> <name>Manageability Considerations</name> <t> This section follows the advice and guidance of <xreftarget='RFC6123'/>.target="RFC6123"/>. </t> <sectiontitle='Controlanchor="mgmt-con-cfp"> <name>Control of Function through Configuration andPolicy' anchor='mgmt-con-cfp'>Policy</name> <t> An implementation supporting this documentSHOULD<bcp14>SHOULD</bcp14> allow the operator to turn on and off the PCEP color capability advertisement (<xreftarget='Color-Cap'/>).target="Color-Cap"/>). An implementation supporting this documentSHOULD<bcp14>SHOULD</bcp14> allow the configuration of color assignment to a TE Tunnel or an SR Policy. A PCCMAY<bcp14>MAY</bcp14> have a local policy configuration that specifies how the color tag is used. This policy configuration is outside the scope of this document. </t> </section> <sectiontitle='Informationanchor="mgmt-con-idm"> <name>Information and DataModels' anchor='mgmt-con-idm'>Models</name> <t> An implementation supporting this documentSHOULD<bcp14>SHOULD</bcp14> 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 <xref target="I-D.ietf-teas-yang-te"/> could be used to retrieve the operational state of a TE tunnel, and the YANG model in <xref target="I-D.ietf-spring-sr-policy-yang"/> could be used to retrieve the operational state of an SR policy. </t> </section> <sectiontitle='Livenessanchor="mgmt-con-ldm"> <name>Liveness Detection andMonitoring' anchor='mgmt-con-ldm'>Monitoring</name> <t> The extensions defined in this document do not require any additional liveness detection and monitoring support. See <xreftarget='RFC5440'/>target="RFC5440"/> and <xreftarget='RFC5886'/>target="RFC5886"/> for more information. </t> </section> <sectiontitle='Verifyinganchor="mgmt-con-vco"> <name>Verifying CorrectOperation' anchor='mgmt-con-vco'>Operation</name> <t> The operatorMAY<bcp14>MAY</bcp14> retrieve the operational state of TE Paths to verify if they are tagged with the correct intended color. </t> </section> <sectiontitle='Requirementsanchor="mgmt-con-prot"> <name>Requirements on OtherProtocols' anchor='mgmt-con-prot'>Protocols</name> <t> This document places no explicit requirements on other protocols. </t> </section> <sectiontitle='Impactanchor="mgmt-con-ino"> <name>Impact on NetworkOperation' anchor='mgmt-con-ino'>Operation</name> <t> The impact on network operations depends on how the color tag is used in the deployment. This is outside the scope of this document. </t> </section> </section> <sectionanchor="IANA" title="IANA Considerations"> <section title="PCEPanchor="IANA"> <name>IANA Considerations</name> <section> <name>PCEP TLV TypeIndicator">Indicator</name> <t>This document introducesIANA has assigned a value in the "PCEP TLV Type Indicators" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:<figure> <artwork align="left"><![CDATA[ Value Description Reference ---------------------------------------------- 67 Color This document ]]></artwork> </figure> Note: The code point specified for the TLV Type Indicator is an early allocation by IANA.</t> <table> <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead> <tbody><tr><td>67</td><td>Color</td><td>RFC 9863</td></tr></tbody> </table> </section><section title="STATEFUL-PCE-CAPABILITY<section> <name>STATEFUL-PCE-CAPABILITY TLV FlagField">Field</name> <t>This document introducesIANA 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:<figure> <artwork align="left"><![CDATA[ Value Description Reference ---------------------------------------------- 20 COLOR-CAPABILITY This document ]]></artwork> </figure> Note: The code point specified for the STATEFUL-PCE-CAPABILITY TLV Flag is an early allocation by IANA.</t></section> <section title="PCEP-Error Object"><table> <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead> <tbody><tr><td>20</td><td>COLOR-CAPABILITY</td><td>RFC 9863</td></tr></tbody> </table> </section> <section> <name>PCEP-Error Object</name> <t>This document introducesIANA 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:<figure> <artwork align="left"><![CDATA[ Error- Meaning Error-value Reference Type ------------------------------------------------------------------ 19 Invalid Operation TBD1:</t> <table> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td rowspan="2">19</td> <td rowspan="2">Invalid Operation</td> <td>31: InvalidColor This document TBD2:Color</td> <td>RFC 9863</td> </tr> <tr> <td>32: InconsistentColor This document ]]></artwork> </figure> </t>Color</td> <td>RFC 9863</td> </tr> </tbody> </table> </section><section title="LSP-ERROR-CODE<section> <name>LSP-ERROR-CODE TLV Error CodeField">Field</name> <t>An earlierA 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. </t> <t> IANAis requested to cancel the early allocation made which is not needed anymore. As per the instructions from the chairs, please markhas marked it as deprecated. </t><t> <figure> <artwork align="left"><![CDATA[ Value Meaning Reference ------------------------------------------------------ 9 Deprecated<table> <thead><tr><th>Value</th><th>Meaning</th><th>Reference</th></tr></thead> <tbody> <tr> <td>9</td> <td>Deprecated (UnsupportedColor) This document ]]></artwork> </figure> </t>Color)</td> <td>RFC 9863</td> </tr> </tbody> </table> </section> </section><section title="Implementation Status"> <t>[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.]</t> <t>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 <xref target="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.</t> <t>According to <xref target="RFC7942"/>, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve</middle> <back> <displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/> <displayreference target="I-D.ietf-teas-yang-te" to="YANG-TE"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8745.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/> <reference anchor="RFC9862" target="https://www.rfc-editor.org/info/rfc9862"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths</title> <author initials="M." surname="Koldychev" fullname="Mike Koldychev"> <organization>Ciena Corporation</organization> </author> <author initials="S." surname="Sivabalan" fullname="Siva Sivabalan"> <organization>Ciena Corporation</organization> </author> <author initials="S." surname="Sidor" fullname="Samuel Sidor"> <organization>Cisco Systems, Inc.</organization> </author> <author initials="C." surname="Barth" fullname="Colby Barth"> <organization>Juniper Networks, Inc.</organization> </author> <author initials="S." surname="Peng" fullname="Shuping Peng"> <organization>Huawei Technologies</organization> </author> <author initials="H." surname="Bidgoli" fullname="Hooman Bidgoli"> <organization>Nokia</organization> </author> <date month="September" year="2025"/> </front> <seriesInfo name="RFC" value="9862"/> <seriesInfo name="DOI" value="10.17487/RFC9862"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3063.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5886.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6123.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/> <!-- [I-D.ietf-teas-yang-te] draft-ietf-teas-yang-te-38 IESG State: I-D Exists asevidenceofvaluable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information07/15/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-yang-te.xml"/> <!-- [I-D.ietf-spring-sr-policy-yang] draft-ietf-spring-sr-policy-yang-05 IESG State: I-D Exists asthey see fit".</t> <t> At the time of publicationofthis version, there are no known implementations. Juniper Networks has plans to implement the extensions defined in this document.</t> </section>07/15/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-policy-yang.xml"/> </references> </references> <sectiontitle='Acknowledgments'> <t> Thenumbered="false"> <name>Acknowledgments</name> <t>The authors would like to thankKaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew Stone, Diego Achaval, and Narasimha Kommuri<contact fullname="Kaliraj Vairavakkalai"/>, <contact fullname="Colby Barth"/>, <contact fullname="Natrajan Venkataraman"/>, <contact fullname="Tarek Saad"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Andrew Stone"/>, <contact fullname="Diego Achaval"/>, and <contact fullname="Narasimha Kommuri"/> for their review andsuggestions. </t>suggestions.</t> </section> <sectiontitle='Contributors'>numbered="false"> <name>Contributors</name> <t>The following people have contributed to this document:</t><author initials="Q." surname="Xiong"<contact fullname="Quan Xiong"> <organization>ZTE Corporation</organization> <address> <email>xiong.quan@zte.com.cn</email> </address></author></contact> </section></middle> <back> <references title='Normative References'> &RFC2119; &RFC8174; &RFC5440; &RFC8231; &RFC8253; &RFC8281; &RFC8408; &RFC8664; &RFC8745; &RFC9012; &RFC9325; <?rfc include='reference.I-D.ietf-pce-segment-routing-policy-cp.xml'?> </references> <references title='Informative References'> &RFC3063; &RFC3209; &RFC3630; &RFC5305; &RFC5329; &RFC5886; &RFC6123; &RFC7308; &RFC7942; &RFC9256; <?rfc include='reference.I-D.ietf-teas-yang-te.xml'?> <?rfc include='reference.I-D.ietf-spring-sr-policy-yang.xml'?> </references></back> <!-- [rfced] Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. COLOR TLV vs. Color TLV OPEN vs. open (one instance of each) TE Tunnel vs. TE tunnel SR Policy vs. SR policy --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>