rfc9862xml2.original.xml   rfc9862.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "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. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.2629.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.o
rg/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]> ]>
<?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 category="std" docName="draft-ietf-pce-segment-routing-policy-cp-27" ipr="t
rust200902" updates="8231">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-pce-segment-routing-policy-cp-27" number="9862" consensus="true" ipr="trust20
0902" updates="8231" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude
="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- [rfced] This document updates RFC 8231. Please review the
errata reported for RFC 8231 <https://www.rfc-editor.org/errata/rfc8231>
and confirm that none are relevant to the content of this document. -->
<front> <front>
<title abbrev="PCEP SR Policy"> <title abbrev="PCEP SR Policy">
Path Computation Element Communication Protocol (PCEP) Extensions for Segmen t Routing (SR) Policy Candidate Paths</title> Path Computation Element Communication Protocol (PCEP) Extensions for Segmen t Routing (SR) Policy Candidate Paths</title>
<seriesInfo name="RFC" value="9862"/>
<author fullname="Mike Koldychev" initials="M." surname="Koldychev"> <author fullname="Mike Koldychev" initials="M." surname="Koldychev">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<postal> <postal>
<street>385 Terry Fox Dr.</street> <street>385 Terry Fox Dr.</street>
<city>Kanata</city> <city>Kanata</city>
<region>Ontario</region> <region>Ontario</region>
<code>K2K 0L1</code> <code>K2K 0L1</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
skipping to change at line 91 skipping to change at line 58
<address> <address>
<postal> <postal>
<street>Eurovea Central 3.</street> <street>Eurovea Central 3.</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>811 09</code> <code>811 09</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ssidor@cisco.com</email> <email>ssidor@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Colby Barth" initials="C." surname="Barth"> <author fullname="Colby Barth" initials="C." surname="Barth">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<email>cbarth@juniper.net</email> <email>cbarth@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Shuping Peng" initials="S." surname="Peng"> <author fullname="Shuping Peng" initials="S." surname="Peng">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address>
<address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city>
<city>Beijing</city> <code>100095</code>
<country>China</country>
<region/>
<code>100095</code>
<country>China</country>
</postal> </postal>
<email>pengshuping@huawei.com</email>
<phone/>
<facsimile/>
<email>pengshuping@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli"> <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>hooman.bidgoli@nokia.com</email> <email>hooman.bidgoli@nokia.com</email>
</address> </address>
</author> </author>
<date year="2025" month="September"/>
<area>RTG</area>
<workgroup>PCE</workgroup>
<date/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>
A Segment Routing (SR) Policy is an ordered list of 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), 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>Segment Routing (SR) Policy Architecture <xref target="RFC9256"/> details the
concepts of Segment Routing (SR) Policy <xref target="RFC8402"/> and approaches
to steering traffic into an SR Policy.</t>
<t>Path Computation Element Communication Protocol (PCEP) Extensions for Segment
Routing <xref target="RFC8664"/> specifies extensions to the PCEP that allow a
stateful Path Computation Element (PCE) to compute and initiate Traffic Engineer
ing (TE) paths, as well as a Path Computation Client (PCC) to request a path sub
ject to certain constraints and optimization criteria in SR domain.
Although PCEP extensions introduced in <xref target="RFC8664"/> enables the crea
tion of SR-TE paths, these do not constitute SR Policies as defined in <xref tar
get="RFC9256"/> and therefore lack support for:
<list style="symbols">
<t>Association of SR Policy Candidate Paths signaled via PCEP with Candidate Pat
hs of the same SR Policy signaled via other sources (e.g., local configuration o
r BGP).</t>
<t>Association of SR Policy with an intent via color, enabling headend-based ste
ering of BGP service routes over SR Policies provisioned via PCEP.</t>
</list>
</t>
<t>PCEP Extensions for establishing relationships between sets of Label Switched
Paths (LSPs) <xref target="RFC8697"/> introduces a generic mechanism to create
a grouping of LSPs which is called an Association.</t>
<t>An SR Policy is associated with one or more candidate paths. A candidate path
is the unit for signaling of an SR Policy to a headend as described in Section
2.2 of <xref target="RFC9256"/>.
This document extends <xref target="RFC8664"/> to support signaling SR Policy Ca
ndidate Paths as LSPs and to signal Candidate Path membership in
an SR Policy by means of the Association mechanism.
A PCEP Association corresponds to a SR Policy and a LSP corresponds to a Candida
te Path.
The unit of signaling in PCEP is the LSP, thus all the information related to SR
Policy is carried at the Candidate Path level.
</t>
<t>Also, this document updates Section 5.8.2 of <xref target="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"/> and Path Setup Type 3 (SRv6) <xref target="RFC9603"/> with t
he aim of reducing the PCEP message exchanges and simplifying implementation.</t
>
<section anchor="Language" title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when
, and only when, they
appear in all capitals, as shown here.</t>
</section>
</section> <!-- Introduction -->
<section anchor="Terminology" title="Terminology">
<t>This document uses the following terms defined in <xref target="RFC5440"
/>: ERO, PCC,
PCE, PCEP Peer, and PCEP speaker.</t>
<t>This document uses the following term defined in <xref target="RFC3031"/
>: LSP.</t>
<t>This document uses the following term defined in <xref target="RFC955
2"/>: BGP-LS.</t>
<t>The following terms are used in this document:
<list style="hanging">
<t hangText="Endpoint:"> The IPv4 or IPv6 endpoint address of an SR Policy,
as described in Section 2.1 of <xref target="RFC9256"/>.</t>
<t hangText="Color:"> The 32-bit color of an SR Policy, as described in Sec
tion 2.1 of <xref target="RFC9256"/>.</t>
<t hangText="Protocol-Origin:"> The protocol that was used to create a Cand
idate Path, as described in Section 2.3 of <xref target="RFC9256"/>.</t>
<t hangText="Originator:"> A device that created a Candidate Path, as descr
ibed in Section 2.4 of <xref target="RFC9256"/>.</t>
<t hangText="Discriminator:"> Distinguishes Candidate Paths created by the
same device, as described in Section 2.5 of <xref target="RFC9256"/>.</t>
<t hangText="Association Parameters:"> As described in <xref target="RFC869
7"/>, refers to the key data that uniquely identifies an Association.</t>
<t hangText="Association Information:"> As described in Section 6.1.4 of <x
ref target="RFC8697"/>, refers to information related to Association Type.</t>
<t hangText="SR Policy LSP:"> An LSP setup using Path Setup Type <xref t
arget="RFC8408"/> 1 (Segment Routing) or 3 (SRv6).</t>
<t hangText="SR Policy Association:"> A new association type used to g
roup candidate paths belonging to same SR
Policy. Depending on the discussion context, it can refer to the PCEP
ASSOCIATION object of SR Policy type or to a group of LSPs that
belong to the association.</t>
</list>
<t> The base PCEP specification <xref target="RFC4655"/> 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 setup types, such as
SRv6, has been introduced <xref target="RFC9603"/>. The term "LSP" is us
ed extensively in PCEP 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 LSP Object as specified in <xref target="RFC8231"/>.</t>
</t>
</section> <!-- Terminology -->
<section anchor="Overview" title="Overview"> <keyword>example</keyword>
<t> <abstract>
The SR Policy is represented by a new type of PCEP Association, called the SR Po <t>
licy Association (SRPA) (see <xref target="Association"/>). A Segment Routing (SR) Policy is an ordered list of instructions called
The SR Policy Candidate Paths of specific SR Policy are the LSPs within the same "segments" that represent a source-routed policy. Packet flows are steered
SRPA. into an SR Policy on a node where it is instantiated. An SR Policy is made
The extensions in this document specify the encoding of a single segment list wi of one or more candidate paths.
thin an SR Policy Candidate Path. Encoding of multiple </t>
segment lists is outside the scope of this document and specified in <xref targe <t>
t="I-D.ietf-pce-multipath"/>. This document specifies the Path Computation Element Communication Protocol
</t> (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) 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" numbered="true" toc="default">
<name>Introduction</name>
<t>"Segment Routing Policy Architecture" <xref target="RFC9256"
format="default"/> details the concepts of Segment Routing (SR) Policy
<xref target="RFC8402" format="default"/> and approaches to steering
traffic into an SR Policy.</t>
<t>"Path Computation Element Communication Protocol (PCEP) Extensions
for Segment Routing" <xref 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 <xref target="RFC8664" format="default"/>
enable the creation of SR-TE paths, these do not constitute SR Policies
as defined in <xref target="RFC9256" format="default"/>. Therefore, they
lack support 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>
</li>
</ul>
<t>"Path Computation Element Communication Protocol (PCEP) Extensions
for Establishing Relationships between Sets of Label Switched Paths
(LSPs)" <xref target="RFC8697" format="default"/> introduces a generic
mechanism to create a grouping of LSPs that is called an
"Association".</t>
<t>An SR Policy is associated with one or more candidate paths. A
candidate path is the unit for signaling an SR Policy to a headend as
described in <xref target="RFC9256" section="2.2"/>. This document
extends <xref 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 to an SR Policy and an LSP corresponds to a
Candidate Path. The unit of signaling in PCEP is the LSP, thus, all the
information related to an SR Policy is carried at the Candidate Path level
.</t>
<t>An SRPA carries three pieces of information: <!-- [rfced] FYI, we added "for" here to make the meaning of the
SR Policy Identifier, SR Policy Candidate Path Identifier, and SR Policy Candida parenthetical more clear. Please let us know if you prefer otherwise.
te Path Attribute(s).</t>
<t> Original:
This document also specifies some additional information that is not encoded as Also, this document updates Section 5.8.2 of [RFC8231], making the
part of an SRPA: Computation Priority of the LSP, Explicit Null Label Policy for use of Path Computation Request (PCReq) and Path Computation Reply
the unlabeled IP packets and Drop-upon-invalid behavior for traffic steering wh (PCRep) messages optional for LSPs setup using Path Setup Type 1
en the LSP is operationally down (see <xref target="Other-mechanisms"/>). (Segment Routing) [RFC8664] and Path Setup Type 3 (SRv6) [RFC9603]
</t> with the aim of reducing the PCEP message exchanges and simplifying
implementation.
[...]
</section> <!-- Overview --> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1
(Segment Routing) or 3 (SRv6).
<section anchor="Association" title="SR Policy Association (SRPA)"> Current:
<t> Also, this document updates Section 5.8.2 of [RFC8231], making the
Per <xref target="RFC8697"/>, LSPs are associated with other LSPs with which use of Path Computation Request (PCReq) and Path Computation Reply
they (PCRep) messages optional for LSPs that are set up using Path Setup
interact by adding them to a common association group. An association group Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 (for
is uniquely identified by the SRv6) [RFC9603] with the aim of reducing the PCEP message exchanges
combination of the following fields in the ASSOCIATION object (<xref target=" and simplifying implementation.
RFC8697" sectionFormat="of" section="6.1"/>): [...]
Association Type, Association ID, Association Source, and (if
present) Global Association Source, or Extended Association ID. These fields
are
referred to as Association Parameters (<xref target="AssociationParameters"/>
).
</t>
<t>
<xref target="RFC8697"/> specifies the ASSOCIATION Object with two Object-Types
for IPv4 and IPv6 which includes the field "Association Type". This document def
ines a new Association type (6) "SR Policy Association" for SRPA.
</t>
<t> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 (for
<xref target="RFC8697"/> specifies the mechanism for the capability advertisemen Segment Routing) or 3 (for SRv6).
t 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 the SR Policy Association Type MUST
be done before using the SRPA. To that aim, a
PCEP speaker MUST include the SRPA Type (6) in
the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
before using the SRPA (<xref target="Association-Type"/>).</t>
<t> <t>Also, this document updates <xref target="RFC8231" section="5.8.2"/>,
SRPA MUST be assigned for all SR Policy LSPs by PCEP speaker originating the making the use of Path Computation Request (PCReq) and Path Computation
LSP if capability was advertised by both PCEP speakers. Reply (PCRep) messages optional for LSPs that are set up using Path Setup
If the above condition is not satisfied, then the receiving PCEP speaker MUST Type 1
send a PCErr message with (for Segment Routing) <xref target="RFC8664" format="default"/> and Path
Error-Type = 6 "Mandatory Object Missing", Error-Value = TBD1 "Missing SR Policy Setup Type 3 (for SRv6) <xref target="RFC9603" format="default"/> with the
Association". aim of reducing the PCEP message exchanges and simplifying
</t> implementation.</t>
<section anchor="Language" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<t> <section anchor="Terminology" numbered="true" toc="default">
A given LSP MUST belong to at most one SRPA, since an SR Policy Candidate Path c <name>Terminology</name>
annot belong to multiple SR Policies. <t>This document uses the following terms defined in <xref target="RFC5440
If a PCEP speaker receives a PCEP message requesting to join more than one SRPA "/>:</t>
for the same LSP, <ul>
then the PCEP speaker MUST send a PCErr message with <li>Explicit Route Object (ERO)</li>
Error-Type = 26 "Association Error", Error-Value = 7 "Cannot join the associatio <li>Path Computation Client (PCC)</li>
n group". <li>Path Computation Element (PCE)</li>
</t> <li>PCEP Peer</li>
<li>PCEP speaker</li>
</ul>
<t> <t>This document uses the following term defined in <xref target="RFC3031"
The existing behavior for the use of Binding SID with SR Policy is already docum />:</t>
ented in <xref target="RFC9604"/>. If BSID value allocation failed, because of c <ul>
onflict with BSID used by another policy, then PCEP peer MUST send a PCErr messa <li>Label Switched Path (LSP)</li>
ge with Error-Type = 32 "Binding label/SID failure" and Error-value = 2 "Unable </ul>
to allocate the specified binding value".
</t>
<section anchor="SRPolicyIdentifier" title="SR Policy Identifier"> <t>This document uses the following term defined in <xref target="RFC9552"
<t>SR Policy Identifier uniquely identifies an SR Policy <xref target="RFC9256"/ />:</t>
> within the SR domain. <ul>
SR Policy Identifier is assigned by PCEP peer originating the LSP and MUST be un <li>Border Gateway Protocol - Link State (BGP-LS)</li>
iform across all the PCEP sessions. </ul>
Candidate Paths within an SR Policy MUST carry the same SR Policy Identifiers in
their SRPAs.
Candidate Paths within an SR Policy MUST NOT change their SR Policy Identifiers
for the lifetime of the PCEP session.
If the above conditions are not satisfied, the receiving PCEP speaker MUST send
a PCEP Error (PCErr) message with Error-Type = 26 "Association Error" and Error
Value = 20 "SR Policy Identifier Mismatch".
SR Policy Identifier consists of:</t>
<t>
<list style="symbols">
<t>Headend router where the SR Policy originates.</t>
<t>Color of the SR Policy (<xref target="RFC9256"/>, Section 2.1).</t>
<t>Endpoint of the SR Policy (<xref target="RFC9256"/>, Section 2.1).</t
>
</list>
</t>
</section>
<section anchor="SRPolicyCandidatePathIdentifier" title="SR Policy Candidate Pat <t>The following other terms are used in this document:</t>
h Identifier"> <dl>
<t>SR Policy Candidate Path Identifier uniquely identifies the SR Policy Candida <dt>Endpoint:</dt>
te Path within the context of an SR Policy. SR Policy Candidate Path Identifier <dd>The IPv4 or IPv6 endpoint address of an SR Policy, as described in <
is assigned by PCEP peer originating the LSP. xref target="RFC9256" section="2.1"/>.</dd>
Candidate Paths within an SR Policy MUST NOT change their SR Policy Candidate Pa <dt>Color:</dt>
th Identifiers for the lifetime of the PCEP session. <dd>The 32-bit color of an SR Policy, as described in <xref target="RFC9
Two or more Candidate Paths within an SR Policy MUST NOT carry same SR Policy Ca 256" section="2.1"/>.</dd>
ndidate Path Identifiers in their SRPAs. <dt>Protocol-Origin:</dt>
If the above conditions are not satisfied, the PCEP speaker MUST send a PCErr me <dd>The protocol that was used to create a Candidate Path, as
ssage with Error-Type = 26 "Association Error" and Error Value = 21 "SR Policy C described in <xref target="RFC9256" section="2.3"/>.</dd>
andidate Path Identifier Mismatch". <dt>Originator:</dt>
SR Policy Candidate Path Identifier consists of:</t> <dd>A device that created a Candidate Path, as described in <xref
<t> target="RFC9256" section="2.4"/>.</dd>
<list style="symbols"> <dt>Discriminator:</dt>
<t>Protocol Origin (<xref target="RFC9256"/>, Section 2.3).</t> <dd>Distinguishes Candidate Paths created by the same device, as
<t>Originator (<xref target="RFC9256"/>, Section 2.4).</t> described in <xref target="RFC9256" section="2.5"/>.</dd>
<t>Discriminator (<xref target="RFC9256"/>, Section 2.5).</t> <dt>Association parameters:</dt>
</list> <dd>Refers to the key data that uniquely identifies an Association,
</t> as described in <xref target="RFC8697" format="default"/>.</dd>
</section> <dt>Association information:</dt>
<dd>Refers to information related to Association Type, as described
in <xref target="RFC8697" section="6.1.4"/>.</dd>
<dt>SR Policy LSP:</dt>
<dd>An LSP setup using Path Setup Type <xref target="RFC8408"
format="default"/> 1 (for Segment Routing) or 3 (for SRv6).</dd>
<dt>SR Policy Association (SRPA):</dt>
<dd>A new Association Type used to group candidate paths belonging to th
e
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 the association.</dd>
</dl>
<section anchor="SRPolicyCandidatePathAttributes" title="SR Policy Candidate Pat <t>The base PCEP specification <xref target="RFC4655"
h Attributes"> format="default"/> originally defined the use of the PCE architecture
<t>SR Policy Candidate Path Attributes carry optional, non-key information about for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE
a Candidate Path and MAY change during the lifetime of an LSP. signaling protocol. Over time, support for additional path setup types
SR Policy Candidate Path Attributes consists of:</t> such as SRv6 has been introduced <xref target="RFC9603"
<t> format="default"/>. The term "LSP" is used extensively in PCEP
<list style="symbols"> specifications, and in the context of this document, refers to a
<t>Candidate Path preference (<xref target="RFC9256"/>, Section 2.7).</t Candidate Path within an SR Policy, which may be an SRv6 path (still
> represented using the LSP object as specified in <xref target="RFC8231"
<t>Candidate Path name (<xref target="RFC9256"/>, Section 2.6).</t> format="default"/>).</t>
<t>SR Policy name (<xref target="RFC9256"/>, Section 2.1).</t> </section>
</list>
</t>
</section>
<section anchor="AssociationParameters" title="Association Parameters"> <section anchor="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 <xref 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 <xref
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 priority of the LSP, Explicit
Null Label Policy for the unlabeled IP packets and Drop-Upon-Invalid
behavior for traffic steering when the LSP is operationally down (see
<xref target="Other-mechanisms" format="default"/>).
</t>
</section>
<t> <section anchor="Association" numbered="true" toc="default">
Per <xref target="RFC9256" sectionFormat="of" section="2.1"/>, <name>SR Policy Association (SRPA)</name>
an SR Policy is identified through the &#60;headend, color, endpoint&#62; tuple. <t>
</t> Per <xref 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" format="default"/>):
Association Type, Association ID, Association Source, and (if present)
Global Association Source, or Extended Association ID. These fields
are referred to as "association parameters" (<xref
target="AssociationParameters" format="default"/>).
</t>
<t>
<xref target="RFC8697" format="default"/> specifies the ASSOCIATION
object with two Object-Types for IPv4 and IPv6 that includes the field
Association Type. This document defines a new Association Type (6)
"SR Policy Association" for an SRPA.
</t>
<t>
<xref 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 the SRPA Type <bcp14>MUST</b
cp14> be done before using the SRPA. To that aim, a
PCEP speaker <bcp14>MUST</bcp14> include the SRPA Type (6) in the
ASSOC-Type-List TLV and <bcp14>MUST</bcp14> receive the same from the
PCEP peer before using the SRPA (<xref target="Association-Type"
format="default"/>).</t>
<t>
An SRPA <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 speaker <bcp14>MUST</bcp14> send a PCErr message
with:</t>
<ul spacing="normal">
<li>Error-Type = 6 "Mandatory Object Missing"</li>
<li>Error-value = 22 "Missing SR Policy Association"</li>
</ul>
<t>
A given LSP <bcp14>MUST</bcp14> belong to one 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 speaker <bcp14>MUST</bcp14> send
a PCErr message with:</t>
<ul spacing="normal">
<li>Error-Type = 26 "Association Error"</li>
<li>Error-value = 7 "Cannot join the association group"</li>
</ul>
<t>
The existing behavior for the use of Binding SID (BSID) with an SR Policy
is already documented in <xref target="RFC9604" format="default"/>. If
BSID value allocation failed because of conflict with the BSID used by
another policy, then the PCEP peer <bcp14>MUST</bcp14> send a PCErr messag
e
with:</t>
<ul spacing="normal">
<li>Error-Type = 32 "Binding label/SID failure"</li>
<li>Error-value = 2 "Unable to allocate the specified binding value"</li>
</ul>
<t>The Association Parameters consists of:</t> <section anchor="SRPolicyIdentifier" numbered="true" toc="default">
<t> <name>SR Policy Identifier</name>
<list style="symbols"> <t>The SR Policy Identifier uniquely identifies an SR Policy <xref
<t>Association Type: Set to 6 "SR Policy Association".</t> target="RFC9256" format="default"/> within the SR domain. The SR Policy
<t>Association Source (IPv4/IPv6): Set to the headend value of the SR Po Identifier is assigned by the PCEP peer originating the LSP and
licy, as defined in <xref target="RFC9256"/> Section 2.1.</t> <bcp14>MUST</bcp14> be uniform across all the PCEP sessions.
<t>Association ID (16-bit): Always set to the numeric value "1".</t> Candidate Paths within an SR Policy <bcp14>MUST</bcp14> carry the same
<t>Extended Association ID TLV: Mandatory TLV for SR Policy Association. SR Policy Identifiers in their SRPAs. Candidate Paths within an SR
Encodes the Color and Endpoint of the SR Policy (<xref target="Extended-Associat Policy <bcp14>MUST NOT</bcp14> change their SR Policy Identifiers for
ion-ID-TLV-FORMAT"/>).</t> the lifetime of the PCEP session. If the above conditions are not
</list> satisfied, the receiving PCEP speaker <bcp14>MUST</bcp14> send a PCEP
</t> Error (PCErr) message with:</t>
<ul spacing="normal">
<li>Error-Type = 26 "Association Error"</li>
<li>Error-value = 20 "SR Policy Identifier Mismatch"</li>
</ul>
<t>The SR Policy Identifier consists of:</t>
<ul spacing="normal">
<li>
<t>Headend router where the SR Policy originates.</t>
</li>
<li>
<t>Color of the SR Policy (<xref target="RFC9256" sectionFormat="com
ma" section="2.1"/>).</t>
</li>
<li>
<t>Endpoint of the SR Policy (<xref target="RFC9256" sectionFormat="
comma" section="2.1"/>).</t>
</li>
</ul>
</section>
<section anchor="SRPolicyCandidatePathIdentifier" numbered="true" toc="def
ault">
<name>SR Policy Candidate Path Identifier</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 originatin
g
the LSP. Candidate Paths within an SR Policy <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 Policy
<bcp14>MUST NOT</bcp14> carry the same SR Policy Candidate Path
Identifiers in their SRPAs. If the above conditions are not
satisfied, the PCEP speaker <bcp14>MUST</bcp14> send a PCErr message
with:</t>
<ul spacing="normal">
<li>Error-Type = 26 "Association Error"</li>
<li>Error-value = 21 "SR Policy Candidate Path Identifier Mismatch"</li>
</ul>
<t>The SR Policy Candidate Path Identifier consists of:</t>
<ul spacing="normal">
<li>
<figure anchor="Extended-Association-ID-TLV-FORMAT" title="Extended Association <t>Protocol-Origin (<xref target="RFC9256" sectionFormat="comma" sec
ID TLV Format"> tion="2.3"/>)</t>
<artwork align="center"><![CDATA[ </li>
0 1 2 3 <li>
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 <t>Originator (<xref target="RFC9256" sectionFormat="comma" section=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "2.4"/>)</t>
| Type = 31 | Length = 8 or 20 | </li>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <li>
| Color | <t>Discriminator (<xref target="RFC9256" sectionFormat="comma" secti
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ on="2.5"/>)</t>
~ Endpoint ~ </li>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </ul>
]]></artwork> </section>
</figure> <section anchor="SRPolicyCandidatePathAttributes" numbered="true" toc="def
ault">
<name>SR Policy Candidate Path Attributes</name>
<t>SR Policy Candidate Path Attributes carry optional, non-key
information about a Candidate Path and <bcp14>MAY</bcp14> change
during the lifetime of an LSP. SR Policy Candidate Path Attributes
consist of:</t>
<ul spacing="normal">
<li>
<t>Candidate Path preference (<xref target="RFC9256" sectionFormat="
comma" section="2.7"/>)</t>
</li>
<li>
<t>Candidate Path name (<xref target="RFC9256" sectionFormat="comma"
section="2.6"/>)</t>
</li>
<li>
<t>SR Policy name (<xref target="RFC9256" sectionFormat="comma" sect
ion="2.1"/>)</t>
</li>
</ul>
</section>
<section anchor="AssociationParameters" numbered="true" toc="default">
<name>Association Parameters</name>
<t>Type: Extended Association ID TLV, type = 31 <xref target="RFC8697"/>.</t> <t>Per <xref target="RFC9256" sectionFormat="of" section="2.1"
format="default"/>, an SR Policy is identified through the &lt;Headend,
Color, Endpoint&gt; tuple.</t>
<t>Length: 8 octets if IPv4 address or 20 octets if IPv6 address is encoded in t he Endpoint field.</t> <t>The association parameters consist of:</t>
<t>Color: unsigned non-zero 32-bit integer value, SR Policy color per <xref targ <dl spacing="normal" newline="false">
et="RFC9256" sectionFormat="of" section="2.1"/>.</t> <dt>Association Type:</dt><dd>Set to 6 "SR Policy Association".</dd>
<dt>Association Source (IPv4/IPv6):</dt><dd>Set to the headend value
of the SR Policy, as defined in <xref target="RFC9256"
sectionFormat="comma" section="2.1"/>.</dd>
<dt>Association ID (16 bit):</dt><dd>Always set to the numeric value 1
.</dd>
<dt>Extended Association ID TLV:</dt><dd><t>Mandatory TLV for an
SRPA. Encodes the Color and Endpoint of the SR Policy (<xref
target="Extended-Association-ID-TLV-FORMAT" format="default"/>).</t>
<t>Endpoint: can be either IPv4 (4 octets) or IPv6 address (16 octets). <figure anchor="Extended-Association-ID-TLV-FORMAT">
This value MAY be different from the one contained in the Destination address fi <name>Extended Association ID TLV Format</name>
eld in the END-POINTS object, or in the Tunnel Endpoint Address field in the LSP <artwork align="center" name="" type="" alt=""><![CDATA[
-IDENTIFIERS TLV (<xref target="RFC9256" sectionFormat="of" section="2.1"/>).</t 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>
</figure>
<t>If a PCEP speaker receives an SRPA object <!-- [rfced] We note that Figure 1 differs slightly from the other TLV format
whose Association Parameters do not follow the above specification, figures in this document. Specifically, Figure 1 contains values for Type
then the PCEP speaker MUST send a PCErr message with and Length within the figure itself. Do you want to remove these values from
Error-Type = 26 "Association Error", Error-Value = 20 "SR Policy Identifier Mism Figure 1 for consistency with the other figures in this document?
atch".</t>
<t>The encoding choice of the Association Parameters in this way is meant to gua rantee that there is no possibility of a race condition when multiple PCEP speak ers want to associate the same SR Policy at the same time. By adhering to this f ormat, all PCEP speakers come up with the same Association Parameters independen tly of each other based on the SR Policy parameters <xref target="RFC9256"/>.</t > Figure 1:
<t> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint | Type = 31 | Length = 8 or 20 |
contained in the &#60;headend, color, endpoint&#62; tuple. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example use case is to terminate the SR Policy before reaching the Endpoint a
nd have decapsulated traffic be forwarded the rest of the path to the Endpoint n
ode using the native Interior Gateway Protocol (IGP) path(s).
In this example, the destination of the SR Policy Candidate Paths will be some n
ode 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 LSP-IDENTIFIERS TLV, per the usual PCEP procedure.
When neither the END-POINTS object nor LSP-IDENTIFIERS TLV is present,
the PCEP speaker MUST extract the destination from the Endpoint field in the SRP
A Extended Association ID TLV.
</t>
<t> Figure 2:
SR Policy with Color-Only steering is signaled with the Endpoint value set to un
specified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per <xref target="RFC9256" sec
tionFormat="of" section="8.8."/>.
</t>
</section> <!-- AssociationParameters --> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<section anchor="AssociationInformation" title="Association Information"> FYI, we updated the first list item after Figure 1 for consistency with
the other lists/figures.
<t>The SRPA object may carry the following TLVs:</t> Original:
Type: Extended Association ID TLV, type = 31 [RFC8697].
<t> Current:
<list style="symbols"> Type: 31 for the Extended Association ID TLV [RFC8697].
<t>SRPOLICY-POL-NAME TLV (<xref target="Policy-name-tlv"/>): (optional) -->
encodes the SR Policy Name string.</t> <dl spacing="normal" newline="false">
<t>SRPOLICY-CPATH-ID TLV (<xref target="Cpath-identifier-tlv"/>): (manda <dt>Type:</dt><dd>31 for the Extended Association ID TLV <xref
tory) encodes the SR Policy Candidate Path Identifier.</t> target="RFC8697" format="default"/>.</dd>
<t>SRPOLICY-CPATH-NAME TLV (<xref target="SRPOLICY-CPATH-NAME"/>): (opti <dt>Length:</dt><dd>8 octets if IPv4 address or 20 octets if IPv6
onal) encodes the SR Policy Candidate Path string name.</t> address is encoded in the Endpoint field.</dd>
<t>SRPOLICY-CPATH-PREFERENCE TLV (<xref target="Cpath-preference-tlv"/>) <dt>Color:</dt><dd>Unsigned non-zero 32-bit integer value, SR Policy
: (optional) encodes the SR Policy Candidate Path preference value.</t> color per <xref target="RFC9256" sectionFormat="of" section="2.1"
</list> format="default"/>.</dd>
</t> <dt>Endpoint:</dt><dd>Can be either IPv4 (4 octets) or IPv6 address
(16 octets). This value <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" format="default"/>).</dd>
</dl>
</dd>
</dl>
<t>If a PCEP speaker receives an SRPA object whose association
parameters do not follow the above specification, then the PCEP
speaker <bcp14>MUST</bcp14> send a PCErr message with:</t>
<ul spacing="normal">
<li>Error-Type = 26 "Association Error"</li>
<li>Error-value = 20 "SR Policy Identifier Mismatch"</li>
</ul>
<t>The encoding choice of the association 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 same association parameters independently of each other based
on the SR Policy parameters <xref target="RFC9256"
format="default"/>.</t>
<t>The last hop of a computed SR Policy Candidate Path
<bcp14>MAY</bcp14> differ from the Endpoint contained in the
&lt;Headend, Color, Endpoint&gt; 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 usua
l
PCEP procedure. When neither the END-POINTS object nor
the LSP-IDENTIFIERS TLV is present, the PCEP speaker <bcp14>MUST</bcp14>
extract the destination from the Endpoint field in the SRPA Extended
Association ID TLV.</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"
format="default"/>.</t>
</section>
<t>When a mandatory TLV is missing from an SRPA object, the PCEP speaker MUST se <section anchor="AssociationInformation" numbered="true" toc="default">
nd a PCErr message with <name>Association Information</name>
Error-Type = 6 "Mandatory Object Missing", Error-Value = 21 "Missing SR Policy M <t>The SRPA object may carry the following TLVs:</t>
andatory TLV".</t> <dl spacing="normal" newline="false">
<dt>SRPOLICY-POL-NAME TLV (<xref target="Policy-name-tlv"
format="default"/>):</dt><dd>(optional) encodes the SR Policy Name
string.</dd>
<dt>SRPOLICY-CPATH-ID TLV (<xref target="Cpath-identifier-tlv"
format="default"/>):</dt><dd>(mandatory) encodes the SR Policy
Candidate Path Identifier.</dd>
<dt>SRPOLICY-CPATH-NAME TLV (<xref target="SRPOLICY-CPATH-NAME"
format="default"/>):</dt><dd>(optional) encodes the SR Policy
Candidate Path string name.</dd>
<dt>SRPOLICY-CPATH-PREFERENCE TLV (<xref
target="Cpath-preference-tlv"
format="default"/>):</dt><dd>(optional) encodes the SR Policy
Candidate Path preference value.</dd>
</dl>
<t>When a mandatory TLV is missing from an SRPA object, the PCEP speaker
<bcp14>MUST</bcp14> send a PCErr message with:</t>
<ul spacing="normal">
<li>Error-Type = 6 "Mandatory Object Missing"</li>
<li>Error-value = 21 "Missing SR Policy Mandatory 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 others
<bcp14>MUST</bcp14> be silently ignored.</t>
<t>Only one TLV instance of each TLV type can be carried in an SRPA object, and <!--[rfced] FYI, several section titles have been updated to exactly
only the first occurrence is processed. Any others MUST be silently ignored.</t match the TLV name. If you prefer the original section titles, please
> let us know. For example:
<section anchor="Policy-name-tlv" title="SR Policy Name TLV"> Original:
4.5.1. SR Policy Name TLV
4.5.2. SR Policy Candidate Path Identifier TLV
<t> Current:
The SRPOLICY-POL-NAME TLV (<xref target="SRPOLICY-POL-NAME-TLV-FORMAT"/>) is an 4.5.1. SRPOLICY-POL-NAME TLV
optional TLV for the SRPA object. It is RECOMMENDED that the size of the name fo 4.5.2. SRPOLICY-CPATH-ID TLV
r the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate -->
long names to 255 bytes to simplify interoperability with other protocols.
</t>
<figure anchor="SRPOLICY-POL-NAME-TLV-FORMAT" title="SRPOLICY-POL-NAME TLV Forma <section anchor="Policy-name-tlv" numbered="true" toc="default">
t"> <name>SRPOLICY-POL-NAME TLV</name>
<artwork align="center"><![CDATA[ <t>The SRPOLICY-POL-NAME TLV (<xref
target="SRPOLICY-POL-NAME-TLV-FORMAT" format="default"/>) is an
optional TLV for the SRPA object. It is <bcp14>RECOMMENDED</bcp14>
that the size of the name for the SR Policy is limited to 255
bytes. Implementations <bcp14>MAY</bcp14> choose to truncate long
names to 255 bytes to simplify interoperability with other
protocols.</t>
<figure anchor="SRPOLICY-POL-NAME-TLV-FORMAT">
<name>SRPOLICY-POL-NAME TLV Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ SR Policy Name ~ ~ SR Policy Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>56 for the SRPOLICY-POL-NAME TLV.</dd>
<t>Type: 56 for "SRPOLICY-POL-NAME" TLV.</t> <dt>Length:</dt><dd>Indicates the length of the value portion of
the TLV in octets and <bcp14>MUST</bcp14> be greater than 0. The
<t>Length: indicates the length of the value portion of the TLV in octets and MU TLV <bcp14>MUST</bcp14> be zero-padded so that the TLV is 4-octet
ST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet ali aligned. Padding is not included in the Length field.</dd>
gned. Padding is not included in the Length field.</t> <dt>SR Policy Name:</dt><dd>SR Policy name, as defined in <xref
target="RFC9256" sectionFormat="of" section="2.1"
<t>SR Policy Name: SR Policy name, as defined in <xref target="RFC9256" sectionF format="default"/>. It <bcp14>MUST</bcp14> be a string of
ormat="of" section="2.1"/>. It MUST be a string of printable ASCII <xref target= printable ASCII <xref target="RFC0020" format="default"/>
"RFC0020"/> characters, without a NULL terminator.</t> characters, without a NULL terminator.</dd>
</dl>
</section> <!-- Policy-name-tlv --> </section>
<section anchor="Cpath-identifier-tlv" title="SR Policy Candidate Path Identifie <section anchor="Cpath-identifier-tlv" numbered="true" toc="default">
r TLV"> <name>SRPOLICY-CPATH-ID TLV</name>
<t> <t>The SRPOLICY-CPATH-ID TLV (<xref
The SRPOLICY-CPATH-ID TLV (<xref target="SRPOLICY-CPATH-ID-TLV-FORMAT"/>) is a m target="SRPOLICY-CPATH-ID-TLV-FORMAT" format="default"/>) is a
andatory TLV for the SRPA object. mandatory TLV for the SRPA object.</t>
</t>
<figure anchor="SRPOLICY-CPATH-ID-TLV-FORMAT" title="SRPOLICY-CPATH-ID TLV Forma <figure anchor="SRPOLICY-CPATH-ID-TLV-FORMAT">
t"> <name>SRPOLICY-CPATH-ID TLV Format</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto. Origin | Reserved | | Proto-Origin | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ASN | | Originator ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Originator Address | | Originator Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator | | Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>57 for the SRPOLICY-CPATH-ID TLV.</dd>
<t>Type: 57 for "SRPOLICY-CPATH-ID" TLV.</t> <dt>Length:</dt><dd>28.</dd>
<dt>Protocol-Origin:</dt><dd>8-bit unsigned integer value that
<t>Length: 28.</t> encodes the Protocol-Origin. The values of this field are
specified in the IANA registry "SR Policy Protocol Origin" under the
<t>Protocol Origin: 8-bit unsigned integer value that encodes the protocol origi "Segment Routing" registry group, which is introduced in <xref
n. The values of this field are specified in IANA registry "SR Policy Protocol O section="8.4" target="I-D.ietf-idr-bgp-ls-sr-policy"
rigin" under "Segment Routing" registry group, which was introduced in Section 8 format="default"/>. Note that in the PCInitiate message <xref
.4 of <xref target="I-D.ietf-idr-bgp-ls-sr-policy"/>. target="RFC8281" format="default"/>, the Protocol-Origin is always
Note that in the PCInitiate message <xref target="RFC8281"/>, the Protocol Origi set to 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)". The
n is always set to 10 - "PCEP (In PCEP or when BGP-LS Producer is PCE)". The "SR "SR Policy Protocol Origin" IANA registry includes a combination
Policy Protocol Origin" IANA registry includes a combination of values intended of values intended for use in PCEP and BGP-LS. When the registry
for use in PCEP and BGP-LS. When the registry contains two variants of values a contains two variants of values associated with the mechanism or
ssociated with the mechanism or protocol used for provisioning of the Candidate protocol used for provisioning of the Candidate Path, for example
Path, for example 1 - "PCEP" and 10 - "PCEP (In PCEP or when BGP-LS Producer is 1 - "PCEP" and 10 - "PCEP (In PCEP or when BGP-LS Producer is
PCE)", the "(In PCEP or when BGP-LS Producer is PCE)" variants MUST be used in P PCE)", the "(In PCEP or when BGP-LS Producer is PCE)", then variants
CEP.</t> <bcp14>MUST</bcp14> be used in PCEP.</dd>
<dt>Reserved:</dt><dd>This field <bcp14>MUST</bcp14> be set to zero
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored on transmission and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
on receipt.</t> <dt>Originator Autonomous System Number (ASN):</dt><dd>Represented
as a 32-bit unsigned integer value, part of the originator
<t>Originator Autonomous System Number (ASN): Represented as a 32-bit unsigned i identifier, as specified in <xref format="default" section="2.4"
nteger value, part of the originator identifier, as specified in <xref format="d sectionFormat="of" target="RFC9256"/>. When sending a PCInitiate
efault" section="2.4" sectionFormat="of" target="RFC9256"/>. message <xref target="RFC8281" format="default"/>, the PCE is the
When sending a PCInitiate message <xref target="RFC8281"/>, the PCE is the origi originator of the Candidate Path. If the PCE is configured with an
nator of the Candidate Path. ASN, then it <bcp14>MUST</bcp14> set it; otherwise, the ASN is set to
If the PCE is configured with an ASN, then it MUST set it, otherwise the ASN is 0.</dd>
set to 0. <dt>Originator Address:</dt><dd>Represented as a 128-bit value as
</t> specified in <xref format="default" section="2.4" sectionFormat="of"
target="RFC9256"/>. When sending a PCInitiate message, the PCE is
<t>Originator Address: Represented as a 128-bit value as specified in <xref form acting as the originator and therefore <bcp14>MAY</bcp14> set this
at="default" section="2.4" sectionFormat="of" target="RFC9256"/>. When sending a to an address that it owns.</dd>
PCInitiate message, the PCE is acting as the originator and therefore MAY set t <dt>Discriminator:</dt><dd>32-bit unsigned integer value that
his to an address that it owns. encodes the Discriminator of the Candidate Path, as specified in
</t> <xref target="RFC9256" sectionFormat="of" section="2.5"
format="default"/>. This is the field that mainly distinguishes
<t>Discriminator: 32-bit unsigned integer value that encodes the Discriminator o different SR Policy Candidate Paths, coming from the same
f the Candidate Path, as specified in <xref target="RFC9256" sectionFormat="of" originator. It is allowed to be any number in the 32-bit range.</dd>
section="2.5"/>. </dl>
This is the field that mainly distinguishes different SR Policy Candidate Paths, </section>
coming from the same originator. It is allowed to be any number in the 32-bit r
ange.
</t>
</section> <!-- Cpath-identifier-tlv -->
<section anchor="SRPOLICY-CPATH-NAME" title="SR Policy Candidate Path Name TLV">
<t> <section anchor="SRPOLICY-CPATH-NAME" numbered="true" toc="default">
The SRPOLICY-CPATH-NAME TLV (<xref target="SRPOLICY-CPATH-NAME-TLV-FORMAT"/>) is <name>SRPOLICY-CPATH-NAME TLV</name>
an optional TLV for the SRPA object. It is RECOMMENDED that the size of the nam <t>The SRPOLICY-CPATH-NAME TLV (<xref
e for the SR Policy is limited to 255 bytes. Implementations MAY choose to trunc target="SRPOLICY-CPATH-NAME-TLV-FORMAT" format="default"/>) is an
ate long names to 255 bytes to simplify interoperability with other protocols. optional TLV for the SRPA object. It is <bcp14>RECOMMENDED</bcp14>
</t> that the size of the name for the SR Policy is limited to 255
bytes. Implementations <bcp14>MAY</bcp14> choose to truncate long
names to 255 bytes to simplify interoperability with other
protocols.</t>
<figure anchor="SRPOLICY-CPATH-NAME-TLV-FORMAT" title="SRPOLICY-CPATH-NAME TLV F <figure anchor="SRPOLICY-CPATH-NAME-TLV-FORMAT">
ormat"> <name>SRPOLICY-CPATH-NAME TLV Format</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ SR Policy Candidate Path Name ~ ~ SR Policy Candidate Path Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>58 for the SRPOLICY-CPATH-NAME TLV.</dd>
<t>Type: 58 for "SRPOLICY-CPATH-NAME" TLV.</t> <dt>Length:</dt><dd>Indicates the length of the value portion of
the TLV in octets and <bcp14>MUST</bcp14> be greater than 0. The
<t>Length: indicates the length of the value portion of the TLV in octets and MU TLV <bcp14>MUST</bcp14> be zero-padded so that the TLV is 4-octet
ST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet ali aligned. Padding is not included in the Length field.</dd>
gned. Padding is not included in the Length field.</t> <dt>SR Policy Candidate Path Name:</dt><dd>SR Policy Candidate
Path Name, as defined in <xref target="RFC9256" sectionFormat="of"
<t>SR Policy Candidate Path Name: SR Policy Candidate Path Name, as defined in < section="2.6" format="default"/>. It <bcp14>MUST</bcp14> be a
xref target="RFC9256" sectionFormat="of" section="2.6"/>. It MUST be a string of string of printable ASCII characters, without a NULL
printable ASCII characters, without a NULL terminator.</t> terminator.</dd>
</dl>
</section> <!-- SRPOLICY-CPATH-NAME --> </section>
<section anchor="Cpath-preference-tlv" title="SR Policy Candidate Path Preferenc
e TLV">
<t> <section anchor="Cpath-preference-tlv" numbered="true" toc="default">
The SRPOLICY-CPATH-PREFERENCE TLV (<xref target="SRPOLICY-CPATH-PREFERENCE-TLV-F <name>SRPOLICY-CPATH-PREFERENCE TLV</name>
ORMAT"/>) is an optional TLV for the SRPA object. <t>The SRPOLICY-CPATH-PREFERENCE TLV (<xref
If the TLV is absent, then default Preference value is 100, per <xref format="de target="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT" format="default"/>) is
fault" section="2.7" sectionFormat="of" target="RFC9256"/>. an optional TLV for the SRPA object. If the TLV is absent, then the
</t> default Preference value is 100, per <xref format="default"
section="2.7" sectionFormat="of" target="RFC9256"/>.</t>
<figure anchor="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT" title="SRPOLICY-CPATH-PREF <figure anchor="SRPOLICY-CPATH-PREFERENCE-TLV-FORMAT">
ERENCE TLV Format"> <name>SRPOLICY-CPATH-PREFERENCE TLV Format</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>59 for the SRPOLICY-CPATH-PREFERENCE TLV.</dd>
<t>Type: 59 for "SRPOLICY-CPATH-PREFERENCE" TLV.</t> <dt>Length:</dt><dd>4.</dd>
<dt>Preference:</dt><dd>32-bit unsigned integer value that encodes t
<t>Length: 4.</t> he
preference of the Candidate Path as defined in <xref
<t>Preference: 32-bit unsigned integer value that encodes preference of the Cand format="default" section="2.7" sectionFormat="of"
idate Path as defined in <xref format="default" section="2.7" sectionFormat="of" target="RFC9256"/>.</dd>
target="RFC9256"/>.</t> </dl>
</section>
</section> <!-- Cpath-preference-tlv --> </section>
</section>
</section> <!-- AssociationInformation -->
</section> <!-- Association -->
<section anchor="Other-mechanisms" title="SR Policy Signaling Extensions">
<t>This section introduces mechanisms described for SR Policies in <xref target=
"RFC9256"/> to PCEP.
These extensions do not make use of the SRPA for signaling in PCEP therefore can
not rely on the Association capability negotiation in ASSOC-Type-List TLV and se
parate capability negotiation is required.
</t>
<t> <!-- [rfced] For clarity, may we update this text as follows?
This document specifies four new TLVs to be carried in the OPEN or LSP object This includes adding "they" after "therefore", adding punctuation,
. and splitting the second sentence into two sentences.
Only one TLV instance of each type can be carried, and only the first
occurrence is processed. Any others MUST be ignored.
</t>
<section anchor="Capability-tlv" title="SR Policy Capability TLV"> 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.
<t> Perhaps:
The SRPOLICY-CAPABILITY TLV (<xref target="SRPOLICY-CAPABILITY-TLV-FORMAT"/>) is This section introduces mechanisms described for SR Policies in
a TLV for the OPEN object. [RFC9256] to PCEP. These extensions do not make use of the SRPA for
It is used at session establishment to learn the peer's signaling in PCEP; therefore, they cannot rely on the Association
capabilities with respect to SR Policy. capability negotiation in the ASSOC-Type-List TLV. Instead, separate
Implementations that support SR Policy MUST include SRPOLICY-CAPABILITY TLV in t capability negotiation is required.
he OPEN object if the extension is enabled. -->
In addition, the ASSOC-Type-List TLV containing SRPA Type (6) MUST be present in
the OPEN object, as specified in <xref target="Association"/>.</t>
<t>If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV is <section anchor="Other-mechanisms" numbered="true" toc="default">
not exchanged, then the PCEP speaker MUST send a PCErr message with Error- <name>SR Policy Signaling Extensions</name>
Type = 10 ("Reception of an invalid object") and Error-Value = TBD2 <t>This section introduces mechanisms described for SR Policies in <xref
("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP target="RFC9256" format="default"/> to PCEP. These extensions do not
session.</t> make use of the SRPA for signaling in PCEP, and therefore cannot rely on t
he
Association capability negotiation in the ASSOC-Type-List TLV and separate
capability negotiation is required.</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 others <bcp14>MUST</bcp14> be
ignored.</t>
<figure anchor="SRPOLICY-CAPABILITY-TLV-FORMAT" title="SRPOLICY-CAPABILITY TLV F <section anchor="Capability-tlv" numbered="true" toc="default">
ormat"> <name>SRPOLICY-CAPABILITY TLV</name>
<artwork align="center"><![CDATA[ <t>The SRPOLICY-CAPABILITY TLV (<xref
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 Policy <bcp14>MUST</bcp14> include the SRPOLICY-CAPABILITY TL
V
in the OPEN object if the extension is enabled. In addition, the
ASSOC-Type-List TLV containing SRPA Type (6) <bcp14>MUST</bcp14> be
present in the OPEN object, as specified in <xref target="Association"
format="default"/>.</t>
<t>If a PCEP speaker receives an SRPA but the SRPOLICY-CAPABILITY TLV is
not exchanged, then the PCEP speaker <bcp14>MUST</bcp14> send a PCErr
message with Error-Type = 10 "Reception of an invalid object" and
Error-value = 44 "Missing SRPOLICY-CAPABILITY TLV" and
<bcp14>MUST</bcp14> then close the PCEP session.</t>
<figure anchor="SRPOLICY-CAPABILITY-TLV-FORMAT">
<name>SRPOLICY-CAPABILITY TLV Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |L| |I|E|P| | Flags |L| |I|E|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal" newline="false">
<t>Type: 71 for "SRPOLICY-CAPABILITY" TLV.</t> <dt>Type:</dt><dd>71 for the SRPOLICY-CAPABILITY TLV.</dd>
<dt>Length:</dt><dd>4.</dd>
<t>Length: 4.</t> <dt>Flags:</dt>
<dd>
<t>Flags (32 bits):</t>
<t> The following flags are currently defined:</t>
<list style="symbols">
<t>P-flag (Computation Priority): If set to '1' by a PCEP speaker, the P flag in
dicates that the PCEP speaker supports the handling of COMPUTATION-PRIORITY TLV
for the SR Policy
(<xref target="Computation-priority-tlv"/>).
If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the COMP
UTATION-PRIORITY TLV and MUST ignore it on receipt.
</t>
<t>E-Flag (Explicit NULL Label Policy): If set to '1' by a PCEP speaker, the E f
lag indicates that the PCEP speaker supports the handling of Explicit Null Label
Policy (ENLP) TLV for the SR Policy
(<xref target="enlp-tlv"/>).
If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the ENLP
TLV and MUST ignore it on receipt.
</t>
<t>I-Flag (Invalidation): If set to '1' by a PCEP speaker, the I flag indicates
that the PCEP speaker supports the handling of INVALIDATION TLV for the SR Polic
y
(<xref target="Invalidation-tlv"/>).
If this flag is set to 0, then the receiving PCEP speaker MUST NOT send the INVA
LIDATION TLV and MUST ignore it on receipt.
</t>
<t>L-Flag (Stateless Operation): If set to '1' by a PCEP speaker, the L flag ind <t>32 bits. The following flags are currently defined:</t>
icates that the PCEP speaker supports the stateless (PCReq/PCRep) operations for <dl spacing="normal" newline="false">
the SR Policy <dt>P-flag (Computation Priority):</dt>
(<xref target="Stateless-oper"/>). <dd>If set to 1 by a PCEP speaker, the P-flag indicates that the
If the PCE set this flag to 0, then the PCC MUST NOT send PCReq messages to th PCEP speaker supports the handling of the COMPUTATION-PRIORITY TLV
is PCE for the SR Policy. for the SR Policy (<xref target="Computation-priority-tlv"
</t> format="default"/>). If this flag is set to 0, then the
receiving PCEP speaker <bcp14>MUST NOT</bcp14> send the
COMPUTATION-PRIORITY TLV and <bcp14>MUST</bcp14> ignore it on
receipt.</dd>
</list> <dt>E-flag (Explicit NULL Label Policy):</dt>
<dd>If set to 1 by a PCEP speaker, the E-flag indicates that the
PCEP speaker supports the handling of the Explicit Null Label Polic
y
(ENLP) TLV for the SR Policy (<xref target="enlp-tlv"
format="default"/>). If this flag is set to 0, then the
receiving PCEP speaker <bcp14>MUST NOT</bcp14> send the ENLP TLV
and <bcp14>MUST</bcp14> ignore it on receipt.</dd>
<t>Unassigned bits MUST be set to '0' on transmission and MUST be ignored on rec <dt>I-flag (Invalidation):</dt>
eipt. More flags can be assigned in the future per (<xref target="sr_policy_cap_ <dd>If set to 1 by a PCEP speaker, the I-flag indicates that the
flag_field"/>).</t> PCEP speaker supports the handling of the INVALIDATION TLV for the
SR Policy (<xref target="Invalidation-tlv" format="default"/>).
If this flag is set to 0, then the receiving PCEP speaker
<bcp14>MUST NOT</bcp14> send the INVALIDATION TLV and
<bcp14>MUST</bcp14> ignore it on receipt.</dd>
</section> <!-- Capability-tlv --> <dt>L-flag (Stateless Operation):</dt>
<dd>If set to 1 by a PCEP speaker, the L-flag indicates that the
PCEP speaker supports the stateless (PCReq/PCRep) operations for
the SR Policy (<xref target="Stateless-oper"
format="default"/>). If the PCE set this flag to 0, then the
PCC <bcp14>MUST NOT</bcp14> send PCReq messages to this PCE for
the SR Policy.</dd>
</dl>
</dd>
</dl>
<t>Unassigned bits <bcp14>MUST</bcp14> be set to 0 on transmission
and <bcp14>MUST</bcp14> be ignored on receipt. More flags can be
assigned in the future per (<xref target="sr_policy_cap_flag_field"
format="default"/>).</t>
</section>
<section anchor="lsp-object-tlvs" title="LSP Object TLVs"> <section anchor="lsp-object-tlvs" numbered="true" toc="default">
<name>LSP Object 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" format="default"/>.</t>
<t>This section is introducing three new TLVs to be carried in LSP object introd <section anchor="Computation-priority-tlv" numbered="true" toc="default"
uced in <xref target="RFC8231" sectionFormat="of" section="7.3"/>.</t> >
<name>COMPUTATION-PRIORITY TLV</name>
<t>The COMPUTATION-PRIORITY TLV (<xref
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" format="default"/>. If the TLV is absent from the
LSP object, and the P-flag in the SRPOLICY-CAPABILITY TLV is set to
1, a default Priority value of 128 is used.</t>
<figure anchor="COMPUTATION-PRIORITY-TLV-FORMAT">
<name>COMPUTATION-PRIORITY TLV Format</name>
<artwork 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>
</figure>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>68 for the 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. The lowest value is the highest
priority.</dd>
<dt>Reserved:</dt><dd>This field <bcp14>MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt.</dd>
</dl>
</section>
<section anchor="Computation-priority-tlv" title="Computation Priority TLV"> <section anchor="enlp-tlv" numbered="true" toc="default">
<name>Explicit Null Label Policy (ENLP) TLV</name>
<t>The COMPUTATION-PRIORITY TLV (<xref target="COMPUTATION-PRIORITY-TLV-FORMAT"/ <t>To steer an unlabeled IP packet into an SR Policy for the MPLS
>) is an optional TLV. data plane, it is necessary to push a label stack of one or more
It is used to signal the numerical computation priority, as specified in <xref t labels on that packet. The Explicit NULL Label Policy (ENLP) TLV is
arget="RFC9256" sectionFormat="of" section="2.12"/>. an optional TLV for the LSP object used to indicate whether an
If the TLV is absent from the LSP object and the P-flag in the SRPOLICY-CAPABILI Explicit NULL Label <xref target="RFC3032" format="default"/> must
TY TLV is set to 1, a default Priority value of 128 is used.</t> be pushed on an unlabeled IP packet before any other labels. The
contents of this TLV are used by the SR Policy manager 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
speaker <bcp14>MUST</bcp14> ignore the presence of this TLV for SRv6
Policies.</t>
<figure anchor="COMPUTATION-PRIORITY-TLV-FORMAT" title="COMPUTATION-PRIORITY TLV <figure anchor="ENLP-TLV-FORMAT">
Format"> <name>Explicit Null Label Policy (ENLP) TLV Format</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Reserved | | ENLP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>69 for the ENLP TLV.</dd>
<t>Type: 68 for "COMPUTATION-PRIORITY" TLV.</t> <dt>Length:</dt><dd>4.</dd>
<dt>ENLP:</dt><dd>Explicit NULL Label 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 SR Policy. The values of this field are specified in the IANA
registry "SR Policy ENLP Values" under the "Segment Routing" registr
y
group, which was introduced in <xref section="6.10"
target="RFC9830" format="default"/>.</dd>
<dt>Reserved:</dt><dd>This field <bcp14>MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt.</dd>
</dl>
<t>Length: 4.</t> <t>The ENLP unassigned values may be used for future extensions, and
implementations <bcp14>MUST</bcp14> ignore the ENLP TLV with
unrecognized values. The behavior signaled in this TLV
<bcp14>MAY</bcp14> be overridden by local configuration by the
network operator based on their deployment requirements. <xref
format="default" section="4.1" sectionFormat="of" target="RFC9256"/>
describes the behavior on the headend for the handling of the
explicit null label.</t>
<t>Priority: 8-bit unsigned integer value that encodes numerical priority with w hich this LSP is to be recomputed by the PCE upon topology change. Lowest value is the highest priority.</t> </section>
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored <section anchor="Invalidation-tlv" numbered="true" toc="default">
on receipt.</t> <name>INVALIDATION TLV</name>
</section> <!-- Computation-priority-tlv --> <t>The INVALIDATION TLV (<xref 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 the
Drop-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. The Drop-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 object <bcp14>MAY</bcp14> be empty if no valid path has been
computed.</t>
<section anchor="enlp-tlv" title="Explicit Null Label Policy (ENLP) TLV"> <t>The INVALIDATION TLV is used in both directions between PCEP peers: </t>
<t> <ul spacing="normal">
To steer an unlabeled IP packet into an SR policy for the MPLS data plane, i <li>PCE -&gt; PCC: The PCE specifies to the PCC whether to enable
t is necessary to push a label stack of one or more labels on that packet. or disable Drop-Upon-Invalid (Config).</li>
The Explicit NULL Label Policy (ENLP) TLV is an optional TLV for the LSP obj <li>PCC -&gt; PCE: The PCC reports the current setting of the
ect used to indicate whether an Explicit NULL Label <xref target="RFC3032"/> mus Drop-Upon-Invalid (Config) and also whether the LSP is currently
t be pushed on an unlabeled IP packet before any other labels. in the drop state (Oper).</li>
The contents of this TLV are used by the SR Policy Manager as described in < </ul>
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 N
ULL 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 speaker MUST ignore the presence of this TLV for S
Rv6 Policies.
</t>
<figure anchor="ENLP-TLV-FORMAT" title="Explicit Null Label Policy (ENLP) TLV Fo <figure anchor="INVALIDATION-TLV-FORMAT">
rmat"> <name>INVALIDATION TLV Format</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENLP | Reserved | | Oper | Config | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure>
<t>Type: 69 for "ENLP" TLV.</t> <dl spacing="normal" newline="false">
<dt>Type:</dt>
<dd>70 for the 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. It <bcp14>MUST</bcp14> be set to 0 by the PCE when sending
and <bcp14>MUST</bcp14> be ignored by the PCC upon receipt. See
<xref target="inval_oper_iana" format="default"/> for IANA
information.</t>
<t>Length: 4.</t> <figure anchor="OPER_INVAL_FLAGS">
<name>Oper State of Drop-Upon-Invalid Feature</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t> <ul indent="5">
ENLP (Explicit NULL Label Policy): 8-bit unsigned integer value that indicates <!--[rfced] Section 5.2.3 vs. IANA Considerations:
whether Explicit NULL labels are to be pushed on unlabeled IP packets Should this text be updated to match the IANA-registered description of
that are being steered into a given SR policy. each bit (which appears in Tables 6 and 7), or is it intentional for
The values of this field are specified in IANA registry "SR Policy ENLP Values Section 5.2.3 to differ?
" under "Segment Routing" registry group, which was introduced in Section 6.10 o
f <xref target="I-D.ietf-idr-sr-policy-safi"/>.
</t>
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt.</t> - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-op erational-flags
<t> Original:
The ENLP unassigned values may be used for future extensions and implementat * D: dropping - the LSP is actively dropping traffic as a result of
ions MUST ignore the ENLP TLV with unrecognized values. Drop-upon-invalid behavior being activated.
The behavior signaled in this TLV MAY be overridden by local configuration b
y 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 null l
abel.
</t>
</section> <!-- enlp-tlv --> Perhaps (if it should match the IANA registry, including the
capitalization change which we will request):
<section anchor="Invalidation-tlv" title="Invalidation TLV"> * D: Dropping - the LSP is currently attracting traffic and
actively dropping it.
<t>The INVALIDATION TLV (<xref target="INVALIDATION-TLV-FORMAT"/>) is an optiona - See https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-invalidation-co
l TLV. nfiguration-flags
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
the Drop-upon-invalid behavior,
specified in <xref format="default" section="8.2" sectionFormat="of" target="RFC
9256"/>.
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.
The Drop-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 object MAY be empty, if no valid path has been computed.
</t>
<t>
The INVALIDATION TLV is used in both directions between PCEP peers:
<list style="symbols">
<t>PCE -> PCC: PCE specifies to the PCC whether to enable or disable Drop-up
on-invalid (Config).</t>
<t>PCC -> PCE: PCC reports the current setting of the Drop-upon-invalid (Con
fig) and also whether the LSP is currently in the drop state (Oper).</t>
</list>
</t>
<figure anchor="INVALIDATION-TLV-FORMAT" title="INVALIDATION TLV Format"> Original:
<artwork align="center"><![CDATA[ * D: drop enabled - the Candidate Path has Drop-upon-invalid feature
0 1 2 3 enabled.
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>
</figure>
<t>Type: 70 for "INVALIDATION" TLV.</t> Perhaps (if it should match the IANA registry, including the capitalization
changes that we will request):
<t>Length: 4.</t> * 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>
<t>Oper: An 8-bit flag field that encodes the operational state of the LSP. It M <li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14> be
UST be set to 0 by the PCE when sending and MUST be ignored by the PCC upon rece set to zero upon transmission and <bcp14>MUST</bcp14> be ignored
ipt. upon receipt.</li>
See <xref target="inval_oper_iana"/> for IANA information. </ul>
</t> </dd>
<figure anchor="OPER_INVAL_FLAGS" title="Oper state of Drop-upon-invalid feature <dt>Config:</dt>
"> <dd><t>An 8-bit flag field that encodes the configuration of the LSP.
<artwork align="center"><![CDATA[ See <xref target="inval_config_iana" format="default"/> for IANA
0 1 2 3 4 5 6 7 information.</t>
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> <figure anchor="CONFIG_INVAL_FLAGS">
<list style="symbols"> <name>Config State of Drop-Upon-Invalid Feature</name>
<t>D: dropping - the LSP is actively dropping traffic as a result of Drop-up <artwork align="center" name="" type="" alt=""><![CDATA[
on-invalid behavior being activated.</t> 0 1 2 3 4 5 6 7
<t>The unassigned bits in the Flag octet MUST be set to zero upon transmissi +-+-+-+-+-+-+-+-+
on and MUST be ignored upon receipt.</t> | |D|
</list> +-+-+-+-+-+-+-+-+]]></artwork>
</t> </figure>
<t>Config: An 8-bit flag field that encodes the configuration of the LSP. <ul indent="5">
See <xref target="inval_config_iana"/> for IANA information. <li>D: Drop enabled - the Candidate Path has Drop-Upon-Invalid
</t> feature enabled.</li>
<li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14> be
set to zero upon transmission and <bcp14>MUST</bcp14> be ignored
upon receipt.</li>
</ul>
</dd>
<figure anchor="CONFIG_INVAL_FLAGS" title="Config state of Drop-upon-invalid fea <dt>Reserved:</dt>
ture"> <dd>This field <bcp14>MUST</bcp14> be set to zero on transmission
<artwork align="center"><![CDATA[ and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
0 1 2 3 4 5 6 7 </dl>
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> <section anchor="Invalidation-per-policy" numbered="true" toc="default
<list style="symbols"> ">
<t>D: drop enabled - the Candidate Path has Drop-upon-invalid feature enable <name>Drop-Upon-Invalid Applies to SR Policy</name>
d.</t> <t>The Drop-Upon-Invalid feature is somewhat special among the
<t>The unassigned bits in the Flag octet MUST be set to zero upon transmissi other SR Policy features in the way that it is enabled/disabled.
on and MUST be ignored upon receipt.</t> This feature is enabled only on the whole SR Policy, not on a
</list> particular Candidate Path of that SR Policy, i.e., when any
</t> Candidate Path has Drop-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 are invalid.</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?
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored Original:
on receipt.</t> Note that only one Candidate Path
needs to be reported to the PCE with the D (dropping) flag set.
<section anchor="Invalidation-per-policy" title="Drop-upon-invalid applies to SR Perhaps (if from Figure 10):
Policy"> 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 have Drop-Upon-Invalid enabled. If so, the SR Policy enters
the drop state and "activates" the highest preference Candidate
Path that has the Drop-Upon-Invalid enabled. Note that only one
Candidate Path needs to be reported to the PCE with the D (dropping)
flag set.</t>
</section>
</section>
</section>
<t> <section anchor="Stateless-oper" numbered="true" toc="default">
The Drop-upon-invalid feature is somewhat special among the other SR Policy feat <name>Updates to RFC 8231</name>
ures in the way that it is enabled/disabled. <t><xref format="default" section="5.8.2" sectionFormat="of"
This feature is enabled only on the whole SR Policy, not on a particular Candida target="RFC8231"/> allows delegation of an LSP in operationally down
te Path of that SR Policy, state, but at the same time mandates the use of PCReq before sending
i.e., when any Candidate Path has Drop-upon-invalid enabled, it means that the w PCRpt. This document updates <xref format="default" section="5.8.2"
hole SR Policy has the feature enabled. sectionFormat="of" target="RFC8231"/>, by making that section of <xref
As stated in <xref format="default" section="8.1" sectionFormat="of" target="RFC target="RFC8231" format="default"/> not applicable to SR Policy LSPs.
9256"/>, an SR Policy is invalid when all its Candidate Paths are invalid. Thus, when a PCC wants to delegate an SR Policy LSP, it
</t> <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 the
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 in the SRPOLICY-CAPABILITY TLV (see <xref
target="Capability-tlv" format="default"/>). When this flag is
cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peer
<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 Policy LSPs.</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 to apply.</t>
</section>
</section>
<t> <section numbered="true" toc="default">
Once all the Candidate Paths of an SR Policy have become invalid, then the SR Po <name>IANA Considerations</name>
licy checks whether any of the Candidate Paths <t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
have Drop-upon-invalid enabled. registry at <eref brackets="angle" target="https://www.iana.org/assignments/
If so, the SR Policy enters the drop state and "activates" the highest preferenc pcep"/>.</t>
e Candidate Path which has <section anchor="Association-Type" numbered="true" toc="default">
the Drop-upon-invalid enabled. <name>Association Type</name>
Note that only one Candidate Path needs to be reported to the PCE with the D (dr <t>This document defines a new Association Type: SR Policy
opping) flag set. Association. IANA has made the following assignment in
</t> the "ASSOCIATION Type Field" registry within the "Path Computation
Element Protocol (PCEP) Numbers" registry group:</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>
</section> <!-- Invalidation-per-policy --> <section numbered="true" toc="default">
<name>PCEP TLV Type Indicators</name>
<t>This document defines eight new TLVs for carrying additional
information about SR Policy and SR Policy Candidate Paths. IANA
has made the following assignments in the existing "PCEP
TLV Type Indicators" registry:</t>
</section> <!-- Invalidation-tlv --> <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> <!-- lsp-object-tlvs --> </section>
<section numbered="true" toc="default">
<name>PCEP Errors</name>
<t>This document defines the following:</t>
<ul>
<li>one new Error-value within the "Mandatory Object Missing" Error-Typ
e,</li>
<li>two new Error-values within the "Association Error" Error-Type, and
</li>
<li>one new Error-value within the "Reception of an invalid object".</l
i>
</ul>
<t>IANA has made the following assignments in the
"PCEP-ERROR Object Error Types and Values" registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry group.</t>
<section anchor="Stateless-oper" title="Update to RFC 8231"> <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 Missing</td>
<td></td>
<td><xref target="RFC5440"/></td>
</tr>
<tr>
<td></td>
<td>21: Missing SR Policy Mandatory 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 Identifers Mismatch</td>
<td>RFC 9862</td>
</tr>
<tr>
<td></td>
<td>21: SR Policy Candidate Path Identifier Mismatch</td>
<td>RFC 9862</td>
</tr>
</tbody>
</table>
<t>IANA has made the following assigments in the "PCEP-ERROR Object Erro
r Types and Values" registry of the "Path Computation Element Protocol (PCEP) Nu
mbers" registry group.</t>
<t> <table>
<xref format="default" section="5.8.2" sectionFormat="of" target="RFC8231"/>, al <thead>
lows delegation of an LSP in operationally down state, <tr>
but at the same time mandates the use of PCReq before sending PCRpt. <th>Error-Type</th>
This document updates <xref format="default" section="5.8.2" sectionFormat="of" <th>Meaning</th>
target="RFC8231"/>, <th>Error-value</th>
by making that section of <xref target="RFC8231"/> not applicable to SR Policy L <th>Reference</th>
SPs. </tr>
Thus, when a PCC wants to delegate an SR Policy LSP, it MAY proceed directly to </thead>
sending PCRpt, <tbody>
without first sending PCReq and waiting for PCRep. <tr>
This has the advantage of reducing the number of PCEP messages and simplifying t <td rowspan="2">6</td>
he implementation. <td>Mandatory Object Missing</td>
</t> <td></td>
<td><xref target="RFC5440"/></td>
</tr>
<tr>
<td></td>
<td>22: Missing SR Policy Association</td>
<td>RFC 9862</td>
</tr>
<tr>
<td rowspan="2">10</td>
<td>Reception of an invalid object</td>
<td></td>
<td><xref target="RFC5440"/></td>
</tr>
<tr>
<td></td>
<td>44: Missing SRPOLICY-CAPABILITY TLV</td>
<td>RFC 9862</td>
</tr>
</tbody>
</table>
<t> </section>
Furthermore, a PCEP speaker is not required to support PCReq/PCRep at all for SR <section numbered="true" toc="default">
Policies. <name>TE-PATH-BINDING TLV Flag Field</name>
The PCEP speaker can indicate support for PCReq/PCRep via the "L-Flag" in <t>A draft version of this document added a new bit in the
the SRPOLICY-CAPABILITY TLV (See <xref target="Capability-tlv"/>). "TE-PATH-BINDING TLV Flag Field" registry of the "Path Computation
When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent, Element Protocol (PCEP) Numbers" registry group, which was early
the given peer MUST NOT be sent PCReq/PCRep messages for SR Policy LSPs. allocated by IANA.</t>
Conversely, when this flag is set, the peer can receive and process <t>IANA has marked the bit position as deprecated.</t>
PCReq/PCRep messages for SR Policy LSPs.
</t>
<t> <table>
The above applies only to SR Policy LSPs and does not affect other LSP types, <thead>
such as RSVP-TE LSPs. For other LSP types, <xref format="default" section="5.8.2 <tr><th>Bit</th><th>Description</th><th>Reference</th></tr>
" sectionFormat="of" target="RFC8231"/> </thead>
continues to apply. <tbody>
</t> <tr><td>1</td><td>Deprecated (Specified-BSID-only)</td><td>RFC 9862</td></tr
>
</tbody>
</table>
</section>
<section anchor="inval_oper_iana" numbered="true" toc="default">
<name>SR Policy Invalidation Operational State</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 "IETF Review" <xref target="RFC8126"
format="default"/>. Each bit will be tracked with the following
qualities:
</t>
<ul spacing="normal">
<li>
<t>Bit (counting from bit 0 as the most significant bit)</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</td><td>Unassigned</td><td></td></tr>
<tr><td>7</td><td>D: Dropping - the LSP is currently attracting traffic and
actively dropping it.</td><td>RFC 9862</td></tr>
</tbody>
</table>
</section> <!-- Stateless-oper --> </section>
<section anchor="inval_config_iana" numbered="true" toc="default">
<name>SR Policy Invalidation Configuration State</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 "IETF Review" <xref target="RFC8126"
format="default"/>. Each bit will be tracked with the following
qualities:
</t>
<ul spacing="normal">
<li>
<t>Bit (counting from bit 0 as the most significant bit)</t>
</li>
<li>
<t>Description</t>
</li>
<li>
<t>Reference</t>
</li>
</ul>
</section> <!-- Other mechanisms --> <table>
<thead>
<tr><th>Bit</th><th>Description</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0 - 6</td><td>Unassigned.</td><td></td></tr>
<tr><td>7</td><td>D: Drop enabled - the Drop-Upon-Invalid is enabled on the
LSP.</td><td>RFC 9862</td></tr>
</tbody>
</table>
</section>
<section anchor="sr_policy_cap_flag_field" numbered="true" toc="default">
<name>SR Policy Capability TLV Flag Field</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 "IETF Review" <xref target="RFC8126"
format="default"/>. Each bit will be tracked with the following
qualities:
</t>
<ul spacing="normal">
<li>
<t>Bit (counting from bit 0 as the most significant bit)</t>
</li>
<li>
<t>Description</t>
</li>
<li>
<t>Reference</t>
</li>
</ul>
<section title="IANA Considerations"> <table>
<thead>
<tr><th>Bit</th><th>Description</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0 - 26</td><td>Unassigned</td><td>RFC 9862</td></tr>
<tr><td>27</td><td>Stateless Operation (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)</td><td>RFC 9862</td>
</tr>
<tr><td>31</td><td>Computation Priority (P-flag)</td><td>RFC 9862</td></tr>
</tbody>
</table>
</section>
</section>
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" <section numbered="true" toc="default">
registry at <eref brackets="angle" target="https://www.iana.org/assignments/ <name>Security Considerations</name>
pcep"/>.</t> <t>The information carried in the newly defined SRPA object and TLVs
could provide an eavesdropper with additional information about the SR
Policy.</t>
<t>The security considerations described in <xref target="RFC5440"
format="default"/>, <xref target="RFC8231" format="default"/>, <xref
target="RFC8281" format="default"/>, <xref target="RFC8664"
format="default"/>, <xref target="RFC8697" format="default"/>, <xref
target="RFC9256" format="default"/>, and <xref target="RFC9603"
format="default"/> are applicable to this specification.</t>
<t>As per <xref target="RFC8231" format="default"/>, it is
<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) <xref target="RFC8253" format="default"/> as per the
recommendations and best current practices in <xref target="RFC9325"
format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>All manageability requirements and considerations listed in <xref
target="RFC5440" format="default"/>, <xref target="RFC8231"
format="default"/>, <xref target="RFC8664" format="default"/>, <xref
target="RFC9256" format="default"/>, and <xref target="RFC9603"
format="default"/> apply to PCEP protocol extensions defined in this
document. In addition, requirements and considerations listed in this
section apply.</t>
<section numbered="true" toc="default">
<name>Control of Function and Policy</name>
<t>A PCE or PCC implementation <bcp14>MAY</bcp14> allow the
capabilities specified in <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>
<section numbered="true" toc="default">
<name>Information and Data Models</name>
<section anchor="Association-Type" title="Association Type"> <!-- [rfced] Does "described in Section 4" refer to Section 4
<t>This document defines a new association type: SR Policy Association. of this document or Section 4 of [I-D.ietf-pce-pcep-srv6-yang]?
IANA is requested to confirm the following allocation 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>
</section>
<section title="PCEP TLV Type Indicators"> Original:
<t>This document defines eight new TLVs for carrying additional information abou [I-D.ietf-pce-pcep-srv6-yang] defines YANG module with common
t SR Policy and SR Policy Candidate Paths. IANA is requested to confirm the foll building blocks for PCEP Extensions described in Section 4.
owing allocations 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>
</section>
<section title="PCEP Errors"> <t><xref target="I-D.ietf-pce-pcep-srv6-yang"/> defines a YANG
<t>This document defines one new Error-Value within the "Mandatory Object Missin module with common building blocks for PCEP extensions described in
g" Error-Type, two new Error-Values within the "Association Error" Error-Type an Section 4.</t>
d one new Error-Value within the "Reception of an invalid object". </t> </section>
<t>IANA is requested to confirm the following allocations within the "PCEP-ERROR <section numbered="true" toc="default">
Object Error Types and Values" registry of the "Path Computation Element Protoc <name>Liveness Detection and Monitoring</name>
ol (PCEP) Numbers" registry group.</t> <t>Mechanisms defined in this document do not imply any new liveness
<t> detection and monitoring requirements in addition to those already
<figure> listed in <xref target="RFC5440" format="default"/>, <xref
<artwork align="left"><![CDATA[ target="RFC8664" format="default"/>, and <xref target="RFC9256"
+------------+------------------+-----------------------+-----------+ format="default"/>.</t>
| Error-Type | Meaning | Error-value | Reference | </section>
+------------+------------------+-----------------------+-----------+ <section numbered="true" toc="default">
| 6 | Mandatory Object | | [RFC5440] | <name>Verify Correct Operations</name>
| | Missing | | | <t>Operation verification requirements already listed in <xref
+------------+------------------+-----------------------+-----------+ target="RFC5440" format="default"/>, <xref target="RFC8231"
| | | 21: Missing SR | This.I-D | format="default"/>, <xref target="RFC8664" format="default"/>, <xref
| | | Policy Mandatory TLV | | target="RFC9256" format="default"/>, and <xref target="RFC9603"
+------------+------------------+-----------------------+-----------+ format="default"/> are applicable to mechanisms defined in this
| 26 | Association | | [RFC8697] | document.</t>
| | Error | | | <t>An implementation <bcp14>MUST</bcp14> allow the operator to view SR
+------------+------------------+-----------------------+-----------+ Policy Identifier and SR Policy Candidate Path Identifier advertised
| | | 20: SR Policy | This.I-D | in an SRPA object.</t>
| | | Identifers Mismatch | | <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view
+------------+------------------+-----------------------+-----------+ the capabilities defined in this document advertised by each PCEP
| | | 21: SR Policy | This.I-D | peer.</t>
| | | Candidate Path | | <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view
| | | Identifier Mismatch | | LSPs associated with a specific SR Policy Identifier.</t>
+------------+------------------+-----------------------+-----------+ </section>
]]></artwork> <section numbered="true" toc="default">
</figure></t> <name>Requirements on Other Protocols</name>
<t>The PCEP extensions defined in this document do not imply any new req
uirements on other protocols.</t>
</section>
<t>IANA is requested to make new allocations within the "PCEP-ERROR Object Error <section numbered="true" toc="default">
Types and Values" registry of the "Path Computation Element Protocol (PCEP) Num <name>Impact on Network Operations</name>
bers" registry group.</t> <t>The mechanisms defined in <xref target="RFC5440" format="default"/>,
<xref target="RFC8231" format="default"/>, <xref target="RFC9256" format="defaul
t"/>, and <xref target="RFC9603" format="default"/> also apply to the PCEP exten
sions defined in this document.</t>
</section>
</section>
<t><figure> </middle>
<artwork align="left"><![CDATA[ <back>
+------------+------------------+-----------------------+-----------+
| Error-Type | Meaning | Error-value | Reference |
+------------+------------------+-----------------------+-----------+
| 6 | Mandatory Object | | [RFC5440] |
| | Missing | | |
+------------+------------------+-----------------------+-----------+
| | | TBD1: Missing SR | This.I-D |
| | | Policy Association | |
+------------+------------------+-----------------------+-----------+
| 10 | Reception of an | | [RFC5440] |
| | invalid object | | |
+------------+------------------+-----------------------+-----------+
| | | TBD2: Missing | This.I-D |
| | | SRPOLICY-CAPABILITY | |
| | | TLV | |
+------------+------------------+-----------------------+-----------+
]]></artwork> <displayreference target="I-D.ietf-pce-pcep-srv6-yang" to="PCEP-SRv6-YANG" /
</figure> >
</t> <displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="ADV-SR-POLICY"
</section> />
<displayreference target="I-D.ietf-pce-multipath" to="PCEP-MULTIPATH" />
<references>
<section title="TE-PATH-BINDING TLV Flag field"> <name>References</name>
<t> <references>
An earlier version of this document added new bit within the "TE-PATH-BINDING TL <name>Normative References</name>
V Flag field" registry of the "Path Computation Element Protocol (PCEP) Numbers" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
registry group, which was also early allocated by the IANA.</t> 020.xml"/>
<t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
IANA is requested to mark the bit position as deprecated.</t> 119.xml"/>
<t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<figure> 032.xml"/>
<artwork align="left"><![CDATA[ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
+------------+------------------------------------------+-----------+ 440.xml"/>
| Bit position | Description | Reference | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
+--------------+----------------------------------------+-----------+ 126.xml"/>
| 1 | Deprecated (Specified-BSID-only) | This.I-D | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
+--------------+----------------------------------------+-----------+ 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
408.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
697.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
603.xml"/>
</references>
<references>
<name>Informative References</name>
]]></artwork> <!-- draft-ietf-idr-sr-policy-safi-13 now RFC 9830
</figure> -->
</t>
</section>
<section anchor="inval_oper_iana" title="SR Policy Invalidation Operational Stat <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9830.xml"
e"> />
<t>
This document requests IANA to maintain a new registry under "Path Computation E
lement Protocol (PCEP) Numbers" registry group.
The new registry is called "SR Policy Invalidation Operational Flags".
New values are to be assigned by "IETF review" <xref target="RFC8126"/>.
Each bit should be tracked with the following qualities:
<list style="symbols">
<t>Bit (counting from bit 0 as the most significant bit).</t>
<t>Description.</t>
<t>Reference.</t>
</list>
</t>
<figure>
<artwork align="left"><![CDATA[
+-------+-----------------------------------------------+-----------+
| Bit | Description | Reference |
+-------+-----------------------------------------------+-----------+
| 0 - 6 | Unassigned | This.I-D |
+-------+-----------------------------------------------+-----------+
| 7 | D: dropping - the LSP is currently attracting | This.I-D |
| | traffic and actively dropping it. | |
+-------+-----------------------------------------------+-----------+
]]></artwork>
</figure>
</section>
<section anchor="inval_config_iana" title="SR Policy Invalidation Configuration <!-- [I-D.ietf-idr-bgp-ls-sr-policy]
State"> -->
<t>
This document requests IANA to maintain a new registry under "Path Computation E
lement Protocol (PCEP) Numbers" registry group.
The new registry is called "SR Policy Invalidation Configuration Flags".
New values are to be assigned by "IETF review" <xref target="RFC8126"/>.
Each bit should be tracked with the following qualities:
<list style="symbols">
<t>Bit (counting from bit 0 as the most significant bit).</t>
<t>Description.</t>
<t>Reference.</t>
</list>
</t>
<figure>
<artwork align="left"><![CDATA[
+-------+-----------------------------------------------+-----------+
| Bit | Description | Reference |
+-------+-----------------------------------------------+-----------+
| 0 - 6 | Unassigned. | This.I-D |
+-------+-----------------------------------------------+-----------+
| 7 | D: drop enabled - the Drop-upon-invalid is | This.I-D |
| | enabled on the LSP. | |
+-------+-----------------------------------------------+-----------+
]]></artwork>
</figure>
</section>
<section anchor="sr_policy_cap_flag_field" title="SR Policy Capability TLV Flag <reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ie
field"> tf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-17">
<t> <front>
This document requests IANA to maintain a new registry under "Path Computation E <title>Advertisement of Segment Routing Policies using BGP Link-State</tit
lement Protocol (PCEP) Numbers" registry group. le>
The new registry is called "SR Policy Capability TLV Flag Field". <author initials="S." surname="Previdi" fullname="Stefano Previdi">
New values are to be assigned by "IETF review" <xref target="RFC8126"/>. <organization>Individual</organization>
Each bit should be tracked with the following qualities: </author>
<list style="symbols"> <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
<t>Bit (counting from bit 0 as the most significant bit).</t> e="editor">
<t>Description.</t> <organization>Cisco Systems</organization>
<t>Reference.</t> </author>
</list> <author initials="J." surname="Dong" fullname="Jie Dong">
</t> <organization>Huawei Technologies</organization>
<figure> </author>
<artwork align="left"><![CDATA[ <author initials="H." surname="Gredler" fullname="Hannes Gredler">
+--------+-----------------------------------------------+-----------+ <organization>RtBrick Inc.</organization>
| Bit | Description | Reference | </author>
+--------+-----------------------------------------------+-----------+ <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
| 0 - 26 | Unassigned | This.I-D | <organization>Nvidia</organization>
+--------+-----------------------------------------------+-----------+ </author>
| 27 | Stateless Operation (L-Flag) | This.I-D | <date month="March" day="6" year="2025" />
+--------+-----------------------------------------------+-----------+ </front>
| 28 | Unassigned | This.I-D | <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-17"
+--------+-----------------------------------------------+-----------+ />
| 29 | Invalidation (I-Flag) | This.I-D |
+--------+-----------------------------------------------+-----------+
| 30 | Explicit NULL Label Policy (E-Flag) | This.I-D |
+--------+-----------------------------------------------+-----------+
| 31 | Computation Priority (P-flag) | This.I-D |
+--------+-----------------------------------------------+-----------+
]]></artwork> </reference>
</figure>
</section>
</section> <!-- [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"/>
<section title="Implementation Status"> <!-- [I-D.ietf-pce-pcep-srv6-yang]
<t>[Note to the RFC Editor - remove this section before publication, as draft-ietf-pce-pcep-srv6-yang-07
well as remove the reference to RFC 7942.]</t> 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.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
604.xml"/>
</references>
</references>
<t>This section records the status of known implementations of the <section anchor="Acknowledgement" numbered="false" toc="default">
protocol defined by this specification at the time of posting of this <name>Acknowledgements</name>
Internet-Draft, and is based on a proposal described in <xref <t>We would like to thank <contact fullname="Abdul Rehman"/>, <contact
target="RFC7942"/>. The description of implementations in this section fullname="Andrew Stone"/>, <contact fullname="Boris Khasanov"/>,
is intended to assist the IETF in its decision processes in progressing <contact fullname="Cheng Li"/>, <contact fullname="Dhruv Dhody"/>,
drafts to RFCs. Please note that the listing of any individual <contact fullname="Gorry Fairhurst"/>, <contact fullname="Gyan
implementation here does not imply endorsement by the IETF. Furthermore, Mishra"/>, <contact fullname="Huaimo Chen"/>, <contact fullname="Ines
no effort has been spent to verify the information presented here that Robles"/>, <contact fullname="Joseph Salowey"/>, <contact
was supplied by IETF contributors. This is not intended as, and must not fullname="Ketan Talaulikar"/>, <contact fullname="Marina Fizgeer"/>,
be construed to be, a catalog of available implementations or their <contact fullname="Mike Bishopm"/>, <contact fullname="Praveen Kumar"/>,
features. Readers are advised to note that other implementations may <contact fullname="Robert Sparks"/>, <contact fullname="Roman
exist.</t> Danyliw"/>, <contact fullname="Stephane Litkowski"/>, <contact
fullname="Tom Petch"/>, <contact fullname="Zoey Rose"/>, <contact
fullname="Xiao Min"/>, <contact fullname="Xiong Quan"/> for review and
suggestions.</t>
</section>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and <section numbered="false" toc="default">
working groups to assign due consideration to documents that have the <name>Contributors</name>
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"> <contact fullname="Dhruv Dhody">
<t><list style="symbols"> <organization>Huawei</organization>
<t>Organization: Cisco Systems</t> <address>
<postal>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
<t>Implementation: IOS-XR PCC and PCE.</t> <contact fullname="Cheng Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city><code>10095</code>
<country>China</country>
</postal>
<email>chengli13@huawei.com</email>
</address>
</contact>
<t>Description: All features supported except Computation Priority, <contact fullname="Zafar Ali">
Explicit NULL and Invalidation Drop.</t> <organization>Cisco Systems, Inc</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
<t>Maturity Level: Production.</t> <contact fullname="Rajesh Melarcode">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2000 Innovation Dr.</street>
<city>Kanata</city><region>Ontario</region>
<country>Canada</country>
</postal>
<email>rmelarco@cisco.com</email>
</address>
</contact>
<t>Coverage: Full.</t> </section>
<t>Contact: ssidor@cisco.com</t> </back>
</list></t>
</section>
<section anchor="Juniper" title="Juniper"> <!-- [rfced] Please review the following questions about terminology.
<t><list style="symbols">
<t>Organization: Juniper Networks</t>
<t>Implementation: PCC and PCE.</t> a) We note the following different uses of the term below. Please review and
let us know how to update for consistency.
<t>Description: Everything in -05 except SR Policy Name TLV and SR P EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2)
olicy Candidate Path Name TLV.</t> 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...
<t>Maturity Level: Production.</t> b) We note different capitalization for the terms below. Please review and
let us know how to update for consistency.
<t>Coverage: Partial.</t> Destination vs. destination
<t>Contact: cbarth@juniper.net</t> Preference vs. preference
</list></t>
</section>
</section> Candidate Path vs. candidate path
-->
<section title="Security Considerations"> <!-- [rfced] FYI - We have already updated the following terms for consistency
<t>The information carried in the newly defined SRPA object and TLVs within the document and to match usage in other RFCs. Please review:
could provide an eavesdropper with additional information about the
SR Policy.
</t>
<t>
The security considerations described in <xref target="RFC5440"/>,
<xref target="RFC8231"/>, <xref target="RFC8281"/>, <xref target="RFC8664"/>,
<xref target="RFC8697"/>, <xref target="RFC9256"/> and <xref target="RFC9603"/>
are applicable to this specification.
</t>
<t>As per <xref target="RFC8231"/>, it is RECOMMENDED that these PCEP extensio a) For the terms below, we have updated the form(s) on the left to
ns can only be activated on authenticated and encrypted sessions across PCEs and the form on the right.
PCCs belonging to the same administrative authority, using Transport Layer Secu
rity (TLS) <xref target="RFC8253"/> as per the recommendations and best current
practices in <xref target="RFC9325"/>.</t>
</section>
<section title="Manageability Considerations" numbered="true" toc="default">
<t>All manageability requirements and considerations listed in <xref target="R
FC5440"/>, <xref target="RFC8231"/>, <xref target="RFC8664"/>, <xref target="RFC
9256"/>, and <xref target="RFC9603"/> apply to PCEP protocol extensions defined
in this document. In addition, requirements and considerations listed in this se
ction apply.</t>
<section title="Control of Function and Policy" numbered="true" toc="default">
<t>A PCE or PCC implementation MAY allow the capabilities specified in Se
ction 5.1 and the capability for support of SRPA advertised in ASSOC-Type-List T
LV to be enabled and disabled.</t>
</section>
<section title="Information and Data Models" numbered="true" toc="default">
<t><xref target="I-D.ietf-pce-pcep-srv6-yang" format="default" sectionForma
t="of" derivedContent="PCEP-SRv6-YANG"/> defines YANG module with common buildin
g blocks for PCEP Extensions described in Section 4.</t>
</section>
<section title="Liveness Detection and Monitoring" numbered="true" toc="defaul
t">
<t>Mechanisms defined in this document do not imply any new liveness detect
ion and monitoring requirements in addition to those already listed in <xref tar
get="RFC5440"/>, <xref target="RFC8664"/>, and <xref target="RFC9256"/>.</t>
</section>
<section title="Verify Correct Operations" numbered="true" toc="default">
<t>Operation verification requirements already listed in <xref target="RF
C5440"/>, <xref target="RFC8231"/>, <xref target="RFC8664"/>, <xref target="RFC9
256"/>, and <xref target="RFC9603"/> are applicable to mechanisms defined in thi
s document.</t>
<t>An implementation MUST allow the operator to view SR Policy Identifier
and SR Policy Candidate Path Identifier advertised in SRPA object.</t>
<t>An implementation SHOULD allow the operator to view the capabilities d
efined in this document advertised by each PCEP peer.</t>
<t>An implementation SHOULD allow the operator to view LSPs associated wi
th specific SR Policy Identifier.</t>
</section>
<section title="Requirements On Other Protocols" numbered="true" toc="default"
>
<t>The PCEP extensions defined in this document do not imply any new require
ments on other protocols.</t>
</section>
<section title="Impact On Network Operations" numbered="true" toc="default">
<t>The mechanisms defined in <xref target="RFC5440"/>, <xref target="RFC8
231"/>, <xref target="RFC9256"/> and <xref target="RFC9603"/> also apply to the
PCEP extensions defined in this document.</t>
</section>
</section>
<section anchor="Acknowledgement" title="Acknowledgement">
<t>
We would like to thank Abdul Rehman, Andrew Stone, Boris Khasanov, Cheng Li, Dhr
uv 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 fo
r review and suggestions.
</t>
</section> <!-- Acknowledgement -->
</middle> association type / Association type -> Association Type (per RFC 8697)
<back> Association Parameters -> association parameters (per RFC 8697)
<references title="Normative References"> ASSOCIATION Object -> ASSOCIATION object (per RFC 8697)
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8253.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8408.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8664.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8697.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9325.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9603.xm
l"?>
</references> Protocol Origin -> Protocol-Origin (per Section 2.3 of RFC 9256)
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i
dr-sr-policy-safi.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i
dr-bgp-ls-sr-policy.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p
ce-multipath.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p
ce-pcep-srv6-yang"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9552.xm
l"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9604.xm
l"?>
</references> Drop-upon-invalid -> Drop-Upon-Invalid (per Section 8.2 of RFC 9256)
<section title="Contributors"> b) We note flags are stylized differently throughout (see some examples
<t><figure><artwork> below). For consistency, we have updated all of these instances to P-flag,
Dhruv Dhody E-flag, etc.
Huawei
India
Email: dhruv.ietf@gmail.com P-flag
P flag
E-Flag
E flag
I-Flag
I flag
L-Flag
L flag
"L-Flag"
O-flag
Cheng Li So, we will ask IANA to update to lowercase 'f' consistently
Huawei Technologies in the description in this registry
Huawei Campus, No. 156 Beiqing Rd. (https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy-capability-tlv-flag-
Beijing, 10095 field)
China 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
Email: chengli13@huawei.com c) FYI, "<headend, color, endpoint>" has been capitalized for consistency with
Section 2.1 of [RFC9256].
Zafar Ali Original:
Cisco Systems, Inc. Per Section 2.1 of [RFC9256], an SR Policy is identified through the
<headend, color, endpoint> tuple.
Email: zali@cisco.com The last hop of a computed SR Policy Candidate Path MAY differ from
the Endpoint contained in the <headend, color, endpoint> tuple.
Rajesh Melarcode Current:
Cisco Systems, Inc. Per Section 2.1 of [RFC9256], an SR Policy is identified through the
2000 Innovation Dr. <Headend, Color, Endpoint> tuple.
Kanata, Ontario
Canada
Email: rmelarco@cisco.com The last hop of a computed SR Policy Candidate Path MAY differ from the
Endpoint contained in the <Headend, Color, Endpoint> tuple.
-->
</artwork></figure></t> <!-- [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.
</section> <!-- Contributors --> For example, please consider whether "native" should be updated in the text belo w:
</back> 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).
-->
</rfc> </rfc>
 End of changes. 163 change blocks. 
1272 lines changed or deleted 1573 lines changed or added

This html diff was produced by rfcdiff 1.48.