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">
<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 54
<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="October"/>
<area>RTG</area>
<workgroup>PCE</workgroup>
<date/> <keyword>PCEP</keyword>
<keyword>SR Policy</keyword>
<workgroup>PCE Working Group</workgroup> <keyword>Candidate Path</keyword>
<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">
<t>
The SR Policy is represented by a new type of PCEP Association, called the SR Po
licy Association (SRPA) (see <xref target="Association"/>).
The SR Policy Candidate Paths of specific SR Policy are the LSPs within the same
SRPA.
The extensions in this document specify the encoding of a single segment list wi
thin an SR Policy Candidate Path. Encoding of multiple
segment lists is outside the scope of this document and specified in <xref targe
t="I-D.ietf-pce-multipath"/>.
</t>
<t>An SRPA carries three pieces of information:
SR Policy Identifier, SR Policy Candidate Path Identifier, and SR Policy Candida
te 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 wh
en the LSP is operationally down (see <xref target="Other-mechanisms"/>).
</t>
</section> <!-- Overview -->
<section anchor="Association" title="SR Policy Association (SRPA)">
<t>
Per <xref target="RFC8697"/>, 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"/>):
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>
<xref target="RFC8697"/> specifies the mechanism for the capability advertisemen
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>
SRPA MUST be assigned for all SR Policy LSPs by PCEP speaker originating the
LSP if capability was advertised by both PCEP speakers.
If the above condition is not satisfied, then the receiving PCEP speaker MUST
send a PCErr message with
Error-Type = 6 "Mandatory Object Missing", Error-Value = TBD1 "Missing SR Policy
Association".
</t>
<t>
A given LSP MUST belong to at most one SRPA, since an SR Policy Candidate Path c
annot 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 MUST send a PCErr message with
Error-Type = 26 "Association Error", Error-Value = 7 "Cannot join the associatio
n group".
</t>
<t>
The existing behavior for the use of Binding SID with SR Policy is already docum
ented in <xref target="RFC9604"/>. If BSID value allocation failed, because of c
onflict with BSID used by another policy, then PCEP peer MUST send a PCErr messa
ge with Error-Type = 32 "Binding label/SID failure" and Error-value = 2 "Unable
to allocate the specified binding value".
</t>
<section anchor="SRPolicyIdentifier" title="SR Policy Identifier">
<t>SR Policy Identifier uniquely identifies an SR Policy <xref target="RFC9256"/
> within the SR domain.
SR Policy Identifier is assigned by PCEP peer originating the LSP and MUST be un
iform across all the PCEP sessions.
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
h Identifier">
<t>SR Policy Candidate Path Identifier uniquely identifies the SR Policy Candida
te Path within the context of an SR Policy. SR Policy Candidate Path Identifier
is assigned by PCEP peer originating the LSP.
Candidate Paths within an SR Policy MUST NOT change their SR Policy Candidate Pa
th Identifiers for the lifetime of the PCEP session.
Two or more Candidate Paths within an SR Policy MUST NOT carry same SR Policy Ca
ndidate Path Identifiers in their SRPAs.
If the above conditions are not satisfied, the PCEP speaker MUST send a PCErr me
ssage with Error-Type = 26 "Association Error" and Error Value = 21 "SR Policy C
andidate Path Identifier Mismatch".
SR Policy Candidate Path Identifier consists of:</t>
<t>
<list style="symbols">
<t>Protocol Origin (<xref target="RFC9256"/>, Section 2.3).</t>
<t>Originator (<xref target="RFC9256"/>, Section 2.4).</t>
<t>Discriminator (<xref target="RFC9256"/>, Section 2.5).</t>
</list>
</t>
</section>
<section anchor="SRPolicyCandidatePathAttributes" title="SR Policy Candidate Pat
h Attributes">
<t>SR Policy Candidate Path Attributes carry optional, non-key information about
a Candidate Path and MAY change during the lifetime of an LSP.
SR Policy Candidate Path Attributes consists of:</t>
<t>
<list style="symbols">
<t>Candidate Path preference (<xref target="RFC9256"/>, Section 2.7).</t
>
<t>Candidate Path name (<xref target="RFC9256"/>, Section 2.6).</t>
<t>SR Policy name (<xref target="RFC9256"/>, Section 2.1).</t>
</list>
</t>
</section>
<section anchor="AssociationParameters" title="Association Parameters">
<t>
Per <xref target="RFC9256" sectionFormat="of" section="2.1"/>,
an SR Policy is identified through the &#60;headend, color, endpoint&#62; tuple.
</t>
<t>The Association Parameters consists of:</t>
<t>
<list style="symbols">
<t>Association Type: Set to 6 "SR Policy Association".</t>
<t>Association Source (IPv4/IPv6): Set to the headend value of the SR Po
licy, as defined in <xref target="RFC9256"/> Section 2.1.</t>
<t>Association ID (16-bit): Always set to the numeric value "1".</t>
<t>Extended Association ID TLV: Mandatory TLV for SR Policy Association.
Encodes the Color and Endpoint of the SR Policy (<xref target="Extended-Associat
ion-ID-TLV-FORMAT"/>).</t>
</list>
</t>
<figure anchor="Extended-Association-ID-TLV-FORMAT" title="Extended Association
ID TLV Format">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 31 | Length = 8 or 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Endpoint ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Type: Extended Association ID TLV, type = 31 <xref target="RFC8697"/>.</t>
<t>Length: 8 octets if IPv4 address or 20 octets if IPv6 address is encoded in t <abstract>
he Endpoint field.</t> <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" 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>Also, this document updates <xref target="RFC8231" section="5.8.2"/>,
making the use of Path Computation Request (PCReq) and Path Computation
Reply (PCRep) messages optional for LSPs that are set up using Path Setup
Type 1
(for Segment Routing) <xref target="RFC8664" format="default"/> and Path
Setup Type 3 (for SRv6) <xref target="RFC9603" format="default"/> with the
aim of reducing the PCEP message exchanges and simplifying
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>Color: unsigned non-zero 32-bit integer value, SR Policy color per <xref targ <section anchor="Terminology" numbered="true" toc="default">
et="RFC9256" sectionFormat="of" section="2.1"/>.</t> <name>Terminology</name>
<t>This document uses the following terms defined in <xref target="RFC5440
"/>:</t>
<ul>
<li>Explicit Route Object (ERO)</li>
<li>Path Computation Client (PCC)</li>
<li>Path Computation Element (PCE)</li>
<li>PCEP Peer</li>
<li>PCEP speaker</li>
</ul>
<t>Endpoint: can be either IPv4 (4 octets) or IPv6 address (16 octets). <t>This document uses the following term defined in <xref target="RFC3031"
This value MAY be different from the one contained in the Destination address fi />:</t>
eld in the END-POINTS object, or in the Tunnel Endpoint Address field in the LSP <ul>
-IDENTIFIERS TLV (<xref target="RFC9256" sectionFormat="of" section="2.1"/>).</t <li>Label Switched Path (LSP)</li>
> </ul>
<t>If a PCEP speaker receives an SRPA object <t>This document uses the following term defined in <xref target="RFC9552"
whose Association Parameters do not follow the above specification, />:</t>
then the PCEP speaker MUST send a PCErr message with <ul>
Error-Type = 26 "Association Error", Error-Value = 20 "SR Policy Identifier Mism <li>Border Gateway Protocol - Link State (BGP-LS)</li>
atch".</t> </ul>
<t>The encoding choice of the Association Parameters in this way is meant to gua <t>The following other terms are used in this document:</t>
rantee that there is no possibility of a race condition when multiple PCEP speak <dl>
ers want to associate the same SR Policy at the same time. By adhering to this f <dt>Endpoint:</dt>
ormat, all PCEP speakers come up with the same Association Parameters independen <dd>The IPv4 or IPv6 endpoint address of an SR Policy, as described in <
tly of each other based on the SR Policy parameters <xref target="RFC9256"/>.</t xref target="RFC9256" section="2.1"/>.</dd>
> <dt>Color:</dt>
<dd>The 32-bit color of an SR Policy, as described in <xref target="RFC9
256" section="2.1"/>.</dd>
<dt>Protocol-Origin:</dt>
<dd>The protocol that was used to create a Candidate Path, as
described in <xref target="RFC9256" section="2.3"/>.</dd>
<dt>Originator:</dt>
<dd>A device that created a Candidate Path, as described in <xref
target="RFC9256" section="2.4"/>.</dd>
<dt>Discriminator:</dt>
<dd>Distinguishes Candidate Paths created by the same device, as
described in <xref target="RFC9256" section="2.5"/>.</dd>
<dt>Association parameters:</dt>
<dd>Refers to the key data that uniquely identifies an Association,
as described in <xref target="RFC8697" format="default"/>.</dd>
<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>
<t> <t>The base PCEP specification <xref target="RFC4655"
The last hop of a computed SR Policy Candidate Path MAY differ from the Endpoint format="default"/> originally defined the use of the PCE architecture
contained in the &#60;headend, color, endpoint&#62; tuple. for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE
An example use case is to terminate the SR Policy before reaching the Endpoint a signaling protocol. Over time, support for additional path setup types
nd have decapsulated traffic be forwarded the rest of the path to the Endpoint n such as SRv6 has been introduced <xref target="RFC9603"
ode using the native Interior Gateway Protocol (IGP) path(s). format="default"/>. The term "LSP" is used extensively in PCEP
In this example, the destination of the SR Policy Candidate Paths will be some n specifications, and in the context of this document, refers to a
ode before the Endpoint, but the Endpoint value is still used at the headend to Candidate Path within an SR Policy, which may be an SRv6 path (still
steer traffic with that Endpoint IP address into the SR Policy. represented using the LSP object as specified in <xref target="RFC8231"
The Destination of the SR Policy Candidate Path is signaled using the END-POINTS format="default"/>).</t>
object and/or LSP-IDENTIFIERS TLV, per the usual PCEP procedure. </section>
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> <section anchor="Overview" numbered="true" toc="default">
SR Policy with Color-Only steering is signaled with the Endpoint value set to un <name>Overview</name>
specified, i.e., 0.0.0.0 for IPv4 or :: for IPv6, per <xref target="RFC9256" sec <t>
tionFormat="of" section="8.8."/>. The SR Policy is represented by a new type of PCEP Association, called
</t> 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>
</section> <!-- AssociationParameters --> <section anchor="Association" numbered="true" toc="default">
<name>SR Policy Association (SRPA)</name>
<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>
<section anchor="AssociationInformation" title="Association Information"> <section anchor="SRPolicyIdentifier" numbered="true" toc="default">
<name>SR Policy Identifier</name>
<t>The SR Policy Identifier uniquely identifies an SR Policy <xref
target="RFC9256" format="default"/> within the SR domain. The SR Policy
Identifier is assigned by the PCEP peer originating the LSP and
<bcp14>MUST</bcp14> be uniform across all the PCEP sessions.
Candidate Paths within an SR Policy <bcp14>MUST</bcp14> carry the same
SR Policy Identifiers in their SRPAs. Candidate Paths within an SR
Policy <bcp14>MUST NOT</bcp14> change their SR Policy Identifiers for
the lifetime of the PCEP session. If the above conditions are not
satisfied, the receiving PCEP speaker <bcp14>MUST</bcp14> send a PCEP
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>
<t>The SRPA object may carry the following TLVs:</t> <t>Protocol-Origin (<xref target="RFC9256" sectionFormat="comma" sec
tion="2.3"/>)</t>
</li>
<li>
<t>Originator (<xref target="RFC9256" sectionFormat="comma" section=
"2.4"/>)</t>
</li>
<li>
<t>Discriminator (<xref target="RFC9256" sectionFormat="comma" secti
on="2.5"/>)</t>
</li>
</ul>
</section>
<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> <t>Per <xref target="RFC9256" sectionFormat="of" section="2.1"
<list style="symbols"> format="default"/>, an SR Policy is identified through the &lt;Headend,
<t>SRPOLICY-POL-NAME TLV (<xref target="Policy-name-tlv"/>): (optional) Color, Endpoint&gt; tuple.</t>
encodes the SR Policy Name string.</t>
<t>SRPOLICY-CPATH-ID TLV (<xref target="Cpath-identifier-tlv"/>): (manda
tory) encodes the SR Policy Candidate Path Identifier.</t>
<t>SRPOLICY-CPATH-NAME TLV (<xref target="SRPOLICY-CPATH-NAME"/>): (opti
onal) encodes the SR Policy Candidate Path string name.</t>
<t>SRPOLICY-CPATH-PREFERENCE TLV (<xref target="Cpath-preference-tlv"/>)
: (optional) encodes the SR Policy Candidate Path preference value.</t>
</list>
</t>
<t>When a mandatory TLV is missing from an SRPA object, the PCEP speaker MUST se <t>The association parameters consist of:</t>
nd a PCErr message with
Error-Type = 6 "Mandatory Object Missing", Error-Value = 21 "Missing SR Policy M
andatory TLV".</t>
<t>Only one TLV instance of each TLV type can be carried in an SRPA object, and <dl spacing="normal" newline="false">
only the first occurrence is processed. Any others MUST be silently ignored.</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>
<section anchor="Policy-name-tlv" title="SR Policy Name TLV"> <figure anchor="Extended-Association-ID-TLV-FORMAT">
<name>Extended Association ID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Endpoint ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>31 for the Extended Association ID TLV <xref
target="RFC8697" format="default"/>.</dd>
<dt>Length:</dt><dd>8 octets if IPv4 address or 20 octets if IPv6
address is encoded in the Endpoint field.</dd>
<dt>Color:</dt><dd>Unsigned non-zero 32-bit integer value, SR Policy
color per <xref target="RFC9256" sectionFormat="of" section="2.1"
format="default"/>.</dd>
<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 Interior Gateway Protocol (IGP) shortest path(s). In
this example, the destination of the SR Policy Candidate Paths will be
some node before the Endpoint, but the Endpoint value is still used at
the headend to steer traffic with that Endpoint IP address into the SR
Policy. The destination of the SR Policy Candidate Path is signaled
using the END-POINTS object and/or the LSP-IDENTIFIERS TLV, per the
usual PCEP procedure. When neither the END-POINTS object nor the
LSP-IDENTIFIERS TLV is present, the PCEP 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> <section anchor="AssociationInformation" numbered="true" toc="default">
The SRPOLICY-POL-NAME TLV (<xref target="SRPOLICY-POL-NAME-TLV-FORMAT"/>) is an <name>Association Information</name>
optional TLV for the SRPA object. It is RECOMMENDED that the size of the name fo <t>The SRPA object may carry the following TLVs:</t>
r the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate <dl spacing="normal" newline="false">
long names to 255 bytes to simplify interoperability with other protocols. <dt>SRPOLICY-POL-NAME TLV (<xref target="Policy-name-tlv"
</t> 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>
<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>
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 MUST be ignored.
</t>
<section anchor="Capability-tlv" title="SR Policy Capability TLV">
<t>
The SRPOLICY-CAPABILITY TLV (<xref target="SRPOLICY-CAPABILITY-TLV-FORMAT"/>) 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 MUST include SRPOLICY-CAPABILITY TLV in t
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; therefore, they cannot rely
on the Association capability negotiation in the ASSOC-Type-List
TLV. Instead, 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
icates that the PCEP speaker supports the stateless (PCReq/PCRep) operations for
the SR Policy
(<xref target="Stateless-oper"/>).
If the PCE set this flag to 0, then the PCC MUST NOT send PCReq messages to th
is PCE for the SR Policy.
</t>
</list>
<t>Unassigned bits MUST be set to '0' on transmission and MUST be ignored on rec
eipt. More flags can be assigned in the future per (<xref target="sr_policy_cap_
flag_field"/>).</t>
</section> <!-- Capability-tlv --> <t>32 bits. The following flags are currently defined:</t>
<dl spacing="normal" newline="false">
<dt>P-flag (Computation Priority):</dt>
<dd>If set to 1 by a PCEP speaker, the P-flag indicates that the
PCEP speaker supports the handling of the COMPUTATION-PRIORITY TLV
for the SR Policy (<xref target="Computation-priority-tlv"
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>
<section anchor="lsp-object-tlvs" title="LSP Object TLVs"> <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-POLICY 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 EXPLICIT-NULL-LABEL-POLICY TLV and <bcp14>MUST</bcp14> ignore i
t on receipt.</dd>
<t>This section is introducing three new TLVs to be carried in LSP object introd <dt>I-flag (Invalidation):</dt>
uced in <xref target="RFC8231" sectionFormat="of" section="7.3"/>.</t> <dd>If set to 1 by a PCEP speaker, the I-flag indicates that the
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 anchor="Computation-priority-tlv" title="Computation Priority 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>
<t>The COMPUTATION-PRIORITY TLV (<xref target="COMPUTATION-PRIORITY-TLV-FORMAT"/ <section anchor="lsp-object-tlvs" numbered="true" toc="default">
>) is an optional TLV. <name>LSP Object TLVs</name>
It is used to signal the numerical computation priority, as specified in <xref t <t>This section is introducing three new TLVs to be carried in the LSP
arget="RFC9256" sectionFormat="of" section="2.12"/>. object introduced in <xref target="RFC8231" sectionFormat="of"
If the TLV is absent from the LSP object and the P-flag in the SRPOLICY-CAPABILI section="7.3" format="default"/>.</t>
TY TLV is set to 1, a default Priority value of 128 is used.</t>
<figure anchor="COMPUTATION-PRIORITY-TLV-FORMAT" title="COMPUTATION-PRIORITY TLV <section anchor="Computation-priority-tlv" numbered="true" toc="default"
Format"> >
<artwork align="center"><![CDATA[ <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
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 | | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>68 for the COMPUTATION-PRIORITY TLV.</dd>
<t>Type: 68 for "COMPUTATION-PRIORITY" TLV.</t> <dt>Length:</dt><dd>4.</dd>
<dt>Priority:</dt><dd>8-bit unsigned integer value that encodes
<t>Length: 4.</t> numerical priority with which this LSP is to be recomputed by the
PCE upon topology change. The lowest value is the highest
<t>Priority: 8-bit unsigned integer value that encodes numerical priority with w priority.</dd>
hich this LSP is to be recomputed by the PCE upon topology change. Lowest value <dt>Reserved:</dt><dd>This field <bcp14>MUST</bcp14> be set to
is the highest priority.</t> zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt.</dd>
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored </dl>
on receipt.</t> </section>
</section> <!-- Computation-priority-tlv -->
<section anchor="enlp-tlv" title="Explicit Null Label Policy (ENLP) TLV"> <section anchor="enlp-tlv" numbered="true" toc="default">
<name>EXPLICIT-NULL-LABEL-POLICY TLV</name>
<t> <t>To steer an unlabeled IP packet into an SR Policy for the MPLS
To steer an unlabeled IP packet into an SR policy for the MPLS data plane, i data plane, it is necessary to push a label stack of one or more
t is necessary to push a label stack of one or more labels on that packet. labels on that packet. The EXPLICIT-NULL-LABEL-POLICY TLV is
The Explicit NULL Label Policy (ENLP) TLV is an optional TLV for the LSP obj an optional TLV for the LSP object used to indicate whether an
ect used to indicate whether an Explicit NULL Label <xref target="RFC3032"/> mus Explicit NULL label <xref target="RFC3032" format="default"/> must
t be pushed on an unlabeled IP packet before any other labels. be pushed on an unlabeled IP packet before any other labels. The
The contents of this TLV are used by the SR Policy Manager as described in < contents of this TLV are used by the SR Policy manager as described
xref format="default" section="4.1" sectionFormat="of" target="RFC9256"/>. in <xref format="default" section="4.1" sectionFormat="of"
If an ENLP TLV is not present, the decision of whether to push an Explicit N target="RFC9256"/>. If an EXPLICIT-NULL-LABEL-POLICY TLV is not prese
ULL label on a given packet is a matter of local configuration. nt, the decision of
Note that Explicit Null is currently only defined for SR-MPLS and not for SRv6. whether to push an Explicit NULL label on a given packet is a matter
Therefore, the receiving PCEP speaker MUST ignore the presence of this TLV for S of local configuration. Note that Explicit NULL is currently only
Rv6 Policies. defined for SR-MPLS and not for SRv6. Therefore, the receiving PCEP
</t> speaker <bcp14>MUST</bcp14> ignore the presence of this TLV for SRv6
Policies.</t>
<figure anchor="ENLP-TLV-FORMAT" title="Explicit Null Label Policy (ENLP) TLV Fo <figure anchor="ENLP-TLV-FORMAT">
rmat"> <name>EXPLICIT-NULL-LABEL-POLICY 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 | | ENLP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <dl spacing="normal" newline="false">
<dt>Type:</dt><dd>69 for the EXPLICIT-NULL-LABEL-POLICY TLV.</dd>
<t>Type: 69 for "ENLP" TLV.</t> <dt>Length:</dt><dd>4.</dd>
<dt>ENLP:</dt><dd>Explicit NULL Label Policy. 8-bit unsigned
<t>Length: 4.</t> 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> <t>The ENLP unassigned values may be used for future extensions, and
ENLP (Explicit NULL Label Policy): 8-bit unsigned integer value that indicates implementations <bcp14>MUST</bcp14> ignore the EXPLICIT-NULL-LABEL-POL
whether Explicit NULL labels are to be pushed on unlabeled IP packets ICY TLV with
that are being steered into a given SR policy. unrecognized values. The behavior signaled in this TLV
The values of this field are specified in IANA registry "SR Policy ENLP Values <bcp14>MAY</bcp14> be overridden by local configuration by the
" under "Segment Routing" registry group, which was introduced in Section 6.10 o network operator based on their deployment requirements. <xref
f <xref target="I-D.ietf-idr-sr-policy-safi"/>. format="default" section="4.1" sectionFormat="of" target="RFC9256"/>
</t> describes the behavior on the headend for the handling of the
Explicit NULL label.</t>
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored on receipt.</t> </section>
<t> <section anchor="Invalidation-tlv" numbered="true" toc="default">
The ENLP unassigned values may be used for future extensions and implementat <name>INVALIDATION TLV</name>
ions MUST ignore the ENLP TLV with unrecognized values.
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 --> <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="Invalidation-tlv" title="Invalidation TLV"> <t>The INVALIDATION TLV is used in both directions between PCEP peers: </t>
<t>The INVALIDATION TLV (<xref target="INVALIDATION-TLV-FORMAT"/>) is an optiona <ul spacing="normal">
l TLV. <li>PCE -&gt; PCC: The PCE specifies to the PCC whether to enable
This TLV is used to control traffic steering into an LSP or disable Drop-Upon-Invalid (Config).</li>
when the LSP is operationally down/invalid. <li>PCC -&gt; PCE: The PCC reports the current setting of the
In the context of SR Policy, this TLV facilitates Drop-Upon-Invalid (Config) and also whether the LSP is currently
the Drop-upon-invalid behavior, in the drop state (Oper).</li>
specified in <xref format="default" section="8.2" sectionFormat="of" target="RFC </ul>
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"> <figure anchor="INVALIDATION-TLV-FORMAT">
<artwork align="center"><![CDATA[ <name>INVALIDATION 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper | Config | Reserved | | Oper | Config | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure>
<t>Type: 70 for "INVALIDATION" TLV.</t>
<t>Length: 4.</t>
<t>Oper: An 8-bit flag field that encodes the operational state of the LSP. It M
UST be set to 0 by the PCE when sending and MUST be ignored by the PCC upon rece
ipt.
See <xref target="inval_oper_iana"/> for IANA information.
</t>
<figure anchor="OPER_INVAL_FLAGS" title="Oper state of Drop-upon-invalid feature
">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>D: dropping - the LSP is actively dropping traffic as a result of Drop-up
on-invalid behavior being activated.</t>
<t>The unassigned bits in the Flag octet MUST be set to zero upon transmissi
on and MUST be ignored upon receipt.</t>
</list>
</t>
<t>Config: An 8-bit flag field that encodes the configuration of the LSP.
See <xref target="inval_config_iana"/> for IANA information.
</t>
<figure anchor="CONFIG_INVAL_FLAGS" title="Config state of Drop-upon-invalid fea
ture">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>D: drop enabled - the Candidate Path has Drop-upon-invalid feature enable
d.</t>
<t>The unassigned bits in the Flag octet MUST be set to zero upon transmissi
on and MUST be ignored upon receipt.</t>
</list>
</t>
<t>Reserved: This field MUST be set to zero on transmission and MUST be ignored
on receipt.</t>
<section anchor="Invalidation-per-policy" title="Drop-upon-invalid applies to SR
Policy">
<t>
The Drop-upon-invalid feature is somewhat special among the other SR Policy feat
ures in the way that it is enabled/disabled.
This feature is enabled only on the whole SR Policy, not on a particular Candida
te Path of that SR Policy,
i.e., when any Candidate Path has Drop-upon-invalid enabled, it means that the w
hole SR Policy has the feature enabled.
As stated in <xref format="default" section="8.1" sectionFormat="of" target="RFC
9256"/>, an SR Policy is invalid when all its Candidate Paths are invalid.
</t>
<t>
Once all the Candidate Paths of an SR Policy have become invalid, then the SR Po
licy 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 preferenc
e Candidate Path which has
the Drop-upon-invalid enabled.
Note that only one Candidate Path needs to be reported to the PCE with the D (dr
opping) flag set.
</t>
</section> <!-- Invalidation-per-policy -->
</section> <!-- Invalidation-tlv -->
</section> <!-- lsp-object-tlvs -->
<section anchor="Stateless-oper" title="Update to RFC 8231">
<t>
<xref format="default" section="5.8.2" sectionFormat="of" target="RFC8231"/>, al
lows delegation of an LSP in operationally down state,
but at the same time mandates the use of PCReq before sending PCRpt.
This document updates <xref format="default" section="5.8.2" sectionFormat="of"
target="RFC8231"/>,
by making that section of <xref target="RFC8231"/> not applicable to SR Policy L
SPs.
Thus, when a PCC wants to delegate an SR Policy LSP, it MAY 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 t
he 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"/>).
When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent,
the given peer MUST NOT 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> <!-- Stateless-oper -->
</section> <!-- Other mechanisms -->
<section title="IANA Considerations">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry at <eref brackets="angle" target="https://www.iana.org/assignments/
pcep"/>.</t>
<section anchor="Association-Type" title="Association Type">
<t>This document defines a new association type: SR Policy Association.
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">
<t>This document defines eight new TLVs for carrying additional information abou
t SR Policy and SR Policy Candidate Paths. IANA is requested to confirm the foll
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>This document defines one new Error-Value within the "Mandatory Object Missin
g" Error-Type, two new Error-Values within the "Association Error" Error-Type an
d one new Error-Value within the "Reception of an invalid object". </t>
<t>IANA is requested to confirm the following allocations within the "PCEP-ERROR
Object Error Types and Values" registry of the "Path Computation Element Protoc
ol (PCEP) Numbers" registry group.</t>
<t>
<figure>
<artwork align="left"><![CDATA[
+------------+------------------+-----------------------+-----------+
| Error-Type | Meaning | Error-value | Reference |
+------------+------------------+-----------------------+-----------+
| 6 | Mandatory Object | | [RFC5440] |
| | Missing | | |
+------------+------------------+-----------------------+-----------+
| | | 21: Missing SR | This.I-D |
| | | Policy Mandatory TLV | |
+------------+------------------+-----------------------+-----------+
| 26 | Association | | [RFC8697] |
| | Error | | |
+------------+------------------+-----------------------+-----------+
| | | 20: SR Policy | This.I-D |
| | | Identifers Mismatch | |
+------------+------------------+-----------------------+-----------+
| | | 21: SR Policy | This.I-D |
| | | Candidate Path | |
| | | Identifier Mismatch | |
+------------+------------------+-----------------------+-----------+
]]></artwork>
</figure></t>
<t>IANA is requested to make new allocations within the "PCEP-ERROR Object Error
Types and Values" registry of the "Path Computation Element Protocol (PCEP) Num
bers" registry group.</t>
<t><figure> <dl spacing="normal" newline="false">
<artwork align="left"><![CDATA[ <dt>Type:</dt>
+------------+------------------+-----------------------+-----------+ <dd>70 for the INVALIDATION TLV.</dd>
| Error-Type | Meaning | Error-value | Reference | <dt>Length:</dt>
+------------+------------------+-----------------------+-----------+ <dd>4.</dd>
| 6 | Mandatory Object | | [RFC5440] | <dt>Oper:</dt>
| | Missing | | | <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
| | | TBD1: Missing SR | This.I-D | and <bcp14>MUST</bcp14> be ignored by the PCC upon receipt. See
| | | Policy Association | | <xref target="inval_oper_iana" format="default"/> for IANA
+------------+------------------+-----------------------+-----------+ information.</t>
| 10 | Reception of an | | [RFC5440] |
| | invalid object | | |
+------------+------------------+-----------------------+-----------+
| | | TBD2: Missing | This.I-D |
| | | SRPOLICY-CAPABILITY | |
| | | TLV | |
+------------+------------------+-----------------------+-----------+
]]></artwork> <figure anchor="OPER_INVAL_FLAGS">
</figure> <name>Oper State of Drop-Upon-Invalid Feature</name>
</t> <artwork align="center" name="" type="" alt=""><![CDATA[
</section> 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |D|
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<section title="TE-PATH-BINDING TLV Flag field"> <ul indent="5">
<t> <li>D: Dropping - the LSP is actively dropping traffic as a result
An earlier version of this document added new bit within the "TE-PATH-BINDING TL of Drop-Upon-Invalid behavior being activated.</li>
V Flag field" registry of the "Path Computation Element Protocol (PCEP) Numbers"
registry group, which was also early allocated by the IANA.</t>
<t>
IANA is requested to mark the bit position as deprecated.</t>
<t>
<figure>
<artwork align="left"><![CDATA[
+------------+------------------------------------------+-----------+
| Bit position | Description | Reference |
+--------------+----------------------------------------+-----------+
| 1 | Deprecated (Specified-BSID-only) | This.I-D |
+--------------+----------------------------------------+-----------+
]]></artwork> <li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14> be
</figure> set to zero upon transmission and <bcp14>MUST</bcp14> be ignored
</t> upon receipt.</li>
</section> </ul>
</dd>
<section anchor="inval_oper_iana" title="SR Policy Invalidation Operational Stat <dt>Config:</dt>
e"> <dd><t>An 8-bit flag field that encodes the configuration of the LSP.
<t> See <xref target="inval_config_iana" format="default"/> for IANA
This document requests IANA to maintain a new registry under "Path Computation E information.</t>
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 <figure anchor="CONFIG_INVAL_FLAGS">
State"> <name>Config State of Drop-Upon-Invalid Feature</name>
<t> <artwork align="center" name="" type="" alt=""><![CDATA[
This document requests IANA to maintain a new registry under "Path Computation E 0 1 2 3 4 5 6 7
lement Protocol (PCEP) Numbers" registry group. +-+-+-+-+-+-+-+-+
The new registry is called "SR Policy Invalidation Configuration Flags". | |D|
New values are to be assigned by "IETF review" <xref target="RFC8126"/>. +-+-+-+-+-+-+-+-+]]></artwork>
Each bit should be tracked with the following qualities: </figure>
<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 <ul indent="5">
field"> <li>D: Drop enabled - the Candidate Path has Drop-Upon-Invalid
<t> feature enabled.</li>
This document requests IANA to maintain a new registry under "Path Computation E <li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14> be
lement Protocol (PCEP) Numbers" registry group. set to zero upon transmission and <bcp14>MUST</bcp14> be ignored
The new registry is called "SR Policy Capability TLV Flag Field". upon receipt.</li>
New values are to be assigned by "IETF review" <xref target="RFC8126"/>. </ul>
Each bit should be tracked with the following qualities: </dd>
<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 - 26 | Unassigned | This.I-D |
+--------+-----------------------------------------------+-----------+
| 27 | Stateless Operation (L-Flag) | This.I-D |
+--------+-----------------------------------------------+-----------+
| 28 | Unassigned | This.I-D |
+--------+-----------------------------------------------+-----------+
| 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> <dt>Reserved:</dt>
</figure> <dd>This field <bcp14>MUST</bcp14> be set to zero on transmission
</section> and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
</dl>
<section anchor="Invalidation-per-policy" numbered="true" toc="default
">
<name>Drop-Upon-Invalid Applies to SR Policy</name>
<t>The Drop-Upon-Invalid feature is somewhat special among the
other SR Policy features in the way that it is enabled/disabled.
This feature is enabled only on the whole SR Policy, not on a
particular Candidate Path of that SR Policy, i.e., when any
Candidate Path 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>
<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 Can
didate Path needs to be reported to the PCE with the Dropping (D) flag set.</t>
</section>
</section>
</section> </section>
<section title="Implementation Status"> <section anchor="Stateless-oper" numbered="true" toc="default">
<t>[Note to the RFC Editor - remove this section before publication, as <name>Updates to RFC 8231</name>
well as remove the reference to RFC 7942.]</t> <t><xref format="default" section="5.8.2" sectionFormat="of"
target="RFC8231"/> allows delegation of an LSP in operationally down
<t>This section records the status of known implementations of the state, but at the same time mandates the use of PCReq before sending
protocol defined by this specification at the time of posting of this PCRpt. This document updates <xref format="default" section="5.8.2"
Internet-Draft, and is based on a proposal described in <xref sectionFormat="of" target="RFC8231"/>, by making that section of <xref
target="RFC7942"/>. The description of implementations in this section target="RFC8231" format="default"/> not applicable to SR Policy LSPs.
is intended to assist the IETF in its decision processes in progressing Thus, when a PCC wants to delegate an SR Policy LSP, it
drafts to RFCs. Please note that the listing of any individual <bcp14>MAY</bcp14> proceed directly to sending PCRpt, without first
implementation here does not imply endorsement by the IETF. Furthermore, sending PCReq and waiting for PCRep. This has the advantage of
no effort has been spent to verify the information presented here that reducing the number of PCEP messages and simplifying the
was supplied by IETF contributors. This is not intended as, and must not implementation.</t>
be construed to be, a catalog of available implementations or their <t>Furthermore, a PCEP speaker is not required to support PCReq/PCRep
features. Readers are advised to note that other implementations may at all for SR Policies. The PCEP speaker can indicate support for
exist.</t> PCReq/PCRep via the L-flag in the SRPOLICY-CAPABILITY TLV (see <xref
target="Capability-tlv" format="default"/>). When this flag is
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peer
working groups to assign due consideration to documents that have the <bcp14>MUST NOT</bcp14> be sent PCReq/PCRep messages for SR Policy
benefit of running code, which may serve as evidence of valuable LSPs. Conversely, when this flag is set, the peer can receive and
experimentation and feedback that have made the implemented protocols process PCReq/PCRep messages for SR Policy LSPs.</t>
more mature. It is up to the individual working groups to use this <t>The above applies only to SR Policy LSPs and does not affect other
information as they see fit".</t> LSP types, such as RSVP-TE LSPs. For other LSP types, <xref
format="default" section="5.8.2" sectionFormat="of" target="RFC8231"/>
<section anchor="Cisco" title="Cisco"> continues to apply.</t>
<t><list style="symbols"> </section>
<t>Organization: Cisco Systems</t> </section>
<t>Implementation: IOS-XR PCC and PCE.</t>
<t>Description: All features supported except Computation Priority,
Explicit NULL and Invalidation Drop.</t>
<t>Maturity Level: Production.</t> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry at <eref brackets="angle" target="https://www.iana.org/assignments/
pcep"/>.</t>
<section anchor="Association-Type" numbered="true" toc="default">
<name>Association Type</name>
<t>This document defines a new Association Type: SR Policy
Association. IANA has made the following assignment in
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>
<t>Coverage: Full.</t> <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>
<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>
<t>Contact: ssidor@cisco.com</t>
</list></t>
</section> </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>one new Error-value within the "Reception of an invalid object", an
d</li>
<li>two new Error-values within the "Association Error" Error-Type.</li
>
</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="Juniper" title="Juniper"> <table>
<t><list style="symbols"> <thead>
<t>Organization: Juniper Networks</t> <tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="3">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></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>
<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 Identifiers 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>Implementation: PCC and PCE.</t> </section>
<section numbered="true" toc="default">
<name>TE-PATH-BINDING TLV Flag Field</name>
<t>A draft version of this document added a new bit in the
"TE-PATH-BINDING TLV Flag Field" registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry group, which was early
allocated by IANA.</t>
<t>IANA has marked the bit position as deprecated.</t>
<t>Description: Everything in -05 except SR Policy Name TLV and SR P <table>
olicy Candidate Path Name TLV.</t> <thead>
<tr><th>Bit</th><th>Description</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>1</td><td>Deprecated (Specified-BSID-only)</td><td>RFC 9862</td></tr
>
</tbody>
</table>
</section>
<section anchor="inval_oper_iana" 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 actively dropping traffic as a
result of Drop-Upon-Invalid behavior being activated.</td><td>RFC
9862</td></tr>
</tbody>
</table>
<t>Maturity Level: Production.</t> </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>
<t>Coverage: Partial.</t> <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 Candidate Path has
Drop-Upon-Invalid feature enabled.</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>
<t>Contact: cbarth@juniper.net</t> <table>
</list></t> <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>
</section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>The information carried in the newly defined SRPA object and TLVs
could provide an eavesdropper with additional information about the 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>
<t><xref target="I-D.ietf-pce-pcep-srv6-yang"/> defines a YANG
module with common building blocks for PCEP extensions described in
<xref target="Association"/> of this document.</t>
</section>
<section numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in <xref target="RFC5440" format="default"/>, <xref
target="RFC8664" format="default"/>, and <xref target="RFC9256"
format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Verify Correct Operations</name>
<t>Operation verification requirements already 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"/> are applicable to mechanisms defined in this
document.</t>
<t>An implementation <bcp14>MUST</bcp14> allow the operator to view SR
Policy Identifier and SR Policy Candidate Path Identifier advertised
in an SRPA object.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view
the capabilities defined in this document advertised by each PCEP
peer.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view
LSPs associated with a specific SR Policy Identifier.</t>
</section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<t>The information carried in the newly defined SRPA object and TLVs <name>Requirements on Other Protocols</name>
could provide an eavesdropper with additional information about the <t>The PCEP extensions defined in this document do not imply any new req
SR Policy. uirements on other protocols.</t>
</t> </section>
<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 <section numbered="true" toc="default">
ns can only be activated on authenticated and encrypted sessions across PCEs and <name>Impact on Network Operations</name>
PCCs belonging to the same administrative authority, using Transport Layer Secu <t>The mechanisms defined in <xref target="RFC5440" format="default"/>,
rity (TLS) <xref target="RFC8253"/> as per the recommendations and best current <xref target="RFC8231" format="default"/>, <xref target="RFC9256" format="defaul
practices in <xref target="RFC9325"/>.</t> t"/>, and <xref target="RFC9603" format="default"/> also apply to the PCEP exten
</section> sions defined in this document.</t>
<section title="Manageability Considerations" numbered="true" toc="default"> </section>
<t>All manageability requirements and considerations listed in <xref target="R </section>
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> </middle>
<back>
<back> <displayreference target="I-D.ietf-pce-pcep-srv6-yang" to="PCEP-SRv6-YANG" /
>
<references title="Normative References"> <displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="ADV-SR-POLICY"
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xm />
l"?> <displayreference target="I-D.ietf-pce-multipath" to="PCEP-MULTIPATH" />
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xm <references>
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>
<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> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<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>
<section title="Contributors"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9830.xml"
<t><figure><artwork> />
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com <!-- [I-D.ietf-idr-bgp-ls-sr-policy]
-->
Cheng Li <reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ie
Huawei Technologies tf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-17">
Huawei Campus, No. 156 Beiqing Rd. <front>
Beijing, 10095 <title>Advertisement of Segment Routing Policies using BGP Link-State</tit
China le>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Individual</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="J." surname="Dong" fullname="Jie Dong">
<organization>Huawei Technologies</organization>
</author>
<author initials="H." surname="Gredler" fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date month="March" day="6" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-17"
/>
Email: chengli13@huawei.com </reference>
Zafar Ali <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
Cisco Systems, Inc. ietf-pce-multipath.xml"/>
<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>
Email: zali@cisco.com <section anchor="Acknowledgement" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="Abdul Rehman"/>, <contact
fullname="Andrew Stone"/>, <contact fullname="Boris Khasanov"/>,
<contact fullname="Cheng Li"/>, <contact fullname="Dhruv Dhody"/>,
<contact fullname="Gorry Fairhurst"/>, <contact fullname="Gyan
Mishra"/>, <contact fullname="Huaimo Chen"/>, <contact fullname="Ines
Robles"/>, <contact fullname="Joseph Salowey"/>, <contact
fullname="Ketan Talaulikar"/>, <contact fullname="Marina Fizgeer"/>,
<contact fullname="Mike Bishopm"/>, <contact fullname="Praveen Kumar"/>,
<contact fullname="Robert Sparks"/>, <contact fullname="Roman
Danyliw"/>, <contact fullname="Stephane Litkowski"/>, <contact
fullname="Tom Petch"/>, <contact fullname="Zoey Rose"/>, <contact
fullname="Xiao Min"/>, and <contact fullname="Xiong Quan"/> for their revi
ews and
suggestions.</t>
</section>
Rajesh Melarcode <section numbered="false" toc="default">
Cisco Systems, Inc. <name>Contributors</name>
2000 Innovation Dr.
Kanata, Ontario
Canada
Email: rmelarco@cisco.com <contact fullname="Dhruv Dhody">
<organization>Huawei</organization>
<address>
<postal>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
</artwork></figure></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>
</section> <!-- Contributors --> <contact fullname="Zafar Ali">
<organization>Cisco Systems, Inc</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
<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>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 102 change blocks. 
1333 lines changed or deleted 1348 lines changed or added

This html diff was produced by rfcdiff 1.48.