<?xmlversion="1.0" encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- 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. --><!ENTITYRFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">zwsp "​"> <!ENTITYRFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">nbhy "‑"> <!ENTITYI-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="no" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-pce-segment-routing-policy-cp-27" number="9862" consensus="true" ipr="trust200902"updates="8231">updates="8231" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add[rfced] This document updates RFC 8231. Please review theattributes updates="NNNN"errata reported for RFC 8231 <https://www.rfc-editor.org/errata/rfc8231> andobsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER *****confirm that none are relevant to the content of this document. --> <front> <title abbrev="PCEP SR Policy"> Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths</title> <seriesInfo name="RFC" value="9862"/> <author fullname="Mike Koldychev" initials="M." surname="Koldychev"> <organization>Ciena Corporation</organization> <address> <postal> <street>385 Terry Fox Dr.</street> <city>Kanata</city> <region>Ontario</region> <code>K2K 0L1</code> <country>Canada</country> </postal> <email>mkoldych@proton.me</email> </address> </author> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <organization>Ciena Corporation</organization> <address> <postal> <street>385 Terry Fox Dr.</street> <city>Kanata</city> <region>Ontario</region> <code>K2K 0L1</code> <country>Canada</country> </postal> <email>ssivabal@ciena.com</email> </address> </author> <author fullname="Samuel Sidor" initials="S." surname="Sidor"> <organization>Cisco Systems, Inc.</organization> <address> <postal> <street>Eurovea Central 3.</street> <city>Bratislava</city> <code>811 09</code> <country>Slovakia</country> </postal> <email>ssidor@cisco.com</email> </address> </author> <author fullname="Colby Barth" initials="C." surname="Barth"> <organization>Juniper Networks, Inc.</organization> <address> <email>cbarth@juniper.net</email> </address> </author> <author fullname="Shuping Peng" initials="S." surname="Peng"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Campus, No. 156 Beiqing Rd.</street> <city>Beijing</city><region/><code>100095</code> <country>China</country> </postal><phone/> <facsimile/><email>pengshuping@huawei.com</email><uri/></address> </author> <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli"> <organization>Nokia</organization> <address> <email>hooman.bidgoli@nokia.com</email> </address> </author><date/> <workgroup>PCE Working Group</workgroup><date year="2025" month="September"/> <area>RTG</area> <workgroup>PCE</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t> A Segment Routing (SR) Policy is an ordered list ofinstructions,instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more candidate paths. </t> <t> This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path(LSP),(LSP) without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). </t> </abstract> </front> <middle> <section anchor="Introduction"title="Introduction"> <t>Segmentnumbered="true" toc="default"> <name>Introduction</name> <t>"Segment Routing(SR)PolicyArchitectureArchitecture" <xreftarget="RFC9256"/>target="RFC9256" format="default"/> details the concepts of Segment Routing (SR) Policy <xreftarget="RFC8402"/>target="RFC8402" format="default"/> and approaches to steering traffic into an SR Policy.</t><t>Path<t>"Path Computation Element Communication Protocol (PCEP) Extensions for SegmentRoutingRouting" <xreftarget="RFC8664"/>target="RFC8664" format="default"/> specifies extensions to the PCEP that allow a stateful Path Computation Element (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 an SR domain. Although PCEP extensions introduced in <xreftarget="RFC8664"/> enablestarget="RFC8664" format="default"/> enable the creation of SR-TE paths, these do not constitute SR Policies as defined in <xreftarget="RFC9256"/> and thereforetarget="RFC9256" format="default"/>. Therefore, they lack supportfor: <list style="symbols">for:</t> <ul spacing="normal"> <li> <t>Association of SR Policy Candidate Paths signaled via PCEP with Candidate Paths of the same SR Policy signaled via other sources (e.g., local configuration or BGP).</t> </li> <li> <t>Association of an SR Policy with an intent via color, enabling headend-based steering of BGP service routes over SR Policies provisioned via PCEP.</t></list> </t> <t>PCEP</li> </ul> <t>"Path Computation Element Communication Protocol (PCEP) Extensions forestablishing relationshipsEstablishing Relationships betweensetsSets of Label Switched Paths(LSPs)(LSPs)" <xreftarget="RFC8697"/>target="RFC8697" format="default"/> introduces a generic mechanism to create a grouping of LSPswhichthat is called anAssociation.</t>"Association".</t> <t>An SR Policy is associated with one or more candidate paths. A candidate path is the unit for signalingofan SR Policy to a headend as described inSection 2.2 of<xreftarget="RFC9256"/>.target="RFC9256" section="2.2"/>. This document extends <xreftarget="RFC8664"/>target="RFC8664" format="default"/> to support signaling SR Policy Candidate Paths as LSPs and to signal Candidate Path membership in an SR Policy by means of the Association mechanism. A PCEP Association corresponds toaan SR Policy andaan LSP corresponds to a Candidate Path. The unit of signaling in PCEP is the LSP,thusthus, all the information related to an SR Policy is carried at the Candidate Pathlevel. </t> <t>Also,level.</t> <!-- [rfced] FYI, we added "for" here to make the meaning of the parenthetical more clear. Please let us know if you prefer otherwise. Original: Also, this document updates Section 5.8.2 of<xref target="RFC8231"/>,[RFC8231], making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs setup using Path Setup Type 1 (Segment Routing)<xref target="RFC8664"/>[RFC8664] and Path Setup Type 3 (SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges and simplifying implementation. [...] SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (Segment Routing) or 3 (SRv6). Current: Also, this document updates Section 5.8.2 of [RFC8231], making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs that are set up using Path Setup Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 (for SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges and simplifying implementation. [...] SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (for Segment Routing) or 3 (for SRv6). --> <t>Also, this document updates <xref target="RFC8231" section="5.8.2"/>, making the use of Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages optional for LSPs that are set up using Path Setup Type 1 (for Segment Routing) <xref target="RFC8664" format="default"/> and Path Setup Type 3 (for SRv6) <xreftarget="RFC9603"/>target="RFC9603" format="default"/> with the aim of reducing the PCEP message exchanges and simplifying implementation.</t> <section anchor="Language"title="Requirements Language"> <t>Thenumbered="true" toc="default"> <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 shownhere.</t>here. </t> </section> </section><!-- Introduction --><section anchor="Terminology"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>This document uses the following terms defined in <xreftarget="RFC5440"/>: ERO, PCC, PCE, PCEP Peer, and PCEP speaker.</t>target="RFC5440"/>:</t> <ul> <li>Explicit Route Object (ERO)</li> <li>Path Computation Client (PCC)</li> <li>Path Computation Element (PCE)</li> <li>PCEP Peer</li> <li>PCEP speaker</li> </ul> <t>This document uses the following term defined in <xreftarget="RFC3031"/>: LSP.</t>target="RFC3031"/>:</t> <ul> <li>Label Switched Path (LSP)</li> </ul> <t>This document uses the following term defined in <xreftarget="RFC9552"/>: BGP-LS.</t>target="RFC9552"/>:</t> <ul> <li>Border Gateway Protocol - Link State (BGP-LS)</li> </ul> <t>The following other terms are used in thisdocument: <list style="hanging"> <t hangText="Endpoint:"> Thedocument:</t> <dl> <dt>Endpoint:</dt> <dd>The IPv4 or IPv6 endpoint address of an SR Policy, as described inSection 2.1 of<xreftarget="RFC9256"/>.</t> <t hangText="Color:"> Thetarget="RFC9256" section="2.1"/>.</dd> <dt>Color:</dt> <dd>The 32-bit color of an SR Policy, as described inSection 2.1 of<xreftarget="RFC9256"/>.</t> <t hangText="Protocol-Origin:"> Thetarget="RFC9256" section="2.1"/>.</dd> <dt>Protocol-Origin:</dt> <dd>The protocol that was used to create a Candidate Path, as described inSection 2.3 of<xreftarget="RFC9256"/>.</t> <t hangText="Originator:"> Atarget="RFC9256" section="2.3"/>.</dd> <dt>Originator:</dt> <dd>A device that created a Candidate Path, as described inSection 2.4 of<xreftarget="RFC9256"/>.</t> <t hangText="Discriminator:"> Distinguishestarget="RFC9256" section="2.4"/>.</dd> <dt>Discriminator:</dt> <dd>Distinguishes Candidate Paths created by the same device, as described inSection 2.5 of<xreftarget="RFC9256"/>.</t> <t hangText="Association Parameters:"> As described in <xref target="RFC8697"/>, referstarget="RFC9256" section="2.5"/>.</dd> <dt>Association parameters:</dt> <dd>Refers to the key data that uniquely identifies anAssociation.</t> <t hangText="Association Information:"> AsAssociation, as described inSection 6.1.4 of<xreftarget="RFC8697"/>, referstarget="RFC8697" format="default"/>.</dd> <dt>Association information:</dt> <dd>Refers to information related to AssociationType.</t> <t hangText="SRType, as described in <xref target="RFC8697" section="6.1.4"/>.</dd> <dt>SR PolicyLSP:"> AnLSP:</dt> <dd>An LSP setup using Path Setup Type <xreftarget="RFC8408"/>target="RFC8408" format="default"/> 1(Segment(for Segment Routing) or 3(SRv6).</t> <t hangText="SR(for SRv6).</dd> <dt>SR PolicyAssociation:"> AAssociation (SRPA):</dt> <dd>A newassociation typeAssociation Type used to group candidate paths belonging to the same SR Policy. Depending on the discussion context, it can refer to the PCEP ASSOCIATION object of an SR Policy type or to a group of LSPs that belong to theassociation.</t> </list> <t> Theassociation.</dd> </dl> <t>The base PCEP specification <xreftarget="RFC4655"/>target="RFC4655" format="default"/> originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setuptypes,types such asSRv6,SRv6 has been introduced <xreftarget="RFC9603"/>.target="RFC9603" format="default"/>. The term "LSP" is used extensively in PCEPspecifications and,specifications, and in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSPObjectobject as specified in <xreftarget="RFC8231"/>.</t> </t>target="RFC8231" format="default"/>).</t> </section><!-- Terminology --><section anchor="Overview"title="Overview">numbered="true" toc="default"> <name>Overview</name> <t> The SR Policy is represented by a new type of PCEP Association, called the SR Policy Association (SRPA) (see <xreftarget="Association"/>).target="Association" format="default"/>). The SR Policy Candidate Paths of a specific SR Policy are the LSPs within the same SRPA. The extensions in this document specify the encoding of a single segment list within an SR Policy Candidate Path. Encoding of multiple segment lists is outside the scope of this document and is specified in <xreftarget="I-D.ietf-pce-multipath"/>.target="I-D.ietf-pce-multipath" format="default"/>. </t> <t>An SRPA carries three pieces of information: SR Policy Identifier, SR Policy Candidate Path Identifier, and SR Policy Candidate Path Attribute(s).</t> <t> This document also specifies some additional information that is not encoded as part of an SRPA:Computation Prioritycomputation priority of the LSP, Explicit Null Label Policy for the unlabeled IP packets andDrop-upon-invalidDrop-Upon-Invalid behavior for traffic steering when the LSP is operationally down (see <xreftarget="Other-mechanisms"/>).target="Other-mechanisms" format="default"/>). </t> </section><!-- Overview --><section anchor="Association"title="SRnumbered="true" toc="default"> <name>SR Policy Association(SRPA)">(SRPA)</name> <t> Per <xreftarget="RFC8697"/>,target="RFC8697" format="default"/>, LSPs are associated with other LSPs with which they interact by adding them to a common association group. An association group is uniquely identified by the combination of the following fields in the ASSOCIATION object (<xref target="RFC8697" sectionFormat="of"section="6.1"/>):section="6.1" format="default"/>): Association Type, Association ID, Association Source, and (if present) Global Association Source, or Extended Association ID. These fields are referred to asAssociation Parameters"association parameters" (<xreftarget="AssociationParameters"/>).target="AssociationParameters" format="default"/>). </t> <t> <xreftarget="RFC8697"/>target="RFC8697" format="default"/> specifies the ASSOCIATIONObjectobject with two Object-Types for IPv4 and IPv6whichthat includes the field"Association Type".Association Type. This document defines a new AssociationtypeType (6) "SR Policy Association" for an SRPA. </t> <t> <xreftarget="RFC8697"/>target="RFC8697" format="default"/> specifies the mechanism for the capability advertisement of the Association Types supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for theSR Policy AssociationSRPA TypeMUST<bcp14>MUST</bcp14> be done before using the SRPA. To that aim, a PCEP speakerMUST<bcp14>MUST</bcp14> include the SRPA Type (6) in the ASSOC-Type-List TLV andMUST<bcp14>MUST</bcp14> receive the same from the PCEP peer before using the SRPA (<xreftarget="Association-Type"/>).</t>target="Association-Type" format="default"/>).</t> <t> An SRPAMUST<bcp14>MUST</bcp14> be assigned for all SR Policy LSPs by the PCEP speaker originating the LSP if the capability was advertised by both PCEP speakers. If the above condition is not satisfied, then the receiving PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 6 "Mandatory ObjectMissing", Error-ValueMissing"</li> <li>Error-value =TBD122 "Missing SR PolicyAssociation". </t>Association"</li> </ul> <t> A given LSPMUST<bcp14>MUST</bcp14> belong toat mostoneSRPA,SRPA at most, since an SR Policy Candidate Path cannot belong to multiple SR Policies. If a PCEP speaker receives a PCEP message requesting to join more than one SRPA for the same LSP, then the PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 26 "AssociationError", Error-ValueError"</li> <li>Error-value = 7 "Cannot join the associationgroup". </t>group"</li> </ul> <t> The existing behavior for the use of Binding SID (BSID) with an SR Policy is already documented in <xreftarget="RFC9604"/>.target="RFC9604" format="default"/>. If BSID value allocationfailed,failed because of conflict with the BSID used by another policy, then the PCEP peerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 32 "Binding label/SIDfailure" and Error-valuefailure"</li> <li>Error-value = 2 "Unable to allocate the specified bindingvalue". </t>value"</li> </ul> <section anchor="SRPolicyIdentifier"title="SRnumbered="true" toc="default"> <name>SR PolicyIdentifier"> <t>SRIdentifier</name> <t>The SR Policy Identifier uniquely identifies an SR Policy <xreftarget="RFC9256"/>target="RFC9256" format="default"/> within the SR domain. The SR Policy Identifier is assigned by the PCEP peer originating the LSP andMUST<bcp14>MUST</bcp14> be uniform across all the PCEP sessions. Candidate Paths within an SR PolicyMUST<bcp14>MUST</bcp14> carry the same SR Policy Identifiers in their SRPAs. Candidate Paths within an SR PolicyMUST NOT<bcp14>MUST NOT</bcp14> change their SR Policy Identifiers for the lifetime of the PCEP session. If the above conditions are not satisfied, the receiving PCEP speakerMUST<bcp14>MUST</bcp14> send a PCEP Error (PCErr) messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 26 "AssociationError" and Error ValueError"</li> <li>Error-value = 20 "SR Policy IdentifierMismatch".Mismatch"</li> </ul> <t>The SR Policy Identifier consists of:</t><t> <list style="symbols"><ul spacing="normal"> <li> <t>Headend router where the SR Policy originates.</t> </li> <li> <t>Color of the SR Policy (<xreftarget="RFC9256"/>, Section 2.1).</t>target="RFC9256" sectionFormat="comma" section="2.1"/>).</t> </li> <li> <t>Endpoint of the SR Policy (<xreftarget="RFC9256"/>, Section 2.1).</t> </list> </t>target="RFC9256" sectionFormat="comma" section="2.1"/>).</t> </li> </ul> </section> <section anchor="SRPolicyCandidatePathIdentifier"title="SRnumbered="true" toc="default"> <name>SR Policy Candidate PathIdentifier"> <t>SRIdentifier</name> <t>The SR Policy Candidate Path Identifier uniquely identifies the SR Policy Candidate Path within the context of an SR Policy. The SR Policy Candidate Path Identifier is assigned by the PCEP peer originating the LSP. Candidate Paths within an SR PolicyMUST NOT<bcp14>MUST NOT</bcp14> change their SR Policy Candidate Path Identifiers for the lifetime of the PCEP session. Two or more Candidate Paths within an SR PolicyMUST NOT<bcp14>MUST NOT</bcp14> carry the same SR Policy Candidate Path Identifiers in their SRPAs. If the above conditions are not satisfied, the PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 26 "AssociationError" and Error ValueError"</li> <li>Error-value = 21 "SR Policy Candidate Path IdentifierMismatch".Mismatch"</li> </ul> <t>The SR Policy Candidate Path Identifier consists of:</t><t> <list style="symbols"> <t>Protocol Origin<ul spacing="normal"> <li> <t>Protocol-Origin (<xreftarget="RFC9256"/>, Section 2.3).</t>target="RFC9256" sectionFormat="comma" section="2.3"/>)</t> </li> <li> <t>Originator (<xreftarget="RFC9256"/>, Section 2.4).</t>target="RFC9256" sectionFormat="comma" section="2.4"/>)</t> </li> <li> <t>Discriminator (<xreftarget="RFC9256"/>, Section 2.5).</t> </list> </t>target="RFC9256" sectionFormat="comma" section="2.5"/>)</t> </li> </ul> </section> <section anchor="SRPolicyCandidatePathAttributes"title="SRnumbered="true" toc="default"> <name>SR Policy Candidate PathAttributes">Attributes</name> <t>SR Policy Candidate Path Attributes carry optional, non-key information about a Candidate Path andMAY<bcp14>MAY</bcp14> change during the lifetime of an LSP. SR Policy Candidate Path Attributesconsistsconsist of:</t><t> <list style="symbols"><ul spacing="normal"> <li> <t>Candidate Path preference (<xreftarget="RFC9256"/>, Section 2.7).</t>target="RFC9256" sectionFormat="comma" section="2.7"/>)</t> </li> <li> <t>Candidate Path name (<xreftarget="RFC9256"/>, Section 2.6).</t>target="RFC9256" sectionFormat="comma" section="2.6"/>)</t> </li> <li> <t>SR Policy name (<xreftarget="RFC9256"/>, Section 2.1).</t> </list> </t>target="RFC9256" sectionFormat="comma" section="2.1"/>)</t> </li> </ul> </section> <section anchor="AssociationParameters"title="Association Parameters"> <t> Pernumbered="true" toc="default"> <name>Association Parameters</name> <t>Per <xref target="RFC9256" sectionFormat="of"section="2.1"/>,section="2.1" format="default"/>, an SR Policy is identified through the<headend, color, endpoint> tuple. </t><Headend, Color, Endpoint> tuple.</t> <t>TheAssociation Parameters consistsassociation parameters consist of:</t><t> <list style="symbols"> <t>Association Type: Set<dl spacing="normal" newline="false"> <dt>Association Type:</dt><dd>Set to 6 "SR PolicyAssociation".</t> <t>AssociationAssociation".</dd> <dt>Association Source(IPv4/IPv6): Set(IPv4/IPv6):</dt><dd>Set to the headend value of the SR Policy, as defined in <xreftarget="RFC9256"/> Section 2.1.</t> <t>Associationtarget="RFC9256" sectionFormat="comma" section="2.1"/>.</dd> <dt>Association ID(16-bit): Always(16 bit):</dt><dd>Always set to the numeric value"1".</t> <t>Extended1.</dd> <dt>Extended Association IDTLV: MandatoryTLV:</dt><dd><t>Mandatory TLV forSR Policy Association.an SRPA. Encodes the Color and Endpoint of the SR Policy (<xreftarget="Extended-Association-ID-TLV-FORMAT"/>).</t> </list> </t>target="Extended-Association-ID-TLV-FORMAT" format="default"/>).</t> <figureanchor="Extended-Association-ID-TLV-FORMAT" title="Extendedanchor="Extended-Association-ID-TLV-FORMAT"> <name>Extended Association ID TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 = 31 | Length = 8 or 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Endpoint ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type:<!-- [rfced] We note that Figure 1 differs slightly from the other TLV format figures in this document. Specifically, Figure 1 contains values for Type and Length within the figure itself. Do you want to remove these values from Figure 1 for consistency with the other figures in this document? Figure 1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 31 | Length = 8 or 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FYI, we updated the first list item after Figure 1 for consistency with the other lists/figures. Original: Type: Extended Association ID TLV, type = 31 [RFC8697]. Current: Type: 31 for the Extended Association ID TLV [RFC8697]. --> <dl spacing="normal" newline="false"> <dt>Type:</dt><dd>31 for the Extended Association ID TLV <xreftarget="RFC8697"/>.</t> <t>Length: 8target="RFC8697" format="default"/>.</dd> <dt>Length:</dt><dd>8 octets if IPv4 address or 20 octets if IPv6 address is encoded in the Endpointfield.</t> <t>Color: unsignedfield.</dd> <dt>Color:</dt><dd>Unsigned non-zero 32-bit integer value, SR Policy color per <xref target="RFC9256" sectionFormat="of"section="2.1"/>.</t> <t>Endpoint: cansection="2.1" format="default"/>.</dd> <dt>Endpoint:</dt><dd>Can be either IPv4 (4 octets) or IPv6 address (16 octets). This valueMAY<bcp14>MAY</bcp14> be different from the one contained in the Destination address field in the END-POINTS object, or in the Tunnel Endpoint Address field in the LSP-IDENTIFIERS TLV (<xref target="RFC9256" sectionFormat="of"section="2.1"/>).</t>section="2.1" format="default"/>).</dd> </dl> </dd> </dl> <t>If a PCEP speaker receives an SRPA object whoseAssociation Parametersassociation parameters do not follow the above specification, then the PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 26 "AssociationError", Error-ValueError"</li> <li>Error-value = 20 "SR Policy IdentifierMismatch".</t>Mismatch"</li> </ul> <t>The encoding choice of theAssociation Parametersassociation parameters in this way is meant to guarantee that there is no possibility of a race condition when multiple PCEP speakers want to associate the same SR Policy at the same time. By adhering to this format, all PCEP speakers come up with the sameAssociation Parametersassociation parameters independently of each other based on the SR Policy parameters <xreftarget="RFC9256"/>.</t> <t> Thetarget="RFC9256" format="default"/>.</t> <t>The last hop of a computed SR Policy Candidate PathMAY<bcp14>MAY</bcp14> differ from the Endpoint contained in the<headend, color, endpoint><Headend, Color, Endpoint> tuple. An example use case is to terminate the SR Policy before reaching the Endpoint and have decapsulated traffic be forwarded the rest of the path to the Endpoint node using the native Interior Gateway Protocol (IGP) path(s). In this example, the destination of the SR Policy Candidate Paths will be some node before the Endpoint, but the Endpoint value is still used at the headend to steer traffic with that Endpoint IP address into the SR Policy. The Destination of the SR Policy Candidate Path is signaled using the END-POINTS object and/or the LSP-IDENTIFIERS TLV, per the usual PCEP procedure. When neither the END-POINTS object nor the LSP-IDENTIFIERS TLV is present, the PCEP speakerMUST<bcp14>MUST</bcp14> extract the destination from the Endpoint field in the SRPA Extended Association IDTLV. </t> <t> SRTLV.</t> <t>SR Policy with Color-Only steering is signaled with the Endpoint value set to unspecified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per <xref target="RFC9256" sectionFormat="of"section="8.8."/>. </t>section="8.8" format="default"/>.</t> </section><!-- AssociationParameters --><section anchor="AssociationInformation"title="Association Information">numbered="true" toc="default"> <name>Association Information</name> <t>The SRPA object may carry the following TLVs:</t><t> <list style="symbols"> <t>SRPOLICY-POL-NAME<dl spacing="normal" newline="false"> <dt>SRPOLICY-POL-NAME TLV (<xreftarget="Policy-name-tlv"/>): (optional)target="Policy-name-tlv" format="default"/>):</dt><dd>(optional) encodes the SR Policy Namestring.</t> <t>SRPOLICY-CPATH-IDstring.</dd> <dt>SRPOLICY-CPATH-ID TLV (<xreftarget="Cpath-identifier-tlv"/>): (mandatory)target="Cpath-identifier-tlv" format="default"/>):</dt><dd>(mandatory) encodes the SR Policy Candidate PathIdentifier.</t> <t>SRPOLICY-CPATH-NAMEIdentifier.</dd> <dt>SRPOLICY-CPATH-NAME TLV (<xreftarget="SRPOLICY-CPATH-NAME"/>): (optional)target="SRPOLICY-CPATH-NAME" format="default"/>):</dt><dd>(optional) encodes the SR Policy Candidate Path stringname.</t> <t>SRPOLICY-CPATH-PREFERENCEname.</dd> <dt>SRPOLICY-CPATH-PREFERENCE TLV (<xreftarget="Cpath-preference-tlv"/>): (optional)target="Cpath-preference-tlv" format="default"/>):</dt><dd>(optional) encodes the SR Policy Candidate Path preferencevalue.</t> </list> </t>value.</dd> </dl> <t>When a mandatory TLV is missing from an SRPA object, the PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr messagewith Error-Typewith:</t> <ul spacing="normal"> <li>Error-Type = 6 "Mandatory ObjectMissing", Error-ValueMissing"</li> <li>Error-value = 21 "Missing SR Policy MandatoryTLV".</t>TLV"</li> </ul> <t>Only one TLV instance of each TLV type can be carried in an SRPA object, and only the first occurrence is processed. Any othersMUST<bcp14>MUST</bcp14> be silently ignored.</t><section anchor="Policy-name-tlv" title="SR<!--[rfced] FYI, several section titles have been updated to exactly match the TLV name. If you prefer the original section titles, please let us know. For example: Original: 4.5.1. SR Policy NameTLV"> <t> TheTLV 4.5.2. SR Policy Candidate Path Identifier TLV Current: 4.5.1. SRPOLICY-POL-NAME TLV 4.5.2. SRPOLICY-CPATH-ID TLV --> <section anchor="Policy-name-tlv" numbered="true" toc="default"> <name>SRPOLICY-POL-NAME TLV</name> <t>The SRPOLICY-POL-NAME TLV (<xreftarget="SRPOLICY-POL-NAME-TLV-FORMAT"/>)target="SRPOLICY-POL-NAME-TLV-FORMAT" format="default"/>) is an optional TLV for the SRPA object. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the size of the name for the SR Policy is limited to 255 bytes. ImplementationsMAY<bcp14>MAY</bcp14> choose to truncate long names to 255 bytes to simplify interoperability with otherprotocols. </t>protocols.</t> <figureanchor="SRPOLICY-POL-NAME-TLV-FORMAT" title="SRPOLICY-POL-NAMEanchor="SRPOLICY-POL-NAME-TLV-FORMAT"> <name>SRPOLICY-POL-NAME TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SR Policy Name ~ | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 56<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>56 for"SRPOLICY-POL-NAME" TLV.</t> <t>Length: indicatesthe SRPOLICY-POL-NAME TLV.</dd> <dt>Length:</dt><dd>Indicates the length of the value portion of the TLV in octets andMUST<bcp14>MUST</bcp14> be greater than 0. The TLVMUST<bcp14>MUST</bcp14> be zero-padded so that the TLV is 4-octet aligned. Padding is not included in the Lengthfield.</t> <t>SRfield.</dd> <dt>SR PolicyName: SRName:</dt><dd>SR Policy name, as defined in <xref target="RFC9256" sectionFormat="of"section="2.1"/>.section="2.1" format="default"/>. ItMUST<bcp14>MUST</bcp14> be a string of printable ASCII <xreftarget="RFC0020"/>target="RFC0020" format="default"/> characters, without a NULLterminator.</t>terminator.</dd> </dl> </section><!-- Policy-name-tlv --><section anchor="Cpath-identifier-tlv"title="SR Policy Candidate Path Identifier TLV"> <t> Thenumbered="true" toc="default"> <name>SRPOLICY-CPATH-ID TLV</name> <t>The SRPOLICY-CPATH-ID TLV (<xreftarget="SRPOLICY-CPATH-ID-TLV-FORMAT"/>)target="SRPOLICY-CPATH-ID-TLV-FORMAT" format="default"/>) is a mandatory TLV for the SRPAobject. </t>object.</t> <figureanchor="SRPOLICY-CPATH-ID-TLV-FORMAT" title="SRPOLICY-CPATH-IDanchor="SRPOLICY-CPATH-ID-TLV-FORMAT"> <name>SRPOLICY-CPATH-ID TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Proto. OriginProto-Origin | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originator Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discriminator |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 57<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>57 for"SRPOLICY-CPATH-ID" TLV.</t> <t>Length: 28.</t> <t>Protocol Origin: 8-bitthe SRPOLICY-CPATH-ID TLV.</dd> <dt>Length:</dt><dd>28.</dd> <dt>Protocol-Origin:</dt><dd>8-bit unsigned integer value that encodes theprotocol origin.Protocol-Origin. The values of this field are specified in the IANA registry "SR Policy Protocol Origin" under the "Segment Routing" registry group, whichwasis introduced inSection 8.4 of<xreftarget="I-D.ietf-idr-bgp-ls-sr-policy"/>.section="8.4" target="I-D.ietf-idr-bgp-ls-sr-policy" format="default"/>. Note that in the PCInitiate message <xreftarget="RFC8281"/>,target="RFC8281" format="default"/>, theProtocol OriginProtocol-Origin is always set to 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)". The "SR Policy Protocol Origin" IANA registry includes a combination of values intended for use in PCEP and BGP-LS. When the registry contains two variants of values associated with the mechanism or protocol used for provisioning of the Candidate Path, for example 1 - "PCEP" and 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)", the "(In PCEP or when BGP-LS Producer isPCE)"PCE)", then variantsMUST<bcp14>MUST</bcp14> be used inPCEP.</t> <t>Reserved: ThisPCEP.</dd> <dt>Reserved:</dt><dd>This fieldMUST<bcp14>MUST</bcp14> be set to zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t> <t>Originatorreceipt.</dd> <dt>Originator Autonomous System Number(ASN): Represented(ASN):</dt><dd>Represented as a 32-bit unsigned integer value, part of the originator identifier, as specified in <xref format="default" section="2.4" sectionFormat="of" target="RFC9256"/>. When sending a PCInitiate message <xreftarget="RFC8281"/>,target="RFC8281" format="default"/>, the PCE is the originator of the Candidate Path. If the PCE is configured with an ASN, then itMUST<bcp14>MUST</bcp14> setit, otherwiseit; otherwise, the ASN is set to0. </t> <t>Originator Address: Represented0.</dd> <dt>Originator Address:</dt><dd>Represented as a 128-bit value as specified in <xref format="default" section="2.4" sectionFormat="of" target="RFC9256"/>. When sending a PCInitiate message, the PCE is acting as the originator and thereforeMAY<bcp14>MAY</bcp14> set this to an address that itowns. </t> <t>Discriminator: 32-bitowns.</dd> <dt>Discriminator:</dt><dd>32-bit unsigned integer value that encodes the Discriminator of the Candidate Path, as specified in <xref target="RFC9256" sectionFormat="of"section="2.5"/>.section="2.5" format="default"/>. This is the field that mainly distinguishes different SR Policy Candidate Paths, coming from the same originator. It is allowed to be any number in the 32-bitrange. </t>range.</dd> </dl> </section><!-- Cpath-identifier-tlv --><section anchor="SRPOLICY-CPATH-NAME"title="SR Policy Candidate Path Name TLV"> <t> Thenumbered="true" toc="default"> <name>SRPOLICY-CPATH-NAME TLV</name> <t>The SRPOLICY-CPATH-NAME TLV (<xreftarget="SRPOLICY-CPATH-NAME-TLV-FORMAT"/>)target="SRPOLICY-CPATH-NAME-TLV-FORMAT" format="default"/>) is an optional TLV for the SRPA object. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the size of the name for the SR Policy is limited to 255 bytes. ImplementationsMAY<bcp14>MAY</bcp14> choose to truncate long names to 255 bytes to simplify interoperability with otherprotocols. </t>protocols.</t> <figureanchor="SRPOLICY-CPATH-NAME-TLV-FORMAT" title="SRPOLICY-CPATH-NAMEanchor="SRPOLICY-CPATH-NAME-TLV-FORMAT"> <name>SRPOLICY-CPATH-NAME TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SR Policy Candidate Path Name ~ | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 58<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>58 for"SRPOLICY-CPATH-NAME" TLV.</t> <t>Length: indicatesthe SRPOLICY-CPATH-NAME TLV.</dd> <dt>Length:</dt><dd>Indicates the length of the value portion of the TLV in octets andMUST<bcp14>MUST</bcp14> be greater than 0. The TLVMUST<bcp14>MUST</bcp14> be zero-padded so that the TLV is 4-octet aligned. Padding is not included in the Lengthfield.</t> <t>SRfield.</dd> <dt>SR Policy Candidate PathName: SRName:</dt><dd>SR Policy Candidate Path Name, as defined in <xref target="RFC9256" sectionFormat="of"section="2.6"/>.section="2.6" format="default"/>. ItMUST<bcp14>MUST</bcp14> be a string of printable ASCII characters, without a NULLterminator.</t>terminator.</dd> </dl> </section><!-- SRPOLICY-CPATH-NAME --><section anchor="Cpath-preference-tlv"title="SR Policy Candidate Path Preference TLV"> <t> Thenumbered="true" toc="default"> <name>SRPOLICY-CPATH-PREFERENCE TLV</name> <t>The SRPOLICY-CPATH-PREFERENCE TLV (<xreftarget="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT"/>)target="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT" format="default"/>) is an optional TLV for the SRPA object. If the TLV is absent, then the default Preference value is 100, per <xref format="default" section="2.7" sectionFormat="of"target="RFC9256"/>. </t>target="RFC9256"/>.</t> <figureanchor="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT" title="SRPOLICY-CPATH-PREFERENCEanchor="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT"> <name>SRPOLICY-CPATH-PREFERENCE TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 59<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>59 for"SRPOLICY-CPATH-PREFERENCE" TLV.</t> <t>Length: 4.</t> <t>Preference: 32-bitthe SRPOLICY-CPATH-PREFERENCE TLV.</dd> <dt>Length:</dt><dd>4.</dd> <dt>Preference:</dt><dd>32-bit unsigned integer value that encodes the preference of the Candidate Path as defined in <xref format="default" section="2.7" sectionFormat="of"target="RFC9256"/>.</t>target="RFC9256"/>.</dd> </dl> </section><!-- Cpath-preference-tlv --></section><!-- AssociationInformation --></section> <!-- [rfced] For clarity, may we update this text as follows? This includes adding "they" after "therefore", adding punctuation, and splitting the second sentence into two sentences. Original: This section introduces mechanisms described for SR Policies in [RFC9256] to PCEP. These extensions do not make use of the SRPA for signaling in PCEP therefore cannot rely on the Association capability negotiation in ASSOC-Type-List TLV and separate capability negotiation is required. Perhaps: This section introduces mechanisms described for SR Policies in [RFC9256] to PCEP. These extensions do not make use of the SRPA for signaling in PCEP; therefore, they cannot rely on the Association capability negotiation in the ASSOC-Type-List TLV. Instead, separate capability negotiation is required. --> <section anchor="Other-mechanisms"title="SRnumbered="true" toc="default"> <name>SR Policy SignalingExtensions">Extensions</name> <t>This section introduces mechanisms described for SR Policies in <xreftarget="RFC9256"/>target="RFC9256" format="default"/> to PCEP. These extensions do not make use of the SRPA for signaling inPCEPPCEP, and therefore cannot rely on the Association capability negotiation in the ASSOC-Type-List TLV and separate capability negotiation isrequired. </t> <t> Thisrequired.</t> <t>This document specifies four new TLVs to be carried in the OPEN or LSP object. Only one TLV instance of each type can be carried, and only the first occurrence is processed. Any othersMUST<bcp14>MUST</bcp14> beignored. </t>ignored.</t> <section anchor="Capability-tlv"title="SR Policy Capability TLV"> <t> Thenumbered="true" toc="default"> <name>SRPOLICY-CAPABILITY TLV</name> <t>The SRPOLICY-CAPABILITY TLV (<xreftarget="SRPOLICY-CAPABILITY-TLV-FORMAT"/>)target="SRPOLICY-CAPABILITY-TLV-FORMAT" format="default"/>) is a TLV for the OPEN object. It is used at session establishment to learn the peer's capabilities with respect to SR Policy. Implementations that support SR PolicyMUST<bcp14>MUST</bcp14> include the SRPOLICY-CAPABILITY TLV in the OPEN object if the extension is enabled. In addition, the ASSOC-Type-List TLV containing SRPA Type (6)MUST<bcp14>MUST</bcp14> be present in the OPEN object, as specified in <xreftarget="Association"/>.</t>target="Association" format="default"/>.</t> <t>If a PCEP speaker receives an SRPA but the SRPOLICY-CAPABILITY TLV is not exchanged, then the PCEP speakerMUST<bcp14>MUST</bcp14> send a PCErr message withError- TypeError-Type = 10("Reception"Reception of an invalidobject")object" andError-ValueError-value =TBD2 ("Missing44 "Missing SRPOLICY-CAPABILITYTLV")TLV" andMUST<bcp14>MUST</bcp14> then close the PCEP session.</t> <figureanchor="SRPOLICY-CAPABILITY-TLV-FORMAT" title="SRPOLICY-CAPABILITYanchor="SRPOLICY-CAPABILITY-TLV-FORMAT"> <name>SRPOLICY-CAPABILITY TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |L| |I|E|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t>Type: 71<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>71 for"SRPOLICY-CAPABILITY" TLV.</t> <t>Length: 4.</t> <t>Flags (32 bits):</t> <t>the SRPOLICY-CAPABILITY TLV.</dd> <dt>Length:</dt><dd>4.</dd> <dt>Flags:</dt> <dd> <t>32 bits. The following flags are currently defined:</t><list style="symbols"> <t>P-flag<dl spacing="normal" newline="false"> <dt>P-flag (ComputationPriority): IfPriority):</dt> <dd>If set to'1'1 by a PCEP speaker, theP flagP-flag indicates that the PCEP speaker supports the handling of the COMPUTATION-PRIORITY TLV for the SR Policy (<xreftarget="Computation-priority-tlv"/>).target="Computation-priority-tlv" format="default"/>). If this flag is set to 0, then the receiving PCEP speakerMUST NOT<bcp14>MUST NOT</bcp14> send the COMPUTATION-PRIORITY TLV andMUST<bcp14>MUST</bcp14> ignore it onreceipt. </t> <t>E-Flagreceipt.</dd> <dt>E-flag (Explicit NULL LabelPolicy): IfPolicy):</dt> <dd>If set to'1'1 by a PCEP speaker, theE flagE-flag indicates that the PCEP speaker supports the handling of the Explicit Null Label Policy (ENLP) TLV for the SR Policy (<xreftarget="enlp-tlv"/>).target="enlp-tlv" format="default"/>). If this flag is set to 0, then the receiving PCEP speakerMUST NOT<bcp14>MUST NOT</bcp14> send the ENLP TLV andMUST<bcp14>MUST</bcp14> ignore it onreceipt. </t> <t>I-Flag (Invalidation): Ifreceipt.</dd> <dt>I-flag (Invalidation):</dt> <dd>If set to'1'1 by a PCEP speaker, theI flagI-flag indicates that the PCEP speaker supports the handling of the INVALIDATION TLV for the SR Policy (<xreftarget="Invalidation-tlv"/>).target="Invalidation-tlv" format="default"/>). If this flag is set to 0, then the receiving PCEP speakerMUST NOT<bcp14>MUST NOT</bcp14> send the INVALIDATION TLV andMUST<bcp14>MUST</bcp14> ignore it onreceipt. </t> <t>L-Flagreceipt.</dd> <dt>L-flag (StatelessOperation): IfOperation):</dt> <dd>If set to'1'1 by a PCEP speaker, theL flagL-flag indicates that the PCEP speaker supports the stateless (PCReq/PCRep) operations for the SR Policy (<xreftarget="Stateless-oper"/>).target="Stateless-oper" format="default"/>). If the PCE set this flag to 0, then the PCCMUST NOT<bcp14>MUST NOT</bcp14> send PCReq messages to this PCE for the SRPolicy. </t> </list>Policy.</dd> </dl> </dd> </dl> <t>Unassigned bitsMUST<bcp14>MUST</bcp14> be set to'0'0 on transmission andMUST<bcp14>MUST</bcp14> be ignored on receipt. More flags can be assigned in the future per (<xreftarget="sr_policy_cap_flag_field"/>).</t>target="sr_policy_cap_flag_field" format="default"/>).</t> </section><!-- Capability-tlv --><section anchor="lsp-object-tlvs"title="LSPnumbered="true" toc="default"> <name>LSP ObjectTLVs">TLVs</name> <t>This section is introducing three new TLVs to be carried in the LSP object introduced in <xref target="RFC8231" sectionFormat="of"section="7.3"/>.</t>section="7.3" format="default"/>.</t> <section anchor="Computation-priority-tlv"title="Computation Priority TLV">numbered="true" toc="default"> <name>COMPUTATION-PRIORITY TLV</name> <t>The COMPUTATION-PRIORITY TLV (<xreftarget="COMPUTATION-PRIORITY-TLV-FORMAT"/>)target="COMPUTATION-PRIORITY-TLV-FORMAT" format="default"/>) is an optional TLV. It is used to signal the numerical computation priority, as specified in <xref target="RFC9256" sectionFormat="of"section="2.12"/>.section="2.12" format="default"/>. If the TLV is absent from the LSPobjectobject, and the P-flag in the SRPOLICY-CAPABILITY TLV is set to 1, a default Priority value of 128 is used.</t> <figureanchor="COMPUTATION-PRIORITY-TLV-FORMAT" title="COMPUTATION-PRIORITYanchor="COMPUTATION-PRIORITY-TLV-FORMAT"> <name>COMPUTATION-PRIORITY TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 68<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>68 for"COMPUTATION-PRIORITY" TLV.</t> <t>Length: 4.</t> <t>Priority: 8-bitthe COMPUTATION-PRIORITY TLV.</dd> <dt>Length:</dt><dd>4.</dd> <dt>Priority:</dt><dd>8-bit unsigned integer value that encodes numerical priority with which this LSP is to be recomputed by the PCE upon topology change.LowestThe lowest value is the highestpriority.</t> <t>Reserved: Thispriority.</dd> <dt>Reserved:</dt><dd>This fieldMUST<bcp14>MUST</bcp14> be set to zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t>receipt.</dd> </dl> </section><!-- Computation-priority-tlv --><section anchor="enlp-tlv"title="Explicitnumbered="true" toc="default"> <name>Explicit Null Label Policy (ENLP)TLV"> <t> ToTLV</name> <t>To steer an unlabeled IP packet into an SRpolicyPolicy for the MPLS data plane, it is necessary to push a label stack of one or more labels on that packet. The Explicit NULL Label Policy (ENLP) TLV is an optional TLV for the LSP object used to indicate whether an Explicit NULL Label <xreftarget="RFC3032"/>target="RFC3032" format="default"/> must be pushed on an unlabeled IP packet before any other labels. The contents of this TLV are used by the SR PolicyManagermanager as described in <xref format="default" section="4.1" sectionFormat="of" target="RFC9256"/>. If an ENLP TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration. Note that Explicit Null is currently only defined for SR-MPLS and not for SRv6. Therefore, the receiving PCEP speakerMUST<bcp14>MUST</bcp14> ignore the presence of this TLV for SRv6Policies. </t>Policies.</t> <figureanchor="ENLP-TLV-FORMAT" title="Explicitanchor="ENLP-TLV-FORMAT"> <name>Explicit Null Label Policy (ENLP) TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENLP | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 69<dl spacing="normal" newline="false"> <dt>Type:</dt><dd>69 for"ENLP" TLV.</t> <t>Length: 4.</t> <t>the ENLP(ExplicitTLV.</dd> <dt>Length:</dt><dd>4.</dd> <dt>ENLP:</dt><dd>Explicit NULL LabelPolicy):Policy. 8-bit unsigned integer value that indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SRpolicy.Policy. The values of this field are specified in the IANA registry "SR Policy ENLP Values" under the "Segment Routing" registry group, which was introduced inSection 6.10 of<xreftarget="I-D.ietf-idr-sr-policy-safi"/>. </t> <t>Reserved: Thissection="6.10" target="RFC9830" format="default"/>.</dd> <dt>Reserved:</dt><dd>This fieldMUST<bcp14>MUST</bcp14> be set to zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t> <t> Thereceipt.</dd> </dl> <t>The ENLP unassigned values may be used for futureextensionsextensions, and implementationsMUST<bcp14>MUST</bcp14> ignore the ENLP TLV with unrecognized values. The behavior signaled in this TLVMAY<bcp14>MAY</bcp14> be overridden by local configuration by the network operator based on their deployment requirements.The<xref format="default" section="4.1" sectionFormat="of" target="RFC9256"/> describes the behavior on the headend for the handling of the explicit nulllabel. </t>label.</t> </section><!-- enlp-tlv --><section anchor="Invalidation-tlv"title="Invalidation TLV">numbered="true" toc="default"> <name>INVALIDATION TLV</name> <t>The INVALIDATION TLV (<xreftarget="INVALIDATION-TLV-FORMAT"/>)target="INVALIDATION-TLV-FORMAT" format="default"/>) is an optional TLV. This TLV is used to control traffic steering into an LSP when the LSP is operationally down/invalid. In the context of SR Policy, this TLV facilitates theDrop-upon-invalidDrop-Upon-Invalid behavior, specified in <xref format="default" section="8.2" sectionFormat="of" target="RFC9256"/>. Normally, if the LSP is down/invalid then it stops attracting traffic; traffic that would have been destined for that LSP is redirected somewhere else, such as via IGP or another LSP. TheDrop-upon-invalidDrop-Upon-Invalid behavior specifies that the LSP keeps attracting traffic and the traffic has to be dropped at the headend. Such an LSP is said to be "in drop state". While in the drop state, the LSP operational state is "UP", as indicated by the O-flag in the LSP object. However, the ERO objectMAY<bcp14>MAY</bcp14> beempty,empty if no valid path has beencomputed. </t> <t> Thecomputed.</t> <t>The INVALIDATION TLV is used in both directions between PCEPpeers: <list style="symbols"> <t>PCE ->peers:</t> <ul spacing="normal"> <li>PCE -> PCC: The PCE specifies to the PCC whether to enable or disableDrop-upon-invalid (Config).</t> <t>PCC ->Drop-Upon-Invalid (Config).</li> <li>PCC -> PCE: The PCC reports the current setting of theDrop-upon-invalidDrop-Upon-Invalid (Config) and also whether the LSP is currently in the drop state(Oper).</t> </list> </t>(Oper).</li> </ul> <figureanchor="INVALIDATION-TLV-FORMAT" title="INVALIDATIONanchor="INVALIDATION-TLV-FORMAT"> <name>INVALIDATION TLVFormat">Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Oper | Config | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure><t>Type: 70<dl spacing="normal" newline="false"> <dt>Type:</dt> <dd>70 for"INVALIDATION" TLV.</t> <t>Length: 4.</t> <t>Oper: Anthe INVALIDATION TLV.</dd> <dt>Length:</dt> <dd>4.</dd> <dt>Oper:</dt> <dd><t>An 8-bit flag field that encodes the operational state of the LSP. ItMUST<bcp14>MUST</bcp14> be set to 0 by the PCE when sending andMUST<bcp14>MUST</bcp14> be ignored by the PCC upon receipt. See <xreftarget="inval_oper_iana"/>target="inval_oper_iana" format="default"/> for IANAinformation. </t>information.</t> <figureanchor="OPER_INVAL_FLAGS" title="Oper stateanchor="OPER_INVAL_FLAGS"> <name>Oper State ofDrop-upon-invalid feature">Drop-Upon-Invalid Feature</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |D|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure><t> <list style="symbols"> <t>D:<ul indent="5"> <!--[rfced] Section 5.2.3 vs. IANA Considerations: Should this text be updated to match the IANA-registered description of each bit (which appears in Tables 6 and 7), or is it intentional for Section 5.2.3 to differ? - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-operational-flags Original: * D: dropping - the LSP is actively dropping traffic as a result of Drop-upon-invalid behavior beingactivated.</t> <t>Theactivated. Perhaps (if it should match the IANA registry, including the capitalization change which we will request): * D: Dropping - the LSP is currently attracting traffic and actively dropping it. - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-configuration-flags Original: * D: drop enabled - the Candidate Path has Drop-upon-invalid feature enabled. Perhaps (if it should match the IANA registry, including the capitalization changes that we will request): * D: Drop enabled - the Drop-Upon-Invalid is enabled on the LSP. --> <li>D: Dropping - the LSP is actively dropping traffic as a result of Drop-Upon-Invalid behavior being activated.</li> <li>The unassigned bits in the Flag octetMUST<bcp14>MUST</bcp14> be set to zero upon transmission andMUST<bcp14>MUST</bcp14> be ignored uponreceipt.</t> </list> </t> <t>Config: Anreceipt.</li> </ul> </dd> <dt>Config:</dt> <dd><t>An 8-bit flag field that encodes the configuration of the LSP. See <xreftarget="inval_config_iana"/>target="inval_config_iana" format="default"/> for IANAinformation. </t>information.</t> <figureanchor="CONFIG_INVAL_FLAGS" title="Config stateanchor="CONFIG_INVAL_FLAGS"> <name>Config State ofDrop-upon-invalid feature">Drop-Upon-Invalid Feature</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |D|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure><t> <list style="symbols"> <t>D: drop<ul indent="5"> <li>D: Drop enabled - the Candidate Path hasDrop-upon-invalidDrop-Upon-Invalid featureenabled.</t> <t>Theenabled.</li> <li>The unassigned bits in the Flag octetMUST<bcp14>MUST</bcp14> be set to zero upon transmission andMUST<bcp14>MUST</bcp14> be ignored uponreceipt.</t> </list> </t> <t>Reserved: Thisreceipt.</li> </ul> </dd> <dt>Reserved:</dt> <dd>This fieldMUST<bcp14>MUST</bcp14> be set to zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t>receipt.</dd> </dl> <section anchor="Invalidation-per-policy"title="Drop-upon-invalid appliesnumbered="true" toc="default"> <name>Drop-Upon-Invalid Applies to SRPolicy"> <t> The Drop-upon-invalidPolicy</name> <t>The Drop-Upon-Invalid feature is somewhat special among the other SR Policy features in the way that it is enabled/disabled. This feature is enabled only on the whole SR Policy, not on a particular Candidate Path of that SR Policy, i.e., when any Candidate Path hasDrop-upon-invalidDrop-Upon-Invalid enabled, it means that the whole SR Policy has the feature enabled. As stated in <xref format="default" section="8.1" sectionFormat="of" target="RFC9256"/>, an SR Policy is invalid when all its Candidate Paths areinvalid. </t> <t> Onceinvalid.</t> <!--[rfced] Section 5.2.3.1: Does 'the D (dropping) flag set' refer to the D flag (Dropping) from Figure 10 or the D flag (Drop enabled) from Figure 11? Original: Note that only one Candidate Path needs to be reported to the PCE with the D (dropping) flag set. Perhaps (if from Figure 10): Note that only one Candidate Path needs to be reported to the PCE with the Dropping (D) flag set. --> <t>Once all the Candidate Paths of an SR Policy have become invalid, then the SR Policy checks whether any of the Candidate Paths haveDrop-upon-invalidDrop-Upon-Invalid enabled. If so, the SR Policy enters the drop state and "activates" the highest preference Candidate Pathwhichthat has theDrop-upon-invalidDrop-Upon-Invalid enabled. Note that only one Candidate Path needs to be reported to the PCE with the D (dropping) flagset. </t>set.</t> </section><!-- Invalidation-per-policy --></section><!-- Invalidation-tlv --></section><!-- lsp-object-tlvs --><section anchor="Stateless-oper"title="Updatenumbered="true" toc="default"> <name>Updates to RFC8231"> <t> <xref8231</name> <t><xref format="default" section="5.8.2" sectionFormat="of"target="RFC8231"/>,target="RFC8231"/> allows delegation of an LSP in operationally down state, but at the same time mandates the use of PCReq before sending PCRpt. This document updates <xref format="default" section="5.8.2" sectionFormat="of" target="RFC8231"/>, by making that section of <xreftarget="RFC8231"/>target="RFC8231" format="default"/> not applicable to SR Policy LSPs. Thus, when a PCC wants to delegate an SR Policy LSP, itMAY<bcp14>MAY</bcp14> proceed directly to sending PCRpt, without first sending PCReq and waiting for PCRep. This has the advantage of reducing the number of PCEP messages and simplifying theimplementation. </t> <t> Furthermore,implementation.</t> <t>Furthermore, a PCEP speaker is not required to support PCReq/PCRep at all for SR Policies. The PCEP speaker can indicate support for PCReq/PCRep via the"L-Flag"L-flag in the SRPOLICY-CAPABILITY TLV(See(see <xreftarget="Capability-tlv"/>).target="Capability-tlv" format="default"/>). When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peerMUST NOT<bcp14>MUST NOT</bcp14> be sent PCReq/PCRep messages for SR Policy LSPs. Conversely, when this flag is set, the peer can receive and process PCReq/PCRep messages for SR PolicyLSPs. </t> <t> TheLSPs.</t> <t>The above applies only to SR Policy LSPs and does not affect other LSP types, such as RSVP-TE LSPs. For other LSP types, <xref format="default" section="5.8.2" sectionFormat="of" target="RFC8231"/> continues toapply. </t>apply.</t> </section><!-- Stateless-oper --></section><!-- Other mechanisms --><sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <eref brackets="angle" target="https://www.iana.org/assignments/pcep"/>.</t> <section anchor="Association-Type"title="Association Type">numbered="true" toc="default"> <name>Association Type</name> <t>This document defines a newassociation type:Association Type: SR Policy Association. IANAis requested to confirmhas made the followingallocationassignment in the "ASSOCIATION Type Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group:</t><t> <figure> <artwork align="left"><![CDATA[ +-----------+-------------------------------------------+-----------+ | Type | Name | Reference | +-----------+-------------------------------------------+-----------+ | 6 | SR Policy Association | This.I-D | +-----------+-------------------------------------------+-----------+ ]]></artwork> </figure> </t><table> <thead> <tr><th>Type</th><th>Name</th><th>Reference</th></tr> </thead> <tbody> <tr><td>6</td><td>SR Policy Association</td><td>RFC 9862</td></tr> </tbody> </table> </section> <sectiontitle="PCEPnumbered="true" toc="default"> <name>PCEP TLV TypeIndicators">Indicators</name> <t>This document defines eight new TLVs for carrying additional information about SR Policy and SR Policy Candidate Paths. IANAis requested to confirmhas made the followingallocationsassignments in the existing "PCEP TLV Type Indicators"registry as follows:</t> <t> <figure> <artwork align="left"><![CDATA[ +-----------+-------------------------------------------+-----------+ | Value | Description | Reference | +-----------+-------------------------------------------+-----------+ | 56 | SRPOLICY-POL-NAME | This.I-D | +-----------+-------------------------------------------+-----------+ | 57 | SRPOLICY-CPATH-ID | This.I-D | +-----------+-------------------------------------------+-----------+ | 58 | SRPOLICY-CPATH-NAME | This.I-D | +-----------+-------------------------------------------+-----------+ | 59 | SRPOLICY-CPATH-PREFERENCE | This.I-D | +-----------+-------------------------------------------+-----------+ | 68 | COMPUTATION-PRIORITY | This.I-D | +-----------+-------------------------------------------+-----------+ | 69 | EXPLICIT-NULL-LABEL-POLICY | This.I-D | +-----------+-------------------------------------------+-----------+ | 70 | INVALIDATION | This.I-D | +-----------+-------------------------------------------+-----------+ | 71 | SRPOLICY-CAPABILITY | This.I-D | +-----------+-------------------------------------------+-----------+ ]]></artwork> </figure> </t>registry:</t> <table> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>56</td> <td>SRPOLICY-POL-NAME</td> <td>RFC 9862</td> </tr> <tr> <td>57</td> <td>SRPOLICY-CPATH-ID</td> <td>RFC 9862</td> </tr> <tr> <td>58</td> <td>SRPOLICY-CPATH-NAME</td> <td>RFC 9862</td> </tr> <tr> <td>59</td> <td>SRPOLICY-CPATH-PREFERENCE</td> <td>RFC 9862</td> </tr> <tr> <td>68</td> <td>COMPUTATION-PRIORITY</td> <td>RFC 9862</td> </tr> <tr> <td>69</td> <td>EXPLICIT-NULL-LABEL-POLICY</td> <td>RFC 9862</td> </tr> <tr> <td>70</td> <td>INVALIDATION</td> <td>RFC 9862</td> </tr> <tr> <td>71</td> <td>SRPOLICY-CAPABILITY</td> <td>RFC 9862</td> </tr> </tbody> </table> </section> <sectiontitle="PCEP Errors">numbered="true" toc="default"> <name>PCEP Errors</name> <t>This document definesonethe following:</t> <ul> <li>one newError-ValueError-value within the "Mandatory Object Missing"Error-Type, twoError-Type,</li> <li>two newError-ValuesError-values within the "Association Error"Error-Type and oneError-Type, and</li> <li>one newError-ValueError-value within the "Reception of an invalidobject". </t>object".</li> </ul> <t>IANAis requested to confirmhas made the followingallocations withinassignments in the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group.</t><t> <figure> <artwork align="left"><![CDATA[ +------------+------------------+-----------------------+-----------+ | Error-Type | Meaning | Error-value | Reference | +------------+------------------+-----------------------+-----------+ | 6 | Mandatory<table> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td rowspan="2">6</td> <td>Mandatory Object| | [RFC5440] | | | Missing | | | +------------+------------------+-----------------------+-----------+ | | | 21:Missing</td> <td></td> <td><xref target="RFC5440"/></td> </tr> <tr> <td></td> <td>21: Missing SR| This.I-D | | | |Policy MandatoryTLV | | +------------+------------------+-----------------------+-----------+ | 26 | Association | | [RFC8697] | | | Error | | | +------------+------------------+-----------------------+-----------+ | | | 20:TLV</td> <td>RFC 9862</td> </tr> <tr> <td rowspan="3">26</td> <td>Association Error</td> <td></td> <td><xref target="RFC8697"/></td> </tr> <tr> <td></td> <td>20: SR Policy| This.I-D | | | |IdentifersMismatch | | +------------+------------------+-----------------------+-----------+ | | | 21:Mismatch</td> <td>RFC 9862</td> </tr> <tr> <td></td> <td>21: SR Policy| This.I-D | | | |Candidate Path| | | | |IdentifierMismatch | | +------------+------------------+-----------------------+-----------+ ]]></artwork> </figure></t>Mismatch</td> <td>RFC 9862</td> </tr> </tbody> </table> <t>IANAis requested to make new allocations withinhas made the following assigments in the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group.</t><t><figure> <artwork align="left"><![CDATA[ +------------+------------------+-----------------------+-----------+ | Error-Type | Meaning | Error-value | Reference | +------------+------------------+-----------------------+-----------+ | 6 | Mandatory<table> <thead> <tr> <th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td rowspan="2">6</td> <td>Mandatory Object| | [RFC5440] | | | Missing | | | +------------+------------------+-----------------------+-----------+ | | | TBD1:Missing</td> <td></td> <td><xref target="RFC5440"/></td> </tr> <tr> <td></td> <td>22: Missing SR| This.I-D | | | |PolicyAssociation | | +------------+------------------+-----------------------+-----------+ | 10 | ReceptionAssociation</td> <td>RFC 9862</td> </tr> <tr> <td rowspan="2">10</td> <td>Reception of an| | [RFC5440] | | |invalidobject | | | +------------+------------------+-----------------------+-----------+ | | | TBD2:object</td> <td></td> <td><xref target="RFC5440"/></td> </tr> <tr> <td></td> <td>44: Missing| This.I-D | | | |SRPOLICY-CAPABILITY| | | | | TLV | | +------------+------------------+-----------------------+-----------+ ]]></artwork> </figure> </t>TLV</td> <td>RFC 9862</td> </tr> </tbody> </table> </section> <sectiontitle="TE-PATH-BINDINGnumbered="true" toc="default"> <name>TE-PATH-BINDING TLV Flagfield"> <t> An earlierField</name> <t>A draft version of this document added a new bitwithinin the "TE-PATH-BINDING TLV Flagfield"Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group, which wasalsoearly allocated bytheIANA.</t><t> IANA is requested to mark<t>IANA has marked the bit position as deprecated.</t><t> <figure> <artwork align="left"><![CDATA[ +------------+------------------------------------------+-----------+ | Bit position | Description | Reference | +--------------+----------------------------------------+-----------+ | 1 | Deprecated (Specified-BSID-only) | This.I-D | +--------------+----------------------------------------+-----------+ ]]></artwork> </figure> </t><table> <thead> <tr><th>Bit</th><th>Description</th><th>Reference</th></tr> </thead> <tbody> <tr><td>1</td><td>Deprecated (Specified-BSID-only)</td><td>RFC 9862</td></tr> </tbody> </table> </section> <section anchor="inval_oper_iana"title="SRnumbered="true" toc="default"> <name>SR Policy Invalidation OperationalState"> <t> This document requests IANA toState</name> <t>IANA has created and will maintain a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Invalidation Operational Flags". New values are to be assigned by "IETFreview"Review" <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Each bitshouldwill be tracked with the following qualities:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Bit (counting from bit 0 as the most significantbit).</t> <t>Description.</t> <t>Reference.</t> </list> </t> <figure> <artwork align="left"><![CDATA[ +-------+-----------------------------------------------+-----------+ | Bit | Description | Reference | +-------+-----------------------------------------------+-----------+ | 0bit)</t> </li> <li> <t>Description</t> </li> <li> <t>Reference</t> </li> </ul> <table> <thead> <tr><th>Bit</th><th>Description</th><th>Reference</th></tr> </thead> <tbody> <tr><td>0 -6 | Unassigned | This.I-D | +-------+-----------------------------------------------+-----------+ | 7 | D: dropping6</td><td>Unassigned</td><td></td></tr> <tr><td>7</td><td>D: Dropping - the LSP is currently attracting| This.I-D | | |traffic and actively droppingit. | | +-------+-----------------------------------------------+-----------+ ]]></artwork> </figure>it.</td><td>RFC 9862</td></tr> </tbody> </table> </section> <section anchor="inval_config_iana"title="SRnumbered="true" toc="default"> <name>SR Policy Invalidation ConfigurationState"> <t> This document requests IANA toState</name> <t>IANA has created and will maintain a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Invalidation Configuration Flags". New values are to be assigned by "IETFreview"Review" <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Each bitshouldwill be tracked with the following qualities:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Bit (counting from bit 0 as the most significantbit).</t> <t>Description.</t> <t>Reference.</t> </list> </t> <figure> <artwork align="left"><![CDATA[ +-------+-----------------------------------------------+-----------+ | Bit | Description | Reference | +-------+-----------------------------------------------+-----------+ | 0bit)</t> </li> <li> <t>Description</t> </li> <li> <t>Reference</t> </li> </ul> <table> <thead> <tr><th>Bit</th><th>Description</th><th>Reference</th></tr> </thead> <tbody> <tr><td>0 -6 | Unassigned. | This.I-D | +-------+-----------------------------------------------+-----------+ | 7 | D: drop6</td><td>Unassigned.</td><td></td></tr> <tr><td>7</td><td>D: Drop enabled - theDrop-upon-invalidDrop-Upon-Invalid is| This.I-D | | |enabled on theLSP. | | +-------+-----------------------------------------------+-----------+ ]]></artwork> </figure>LSP.</td><td>RFC 9862</td></tr> </tbody> </table> </section> <section anchor="sr_policy_cap_flag_field"title="SRnumbered="true" toc="default"> <name>SR Policy Capability TLV Flagfield"> <t> This document requests IANA toField</name> <t>IANA has created and will maintain a new registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. The new registry is called "SR Policy Capability TLV Flag Field". New values are to be assigned by "IETFreview"Review" <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Each bitshouldwill be tracked with the following qualities:<list style="symbols"></t> <ul spacing="normal"> <li> <t>Bit (counting from bit 0 as the most significantbit).</t> <t>Description.</t> <t>Reference.</t> </list> </t> <figure> <artwork align="left"><![CDATA[ +--------+-----------------------------------------------+-----------+ | Bit | Description | Reference | +--------+-----------------------------------------------+-----------+ | 0bit)</t> </li> <li> <t>Description</t> </li> <li> <t>Reference</t> </li> </ul> <table> <thead> <tr><th>Bit</th><th>Description</th><th>Reference</th></tr> </thead> <tbody> <tr><td>0 -26 | Unassigned | This.I-D | +--------+-----------------------------------------------+-----------+ | 27 | Stateless26</td><td>Unassigned</td><td>RFC 9862</td></tr> <tr><td>27</td><td>Stateless Operation(L-Flag) | This.I-D | +--------+-----------------------------------------------+-----------+ | 28 | Unassigned | This.I-D | +--------+-----------------------------------------------+-----------+ | 29 | Invalidation (I-Flag) | This.I-D | +--------+-----------------------------------------------+-----------+ | 30 | Explicit(L-flag)</td><td>RFC 9862</td></tr> <tr><td>28</td><td>Unassigned</td><td>RFC 9862</td></tr> <tr><td>29</td><td>Invalidation (I-flag)</td><td>RFC 9862</td></tr> <tr><td>30</td><td>Explicit NULL Label Policy(E-Flag) | This.I-D | +--------+-----------------------------------------------+-----------+ | 31 | Computation(E-flag)</td><td>RFC 9862</td></tr> <tr><td>31</td><td>Computation Priority(P-flag) | This.I-D | +--------+-----------------------------------------------+-----------+ ]]></artwork> </figure>(P-flag)</td><td>RFC 9862</td></tr> </tbody> </table> </section> </section> <sectiontitle="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 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".</t> <section anchor="Cisco" title="Cisco"> <t><list style="symbols"> <t>Organization: Cisco Systems</t> <t>Implementation: IOS-XR PCC and PCE.</t> <t>Description: All features supported except Computation Priority, Explicit NULL and Invalidation Drop.</t> <t>Maturity Level: Production.</t> <t>Coverage: Full.</t> <t>Contact: ssidor@cisco.com</t> </list></t> </section> <section anchor="Juniper" title="Juniper"> <t><list style="symbols"> <t>Organization: Juniper Networks</t> <t>Implementation: PCC and PCE.</t> <t>Description: Everything in -05 except SR Policy Name TLV and SR Policy Candidate Path Name TLV.</t> <t>Maturity Level: Production.</t> <t>Coverage: Partial.</t> <t>Contact: cbarth@juniper.net</t> </list></t> </section> </section> <section title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The information carried in the newly defined SRPA object and TLVs could provide an eavesdropper with additional information about the SRPolicy. </t> <t> ThePolicy.</t> <t>The security considerations described in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, <xreftarget="RFC8281"/>,target="RFC8281" format="default"/>, <xreftarget="RFC8664"/>,target="RFC8664" format="default"/>, <xreftarget="RFC8697"/>,target="RFC8697" format="default"/>, <xreftarget="RFC9256"/>target="RFC9256" format="default"/>, and <xreftarget="RFC9603"/>target="RFC9603" format="default"/> are applicable to thisspecification. </t>specification.</t> <t>As per <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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) <xreftarget="RFC8253"/>target="RFC8253" format="default"/> as per the recommendations and best current practices in <xreftarget="RFC9325"/>.</t>target="RFC9325" format="default"/>.</t> </section> <sectiontitle="Manageability Considerations"numbered="true" toc="default"> <name>Manageability Considerations</name> <t>All manageability requirements and considerations listed in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, <xreftarget="RFC8664"/>,target="RFC8664" format="default"/>, <xreftarget="RFC9256"/>,target="RFC9256" format="default"/>, and <xreftarget="RFC9603"/>target="RFC9603" format="default"/> apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.</t> <sectiontitle="Controlnumbered="true" toc="default"> <name>Control of Function andPolicy" numbered="true" toc="default">Policy</name> <t>A PCE or PCC implementationMAY<bcp14>MAY</bcp14> allow the capabilities specified inSection 5.1<xref target="Capability-tlv"/> and the capability for support of an SRPA advertised in the ASSOC-Type-List TLV to be enabled and disabled.</t> </section> <sectiontitle="Information and Data Models"numbered="true" toc="default"><t><xref target="I-D.ietf-pce-pcep-srv6-yang" format="default" sectionFormat="of" derivedContent="PCEP-SRv6-YANG"/><name>Information and Data Models</name> <!-- [rfced] Does "described in Section 4" refer to Section 4 of this document or Section 4 of [I-D.ietf-pce-pcep-srv6-yang]? Original: [I-D.ietf-pce-pcep-srv6-yang] defines YANG module with common building blocks for PCEP Extensions described in Section 4. --> <t><xref target="I-D.ietf-pce-pcep-srv6-yang"/> defines a YANG module with common building blocks for PCEP extensions described in Section 4.</t> </section> <sectiontitle="Liveness Detection and Monitoring"numbered="true" toc="default"> <name>Liveness Detection and Monitoring</name> <t>Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8664"/>,target="RFC8664" format="default"/>, and <xreftarget="RFC9256"/>.</t>target="RFC9256" format="default"/>.</t> </section> <sectiontitle="Verify Correct Operations"numbered="true" toc="default"> <name>Verify Correct Operations</name> <t>Operation verification requirements already listed in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, <xreftarget="RFC8664"/>,target="RFC8664" format="default"/>, <xreftarget="RFC9256"/>,target="RFC9256" format="default"/>, and <xreftarget="RFC9603"/>target="RFC9603" format="default"/> are applicable to mechanisms defined in this document.</t> <t>An implementationMUST<bcp14>MUST</bcp14> allow the operator to view SR Policy Identifier and SR Policy Candidate Path Identifier advertised in an SRPA object.</t> <t>An implementationSHOULD<bcp14>SHOULD</bcp14> allow the operator to view the capabilities defined in this document advertised by each PCEP peer.</t> <t>An implementationSHOULD<bcp14>SHOULD</bcp14> allow the operator to view LSPs associated with a specific SR Policy Identifier.</t> </section> <sectiontitle="Requirements On Other Protocols"numbered="true" toc="default"> <name>Requirements on Other Protocols</name> <t>The PCEP extensions defined in this document do not imply any new requirements on other protocols.</t> </section> <sectiontitle="Impact On Network Operations"numbered="true" toc="default"> <name>Impact on Network Operations</name> <t>The mechanisms defined in <xreftarget="RFC5440"/>,target="RFC5440" format="default"/>, <xreftarget="RFC8231"/>,target="RFC8231" format="default"/>, <xreftarget="RFC9256"/>target="RFC9256" format="default"/>, and <xreftarget="RFC9603"/>target="RFC9603" format="default"/> also apply to the PCEP extensions defined in this document.</t> </section> </section> </middle> <back> <displayreference target="I-D.ietf-pce-pcep-srv6-yang" to="PCEP-SRv6-YANG" /> <displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="ADV-SR-POLICY" /> <displayreference target="I-D.ietf-pce-multipath" to="PCEP-MULTIPATH" /> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/> <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.3032.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.8126.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.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.8402.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.8697.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9603.xml"/> </references> <references> <name>Informative References</name> <!-- draft-ietf-idr-sr-policy-safi-13 now RFC 9830 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9830.xml"/> <!-- [I-D.ietf-idr-bgp-ls-sr-policy] --> <reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-17"> <front> <title>Advertisement of Segment Routing Policies using BGP Link-State</title> <author initials="S." surname="Previdi" fullname="Stefano Previdi"> <organization>Individual</organization> </author> <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor"> <organization>Cisco Systems</organization> </author> <author initials="J." surname="Dong" fullname="Jie Dong"> <organization>Huawei Technologies</organization> </author> <author initials="H." surname="Gredler" fullname="Hannes Gredler"> <organization>RtBrick Inc.</organization> </author> <author initials="J." surname="Tantsura" fullname="Jeff Tantsura"> <organization>Nvidia</organization> </author> <date month="March" day="6" year="2025" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-17" /> </reference> <!-- [I-D.ietf-pce-multipath] draft-ietf-pce-multipath-13 IESG State: I-D Exists as of 06/03/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-multipath.xml"/> <!-- [I-D.ietf-pce-pcep-srv6-yang] draft-ietf-pce-pcep-srv6-yang-07 IESG State: I-D Exists as of 06/03/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-srv6-yang.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9604.xml"/> </references> </references> <section anchor="Acknowledgement"title="Acknowledgement"> <t> Wenumbered="false" toc="default"> <name>Acknowledgements</name> <t>We would like to thankAbdul Rehman, Andrew Stone, Boris Khasanov, Cheng Li, Dhruv Dhody, Gorry Fairhurst, Gyan Mishra, Huaimo Chen, Ines Robles, Joseph Salowey, Ketan Talaulikar, Marina Fizgeer, Mike Bishopm, Praveen Kumar, Robert Sparks, Roman Danyliw, Stephane Litkowski, Tom Petch, Zoey Rose, Xiao Min, Xiong Quan<contact fullname="Abdul Rehman"/>, <contact fullname="Andrew Stone"/>, <contact fullname="Boris Khasanov"/>, <contact fullname="Cheng Li"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Huaimo Chen"/>, <contact fullname="Ines Robles"/>, <contact fullname="Joseph Salowey"/>, <contact fullname="Ketan Talaulikar"/>, <contact fullname="Marina Fizgeer"/>, <contact fullname="Mike Bishopm"/>, <contact fullname="Praveen Kumar"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Stephane Litkowski"/>, <contact fullname="Tom Petch"/>, <contact fullname="Zoey Rose"/>, <contact fullname="Xiao Min"/>, <contact fullname="Xiong Quan"/> for review andsuggestions. </t>suggestions.</t> </section><!-- Acknowledgement --> </middle> <back> <references title="Normative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8408.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8697.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9325.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9603.xml"?> </references> <references title="Informative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-sr-policy-safi.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ls-sr-policy.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-multipath.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-srv6-yang"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9552.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9604.xml"?> </references><sectiontitle="Contributors"> <t><figure><artwork> Dhruv Dhody Huawei India Email: dhruv.ietf@gmail.com Cheng Li Huawei Technologies Huaweinumbered="false" toc="default"> <name>Contributors</name> <contact fullname="Dhruv Dhody"> <organization>Huawei</organization> <address> <postal> <country>India</country> </postal> <email>dhruv.ietf@gmail.com</email> </address> </contact> <contact fullname="Cheng Li"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Campus, No. 156 BeiqingRd. Beijing, 10095 China Email: chengli13@huawei.com Zafar Ali CiscoRd.</street> <city>Beijing</city><code>10095</code> <country>China</country> </postal> <email>chengli13@huawei.com</email> </address> </contact> <contact fullname="Zafar Ali"> <organization>Cisco Systems,Inc. Email: zali@cisco.com Rajesh Melarcode CiscoInc</organization> <address> <email>zali@cisco.com</email> </address> </contact> <contact fullname="Rajesh Melarcode"> <organization>Cisco Systems,Inc. 2000Inc.</organization> <address> <postal> <street>2000 InnovationDr. Kanata, Ontario Canada Email: rmelarco@cisco.com </artwork></figure></t>Dr.</street> <city>Kanata</city><region>Ontario</region> <country>Canada</country> </postal> <email>rmelarco@cisco.com</email> </address> </contact> </section> </back> <!-- [rfced] Please review the following questions about terminology. a) We note the following different uses of the term below. Please review and let us know how to update for consistency. EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2) Explicit NULL Label Policy (ENLP) TLV Explicit Null Label Policy (ENLP) TLV Explicit NULL Label Policy (E-Flag) Explicit NULL Label [RFC3032] Explicit Null Label Policy Explicit NULL label/s explicit null label Note that Explicit Null is... b) We note different capitalization for the terms below. Please review and let us know how to update for consistency. Destination vs. destination Preference vs. preference Candidate Path vs. candidate path --> <!--Contributors[rfced] FYI - We have already updated the following terms for consistency within the document and to match usage in other RFCs. Please review: a) For the terms below, we have updated the form(s) on the left to the form on the right. association type / Association type -> Association Type (per RFC 8697) Association Parameters -> association parameters (per RFC 8697) ASSOCIATION Object -> ASSOCIATION object (per RFC 8697) Protocol Origin -> Protocol-Origin (per Section 2.3 of RFC 9256) Drop-upon-invalid -> Drop-Upon-Invalid (per Section 8.2 of RFC 9256) b) We note flags are stylized differently throughout (see some examples below). For consistency, we have updated all of these instances to P-flag, E-flag, etc. P-flag P flag E-Flag E flag I-Flag I flag L-Flag L flag "L-Flag" O-flag So, we will ask IANA to update to lowercase 'f' consistently in the description in this registry (https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-capability-tlv-flag-field) unless you let us know otherwise. Specifically, for bits 27, 29, and 30: OLD: L-Flag, I-Flag, E-Flag NEW: L-flag, I-flag, E-flag c) FYI, "<headend, color, endpoint>" has been capitalized for consistency with Section 2.1 of [RFC9256]. Original: Per Section 2.1 of [RFC9256], an SR Policy is identified through the <headend, color, endpoint> tuple. The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <headend, color, endpoint> tuple. Current: Per Section 2.1 of [RFC9256], an SR Policy is identified through the <Headend, Color, Endpoint> tuple. The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <Headend, Color, Endpoint> tuple. --> <!-- [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. For example, please consider whether "native" should be updated in the text below: An example use case is to terminate the SR Policy before reaching the Endpoint and have decapsulated traffic be forwarded the rest of the path to the Endpoint node using the native Interior Gateway Protocol (IGP) path(s). --></back></rfc>