rfc9830xml2.original.xml   rfc9830.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?> <!DOCTYPE rfc [
<?rfc compact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc inline="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc subcompact="no"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc tocindent="yes"?> tf-idr-sr-policy-safi-13" number="9830" ipr="trust200902" consensus="true" updat
<?rfc tocompact="yes"?> es="9012" obsoletes="" submissionType="IETF" xml:lang="en" sortRefs="true" symRe
<rfc category="std" docName="draft-ietf-idr-sr-policy-safi-13" fs="true" tocInclude="true" tocDepth="3" version="3">
ipr="trust200902" updates="9012">
<front> <front>
<title abbrev="Segment Routing Policies in BGP">Advertising Segment <title abbrev="Segment Routing Policies in BGP">Advertising Segment
Routing Policies in BGP</title> Routing Policies in BGP</title>
<seriesInfo name="RFC" value="9830"/>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <country>Italy</country>
<city/>
<code/>
<country>IT</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Brussels</city> <city>Brussels</city>
<country>Belgium</country>
<region/>
<code/>
<country>BE</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
<author fullname="Ketan Talaulikar" initials="K." role="editor" aulikar">
surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Paul Mattes" initials="P." surname="Mattes"> <author fullname="Paul Mattes" initials="P." surname="Mattes">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street>One Microsoft Way</street> <street>One Microsoft Way</street>
<city>Redmond</city> <city>Redmond</city>
<region>WA</region> <region>WA</region>
<code>98052</code> <code>98052</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>pamattes@microsoft.com</email> <email>pamattes@microsoft.com</email>
</address> </address>
</author> </author>
<author fullname="Dhanendra Jain" initials="D." surname="Jain"> <author fullname="Dhanendra Jain" initials="D." surname="Jain">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>dhanendra.ietf@gmail.com</email> <email>dhanendra.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="September" year="2025"/>
<date/> <area>RTG</area>
<workgroup>idr</workgroup>
<abstract> <abstract>
<t>A Segment Routing (SR) Policy is an ordered list of segments (also <t>A Segment Routing (SR) Policy is an ordered list of segments (also
referred to as instructions) that define a source-routed policy. An SR referred to as "instructions") that define a source-routed policy. An SR
Policy consists of one or more candidate paths, each comprising one or Policy consists of one or more Candidate Paths (CPs), each comprising one
more segment lists. A headend can be provisioned with these candidate or
paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP.</t> more segment lists. A headend can be provisioned with these CPs using vari
ous mechanisms such as Command-Line Interface (CLI), Network Configuration Proto
col (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.</
t>
<t>This document specifies how BGP can be used to distribute SR Policy <t>This document specifies how BGP can be used to distribute SR Policy
candidate paths. It introduces a BGP SAFI for advertising a candidate CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and def
path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation ines sub-TLVs for the Tunnel Encapsulation
Attribute to signal information related to these candidate paths.</t> Attribute to signal information related to these CPs.</t>
<t>Furthermore, this document updates RFC 9012 by extending the Color
<t>Furthermore, this document updates RFC9012 by extending the Color
Extended Community to support additional steering modes over SR Extended Community to support additional steering modes over SR
Policy.</t> Policy.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>Segment Routing (SR) <xref target="RFC8402"/> allows a headend node <name>Introduction</name>
<t>Segment Routing (SR) <xref target="RFC8402" format="default"/> allows a
headend node
to steer a packet flow along a specific path. Intermediate per-path to steer a packet flow along a specific path. Intermediate per-path
states are eliminated thanks to source routing.</t> states are eliminated thanks to source routing.</t>
<t>The headend node is said to steer a flow into an SR Policy <xref target
<t>The headend node is said to steer a flow into an SR Policy <xref ="RFC9256" format="default"/>.</t>
target="RFC9256"/>.</t>
<t>The packets steered into an SR Policy carry an ordered list of <t>The packets steered into an SR Policy carry an ordered list of
segments associated with that SR Policy.</t> segments associated with that SR Policy.</t>
<t><xref target="RFC9256" format="default"/> further details the concepts
<t><xref target="RFC9256"/> further details the concepts of SR Policy of SR Policy
and steering into an SR Policy. These apply equally to the SR-MPLS and and steering into an SR Policy. These apply equally to the SR-MPLS and
Segment Routing for IPv6 (SRv6) data-plane instantiations of Segment Segment Routing over IPv6 (SRv6) data plane instantiations of Segment
Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described
in <xref target="RFC8402"/>. <xref target="RFC8660"/> describes the in <xref target="RFC8402" format="default"/>. <xref target="RFC8660" forma t="default"/> describes the
representation and processing of this ordered list of segments as an representation and processing of this ordered list of segments as an
MPLS label stack for SR-MPLS. While <xref target="RFC8754"/> and <xref MPLS label stack for SR-MPLS. <xref target="RFC8754" format="default"/> an
target="RFC8986"/> describe the same for SRv6 with the use of the d <xref target="RFC8986" format="default"/> describe the same for SRv6 with the
use of the
Segment Routing Header (SRH).</t> Segment Routing Header (SRH).</t>
<t>The functionality related to SR Policy described in <xref target="RFC92
<t>The SR Policy related functionality described in <xref 56" format="default"/> can be conceptually viewed as being incorporated in
target="RFC9256"/> can be conceptually viewed as being incorporated in an SR Policy Module (SRPM). The following is a reminder of the high-level
an SR Policy Module (SRPM). Following is a reminder of the high-level functionality of SRPM: </t>
functionality of SRPM: <list style="symbols"> <ul spacing="normal">
<t>Learning multiple candidate paths (CP) for an SR Policy via <li>
<t>Learning multiple CPs for an SR Policy via
various mechanisms (CLI, NETCONF, PCEP, or BGP).</t> various mechanisms (CLI, NETCONF, PCEP, or BGP).</t>
</li>
<t>Selection of the best candidate path for an SR Policy.</t> <li>
<t>Selection of the best CP for an SR Policy.</t>
<t>Associating a Binding SID (BSID) to the selected candidate path </li>
<li>
<t>Associating a Binding SID (BSID) to the selected CP
of an SR Policy.</t> of an SR Policy.</t>
</li>
<t>Installation of the selected candidate path and its BSID in the <li>
<t>Installation of the selected CP and its BSID in the
forwarding plane.</t> forwarding plane.</t>
</list></t> </li>
</ul>
<t>This document specifies the use of BGP to distribute one or more of <t>This document specifies the use of BGP to distribute one or more of
the candidate paths of an SR Policy to the headend of that policy. The the CPs of an SR Policy to the headend of that SR Policy. The
document describes the functionality provided by BGP and, as document describes the functionality provided by BGP and, as
appropriate, provides references for the functionality which is outside appropriate, provides references for the functionality, which is outside
the scope of BGP (i.e. resides within SRPM on the headend node).</t> the scope of BGP (i.e., resides within SRPM on the headend node).</t>
<t>This document specifies a way of representing SR Policy CPs in BGP UPDA
<t>This document specifies a way of representing SR Policy candidate TE messages. BGP can then be used to propagate the SR
paths in BGP UPDATE messages. BGP can then be used to propagate the SR Policy CPs to the headend nodes in a network. The usual BGP
Policy candidate paths to the headend nodes in a network. The usual BGP
rules for BGP propagation and best-path selection are used. At the rules for BGP propagation and best-path selection are used. At the
headend of a specific policy, this will result in one or more candidate headend of a specific SR Policy, this will result in one or more CPs being
paths being installed into the "BGP table". These paths are then passed installed into the "BGP table". These paths are then passed
to the SRPM. The SRPM may compare them to candidate paths learned via to the SRPM. The SRPM may compare them to CPs learned via
other mechanisms and will choose one or more paths to be installed in other mechanisms and will choose one or more paths to be installed in
the data plane. BGP itself does not install SR Policy candidate paths the data plane. BGP itself does not install SR Policy CPs
into the data plane.</t> into the data plane.</t>
<t>This document introduces a BGP Subsequent Address Family Identifier (SA
<t>This document introduces a BGP subsequent address family (SAFI) for FI) for
IPv4 and IPv6 address families. In UPDATE messages of those AFI/SAFIs, IPv4 and IPv6 address families. In BGP UPDATE messages of those AFI/SAFIs,
the Network Layer Reachability Information (NLRI) identifies an SR the Network Layer Reachability Information (NLRI) identifies an SR
Policy Candidate Path while the attributes encode the segment lists and Policy CP while the attributes encode the segment lists and
other details of that SR Policy Candidate Path.</t> other details of that SR Policy CP.</t>
<t>While, for simplicity, the text in this document states that BGP
<t>While for simplicity the text in this document states that BGP
advertises an SR Policy, it is to be understood that BGP advertises a advertises an SR Policy, it is to be understood that BGP advertises a
candidate path of an SR policy and that this SR Policy might have CP of an SR Policy and that this SR Policy might have
several other candidate paths provided via BGP (via an NLRI with a several other CPs provided via BGP (via an NLRI with a
different distinguisher as defined in <xref target="SRPOLICYSAFI"/>), different distinguisher as defined in <xref target="SRPOLICYSAFI" format="
default"/>),
PCEP, NETCONF, or local policy configuration.</t> PCEP, NETCONF, or local policy configuration.</t>
<t>Typically, an SR Policy Controller <xref target="RFC9256" format="defau
<t>Typically, a SR Policy Controller <xref target="RFC9256"/> defines lt"/> defines
the set of policies and advertises them to policy headend routers the set of policies and advertises them to SR Policy headend routers
(typically ingress routers). These policy advertisements use the BGP (typically ingress routers). These SR Policy advertisements use the BGP
extensions defined in this document. In most cases, the policy extensions defined in this document. In most cases, the SR Policy
advertisement is tailored for a specific policy headend; consequently, advertisement is tailored for a specific SR Policy headend; consequently,
it may be transmitted over a direct BGP session (i.e., without it may be transmitted over a direct BGP session (i.e., without
intermediate BGP hops) to that headend and is not propagated any intermediate BGP hops) to that headend and is not propagated any
further. In such cases, the policy advertisements will not traverse any further. In such cases, the SR Policy advertisements will not traverse any
Route Reflector (RR, <xref target="RFC4456"/>) (see <xref Route Reflector (RR) (see <xref target="RFC4456" format="default"/> and <x
target="PROPAGATE"/>).</t> ref target="PROPAGATE" format="default"/>).</t>
<t>Alternatively, a BGP egress router may advertise SR Policies that <t>Alternatively, a BGP egress router may advertise SR Policies that
represent paths terminating on itself. In such cases, the router can represent paths that terminate on it. In such cases, the router can
send these policies directly to each headend over a dedicated BGP send these policies directly to each headend over a dedicated BGP
session, without necessitating any further propagation of the session, without necessitating any further propagation of the
policy.</t> SR Policy.</t>
<t>In some situations, it is undesirable for a controller or BGP egress <t>In some situations, it is undesirable for a controller or BGP egress
router to have a BGP session to each policy headend. In these router to have a BGP session to each SR Policy headend. In these
situations, BGP Route Reflectors may be used to propagate the situations, BGP RRs may be used to propagate the
advertisements. In certain other deployments, it may be necessary for advertisements. In certain other deployments, it may be necessary for
the advertisement to propagate through a sequence of one or more ASes the advertisement to propagate through a sequence of one or more Autonomou
within an SR Domain (refer to <xref target="Security"/> for the s Systems (ASes)
within an SR Domain (refer to <xref target="Security" format="default"/> f
or the
associated security considerations). To make this possible, an attribute associated security considerations). To make this possible, an attribute
needs to be attached to the advertisement that enables a BGP speaker to needs to be attached to the advertisement that enables a BGP speaker to
determine whether it is intended to be a headend for the advertised determine whether it is intended to be a headend for the advertised
policy. This is done by attaching one or more Route Target Extended SR Policy. This is done by attaching one or more Route Target extended
Communities to the advertisement <xref target="RFC4360"/>.</t> communities to the advertisement <xref target="RFC4360" format="default"/>
.</t>
<t>The BGP extensions for the advertisement of SR Policies include <t>The BGP extensions for the advertisement of SR Policies include
following components: <list style="symbols"> following components: </t>
<t>A Subsequent Address Family Identifier (SAFI) whose NLRIs <ul spacing="normal">
identifies an SR Policy candidate path.</t> <li>
<t>A SAFI whose NLRIs
<t>A Tunnel Type identifier for SR Policy, and a set of sub-TLVs to identify an SR Policy CP.</t>
</li>
<li>
<t>A Tunnel Type identifier for SR Policy and a set of sub-TLVs to
be inserted into the Tunnel Encapsulation Attribute (as defined in be inserted into the Tunnel Encapsulation Attribute (as defined in
<xref target="RFC9012"/>) specifying segment lists of the SR Policy <xref target="RFC9012" format="default"/>) specifying segment lists of
candidate path, as well as other information about the SR the SR Policy
CP as well as other information about the SR
Policy.</t> Policy.</t>
</li>
<t>One or more IPv4 address-specific format route target extended <li>
community (<xref target="RFC4360"/>) attached to the SR Policy <t>One or more IPv4 address-specific format Route Target extended
Candidate Path advertisement and that indicates the intended headend community (<xref target="RFC4360" format="default"/>) attached to the
of such an SR Policy Candidate Path advertisement.</t> SR Policy
</list></t> CP advertisement that indicates the intended headend
of such an SR Policy CP advertisement.</t>
</li>
</ul>
<t>The SR Policy SAFI route updates utilize the Tunnel Encapsulation <t>The SR Policy SAFI route updates utilize the Tunnel Encapsulation
Attribute to signal an SR Policy, which itself functions as a tunnel. Attribute to signal an SR Policy, which itself functions as a tunnel.
This usage differs notably from the approach described in <xref This usage differs notably from the approach described in <xref target="RF
target="RFC9012"/>, where the Tunnel Encapsulation Attribute is C9012" format="default"/>, where the Tunnel Encapsulation Attribute is
associated with a BGP route update (e.g., for Internet or VPN routes) to associated with a BGP route update (e.g., for Internet or VPN routes) to
specify the tunnel used for forwarding traffic. This document does not specify the tunnel used for forwarding traffic. This document does not
modify or supersede the usage of the Tunnel Encapsulation Attribute for modify or supersede the usage of the Tunnel Encapsulation Attribute for
existing AFI/SAFIs as defined in <xref target="RFC9012"/>. Details existing AFI/SAFIs as defined in <xref target="RFC9012" format="default"/> . Details
regarding the processing of the Tunnel Encapsulation Attribute for the regarding the processing of the Tunnel Encapsulation Attribute for the
SR Policy SAFI are provided in <xref target="ENCAPSATTR"/> and <xref SR Policy SAFI are provided in Sections <xref target="ENCAPSATTR" format="
target="ENDCOLOR"/>.</t> counter"/> and <xref target="ENDCOLOR" format="counter"/>.</t>
<t>The northbound advertisement of the operational state of the SR <t>The northbound advertisement of the operational state of the SR
Policy Candidate Paths as part of BGP-LS <xref target="RFC9552"/> Policy CPs as part of BGP - Link State (BGP-LS) <xref target="RFC9552" for
topology information is specified in <xref mat="default"/>
target="I-D.ietf-idr-bgp-ls-sr-policy"/>.</t> topology information is specified in <xref target="I-D.ietf-idr-bgp-ls-sr-
policy" format="default"/>.</t>
<t>The signaling of Dynamic and Composite Candidate Paths (sections 5.2 <t>The signaling of Dynamic and Composite CPs (Sections
and 5.3 respectively of <xref target="RFC9256"/>) is outside the scope <xref target="RFC9256" sectionFormat="bare" section="5.2"/> and <xref
of this document.</t> target="RFC9256" sectionFormat="bare" section="5.3"/>, respectively, of
<xref target="RFC9256" format="default"/>) is outside the scope of this
<t>The Color Extended Community (as defined in <xref target="RFC9012"/>) document.</t>
is used to steer traffic into an SR Policy, as described in section 8.8 <t>The Color Extended Community (as defined in <xref target="RFC9012"
of <xref target="RFC9256"/>. The <xref target="EXTCOLOR"/> of this format="default"/>) is used to steer traffic into an SR Policy, as
document updates <xref target="RFC9012"/> with modifications to the described in <xref target="RFC9256" sectionFormat="of"
format of the Flags field of the Color Extended Community by using the section="8.8"/>. <xref target="EXTCOLOR" format="default"/> of this
two leftmost bits of that field.</t> document updates <xref target="RFC9012" format="default"/> with
modifications to the format of the Flags field of the Color Extended
<section title="Requirements Language"> Community by using the two leftmost bits of that field.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <section numbered="true" toc="default">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <name>Requirements Language</name>
"OPTIONAL" in this document are to be interpreted as described in BCP <t>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
when, they appear in all capitals, as shown here.</t> IRED</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>
</section> </section>
<section anchor="ENCODING" numbered="true" toc="default">
<name>SR Policy Encoding</name>
<section anchor="SRPOLICYSAFI" numbered="true" toc="default">
<name>SR Policy SAFI and NLRI</name>
<t>The SR Policy SAFI with
code point 73 is introduced in this document. The AFI used <bcp14>MUST</
bcp14> be IPv4(1) or IPv6(2).</t>
<t>The SR Policy SAFI uses the NLRI format defined as follows: </t>
<section anchor="ENCODING" title="SR Policy Encoding"> <figure>
<section anchor="SRPOLICYSAFI" title="SR Policy SAFI and NLRI"> <name>SR Policy SAFI Format</name>
<t>A SAFI is introduced in this document: the SR Policy SAFI with <artwork align="left" name="" type="" alt=""><![CDATA[
codepoint 73. The AFI used MUST be IPv4(1) or IPv6(2).</t>
<t>The SR Policy SAFI uses the NLRI format defined as follows: <figure
align="center">
<artwork align="left"><![CDATA[
+------------------+ +------------------+
| NLRI Length | 1 octet | NLRI Length | 1 octet
+------------------+ +------------------+
| Distinguisher | 4 octets | Distinguisher | 4 octets
+------------------+ +------------------+
| Policy Color | 4 octets | Color | 4 octets
+------------------+ +------------------+
| Endpoint | 4 or 16 octets | Endpoint | 4 or 16 octets
+------------------+ +------------------+
]]></artwork>
</figure>
Figure 1: SR Policy SAFI Format <t>Where:</t>
<dl spacing="normal">
where: ]]></artwork> <dt>NLRI Length:</dt><dd>1 octet indicating the length expressed in bi
</figure><list style="symbols"> ts as
<t>NLRI Length: 1 octet indicating the length expressed in bits as defined in <xref target="RFC4760" format="default"/>. When AFI = 1,
defined in <xref target="RFC4760"/>. When AFI = 1 the value MUST the value <bcp14>MUST</bcp14> be 96; when AFI = 2, the value
be 96 and when AFI = 2 the value MUST be 192.</t> <bcp14>MUST</bcp14> be 192.</dd>
<t>Distinguisher: 4-octet value uniquely identifying the policy in
the context of &lt;color, endpoint&gt; tuple. The distinguisher
has no semantic value and is solely used by the SR Policy
originator to make unique (from an NLRI perspective) both for
multiple candidate paths of the same SR Policy as well as
candidate paths of different SR Policies (i.e. with different
segment lists) with the same Color and Endpoint but meant for
different headends. The distinguisher is the discriminator of the
SR Policy candidate path as specified in section 2.5 of <xref
target="RFC9256"/>.</t>
<t>Policy Color: 4 octets that carry an unsigned non-zero integer
value indicating the color of the SR Policy as specified in
section 2.1 of <xref target="RFC9256"/>. The color is used to
match the color of the destination prefixes to steer traffic into
the SR Policy as specified in section 8 of <xref
target="RFC9256"/>.</t>
<t>Endpoint: value identifies the endpoint of a policy. The
Endpoint may represent a single node or a set of nodes (e.g., an
anycast address). The Endpoint is an IPv4 (4-octet) address or an
IPv6 (16-octet) address according to the AFI of the NLRI. The
address can be either a unicast or an unspecified address (0.0.0.0
for IPv4, :: for IPv6), known as null endpoint, as specified in
section 2.1 of <xref target="RFC9256"/>.</t>
</list></t>
<t>The color and endpoint are used to automate the steering of BGP <dt>Distinguisher:</dt><dd><t>4-octet value uniquely identifying the S
service routes on SR Policy as described in section 8 of <xref R Policy in
target="RFC9256"/>.</t> the context of &lt;Color, Endpoint&gt; tuple. The distinguisher has
no semantic value. It is used by the SR Policy originator to form
unique NLRIs the following situations:</t>
<ul spacing="normal">
<li>to differentiate multiple CPs
of the same SR Policy</li>
<li>to differentiate CPs meant for different headends but having the
same Color and Endpoint</li>
</ul>
<t>The distinguisher is
the discriminator of the SR Policy CP as specified in
<xref target="RFC9256" sectionFormat="of" section="2.5"/>.</t></dd>
<dt>Color:</dt><dd>4 octets that carry an unsigned non-zero integer
value indicating the Color of the SR Policy as specified in <xref
target="RFC9256" sectionFormat="of" section="2.1"/>. The Color is
used to match the Color of the destination prefixes to steer traffic
into the SR Policy as specified in <xref target="RFC9256"
sectionFormat="of" section="8"/>.</dd>
<dt>Endpoint:</dt><dd>a value that identifies the Endpoint of an SR Po
licy. The
Endpoint may represent a single node or a set of nodes (e.g., an
anycast address). The Endpoint is an IPv4 (4-octet) address or an
IPv6 (16-octet) address according to the AFI of the NLRI. The
address can be either unicast or an unspecified address (0.0.0.0
for IPv4, :: for IPv6), known as a null Endpoint as specified in
<xref target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>
</dl>
<t>The NLRI containing an SR Policy candidate path is carried in a BGP <t>The Color and Endpoint are used to automate the steering of BGP
UPDATE message <xref target="RFC4271"/> using BGP multi-protocol service routes on an SR Policy as described in <xref target="RFC9256" se
extensions <xref target="RFC4760"/> with an AFI of 1 or 2 (IPv4 or ctionFormat="of" section="8"/>.</t>
<t>The NLRI containing an SR Policy CP is carried in a BGP
UPDATE message <xref target="RFC4271" format="default"/> using BGP multi
protocol
extensions <xref target="RFC4760" format="default"/> with an AFI of 1 or
2 (IPv4 or
IPv6) and with a SAFI of 73. The fault management and error handling IPv6) and with a SAFI of 73. The fault management and error handling
in the encoding of the NLRI is specified in <xref in the encoding of the NLRI are specified in <xref target="ERROR" format
target="ERROR"/>.</t> ="default"/>.</t>
<t>A BGP UPDATE message that carries the MP_REACH_NLRI or MP_UNREACH_NLR
<t>An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI I
attribute with the SR Policy SAFI MUST also carry the BGP mandatory attribute with the SR Policy SAFI <bcp14>MUST</bcp14> also carry the BGP
attributes. In addition, the BGP update message MAY also contain any mandatory
attributes. In addition, the BGP UPDATE message <bcp14>MAY</bcp14> also
contain any
of the BGP optional attributes.</t> of the BGP optional attributes.</t>
<t>The next-hop network address field in SR Policy SAFI (73) updates <t>The next-hop network address field in SR Policy SAFI (73) updates
may be either a 4-octet IPv4 address or a 16-octet IPv6 address, may be either a 4-octet IPv4 address or a 16-octet IPv6 address,
independent of the SR Policy AFI. The length field of the next-hop independent of the SR Policy AFI. The Length field of the next-hop
address specifies the next-hop address family. If the next-hop length address specifies the next-hop address family. If the next-hop length
is 4, then the next-hop is an IPv4 address; if the next-hop length is is 4, then the next-hop is an IPv4 address. If the next-hop length is
16, then it is a global IPv6 address; if the next-hop length is 32, 16, then it is a global IPv6 address. If the next-hop length is 32,
then it has a global IPv6 address followed by a link-local IPv6 then it has a global IPv6 address followed by a link-local IPv6
address. The setting of the next-hop field and its attendant address. The setting of the next-hop field and its attendant
processing is governed by standard BGP procedures as described in processing is governed by standard BGP procedures as described in
section 3 of <xref target="RFC4760"/> and section 3 of <xref <xref target="RFC4760" sectionFormat="of" section="3"/> and <xref target
target="RFC2545"/>.</t> ="RFC2545" sectionFormat="of" section="3"/>.</t>
<t>It is important to note that at any BGP speaker receiving BGP <t>It is important to note that at any BGP speaker receiving BGP
updates with SR Policy NLRIs, the SRPM processes only the best path as updates with SR Policy NLRIs, the SRPM processes only the best path as
per the BGP best-path selection algorithm. In other words, this per the BGP best-path selection algorithm. In other words, this
document leverages the existing BGP propagation and best-path document leverages the existing BGP propagation and best-path
selection rules. Details of the procedures are described in <xref selection rules. Details of the procedures are described in <xref target
target="OPERATIONS"/>.</t> ="OPERATIONS" format="default"/>.</t>
<t>It has to be noted that if several CPs of the same SR
<t>It has to be noted that if several candidate paths of the same SR Policy (Endpoint, Color) are signaled via BGP to a headend, then it is
Policy (endpoint, color) are signaled via BGP to a headend, then it is <bcp14>RECOMMENDED</bcp14> that each NLRI use a different distinguisher.
RECOMMENDED that each NLRI uses a different distinguisher. If BGP has If BGP has
installed into the BGP table two advertisements whose respective NLRIs installed into the BGP table two advertisements whose respective NLRIs
have the same color and endpoint, but different distinguishers, both have the same Color and Endpoint, but different distinguishers, both
advertisements are passed to the SRPM as different candidate paths advertisements are passed to the SRPM as different CPs
along with their respective originator information (i.e., ASN and BGP along with their respective originator information (i.e., Autonomous Sys
Router-ID) as described in section 2.4 of <xref target="RFC9256"/>. tem Number (ASN) and BGP
Router-ID) as described in <xref target="RFC9256" sectionFormat="of" sec
tion="2.4"/>.
The ASN would be the ASN of the origin and the BGP Router-ID is The ASN would be the ASN of the origin and the BGP Router-ID is
determined in the following order:<list style="symbols"> determined in the following order:</t>
<t>From the Route Origin Community <xref target="RFC4360"/> if <ul spacing="normal">
<li>
<t>From the Route Origin Community <xref target="RFC4360" format="de
fault"/> if
present and carrying an IP Address, or</t> present and carrying an IP Address, or</t>
</li>
<li>
<t>As the BGP Originator ID <xref target="RFC4456"/> if present, <t>As the BGP ORIGINATOR_ID <xref target="RFC4456" format="default"/ > if present,
or</t> or</t>
</li>
<li>
<t>As the BGP Router-ID of the peer from which the update was <t>As the BGP Router-ID of the peer from which the update was
received as a last resort.</t> received as a last resort.</t>
</list></t> </li>
</ul>
<t>The Section 2.9 of <xref target="RFC9256"/> specifies the selection <t><xref target="RFC9256" sectionFormat="of" section="2.9"/> specifies t
of the active candidate path of the SR Policy by the SRPM based on the he selection
of the active CP of the SR Policy by the SRPM based on the
information provided to it by BGP.</t> information provided to it by BGP.</t>
</section> </section>
<section anchor="ENCAPSATTR" numbered="true" toc="default">
<name>SR Policy and Tunnel Encapsulation Attribute</name>
<section anchor="ENCAPSATTR" <t>The content of the SR Policy CP is encoded in the
title="SR Policy and Tunnel Encapsulation Attribute"> Tunnel Encapsulation Attribute defined in <xref target="RFC9012" format=
<t>The content of the SR Policy Candidate Path is encoded in the "default"/>
Tunnel Encapsulation Attribute defined in <xref target="RFC9012"/> using a Tunnel Type called the "SR Policy" type with code point 15. The
using a Tunnel-Type called SR Policy Type with codepoint 15. The use use
of SR Policy Tunnel-type is applicable only for the AFI/SAFI pairs of of the SR Policy Tunnel Type is applicable only for the AFI/SAFI pairs o
f
(1/73, 2/73). This document specifies the use of the Tunnel (1/73, 2/73). This document specifies the use of the Tunnel
Encapsulation Attribute with the SR Policy Tunnel-Type and the use of Encapsulation Attribute with the SR Policy Tunnel Type and the use of
any other Tunnel-Type with the SR Policy SAFI MUST be considered any other Tunnel Type with the SR Policy SAFI <bcp14>MUST</bcp14> be con
malformed and handled by the "Treat-as-Withdraw" strategy <xref sidered
target="RFC7606"/>.</t> malformed and handled by the "treat-as-withdraw" strategy <xref target="
RFC7606" format="default"/>.</t>
<t>The SR Policy Encoding structure is as follows: </t>
<t>The SR Policy Encoding structure is as follows: <figure <figure>
align="center"> <name>SR Policy Encoding</name>
<artwork align="left"><![CDATA[SR Policy SAFI NLRI: <Distinguisher, <artwork align="left" name="" type="" alt=""><![CDATA[
Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Color, Endpoint>
Attributes: Attributes:
Tunnel Encapsulation Attribute (23) Tunnel Encapsulation Attribute (23)
Tunnel Type: SR Policy (15) Tunnel Type: SR Policy (15)
Binding SID Binding SID
Preference Preference
Priority Priority
Policy Name SR Policy Name
Policy Candidate Path Name SR Policy Candidate Path Name
Explicit NULL Label Policy (ENLP) Explicit NULL Label Policy (ENLP)
Segment List Segment List
Weight Weight
Segment Segment
Segment Segment
... ...
... ...
]]></artwork>
</figure>
Figure 2: SR Policy Encoding <t>Where:</t>
<ul spacing="normal">
where:]]></artwork> <li>
</figure><list style="symbols"> <t>The SR Policy SAFI NLRI is defined in <xref target="SRPOLICYSAFI"
<t>SR Policy SAFI NLRI is defined in <xref format="default"/>.</t>
target="SRPOLICYSAFI"/>.</t> </li>
<li>
<t>Tunnel Encapsulation Attribute is defined in <xref <t>The Tunnel Encapsulation Attribute is defined in <xref target="RF
target="RFC9012"/>.</t> C9012" format="default"/>.</t>
</li>
<t>Tunnel-Type is set to 15.</t> <li>
<t>The Tunnel Type is set to 15.</t>
<t>Preference, Binding SID, Priority, Policy Name, Policy </li>
<li>
<t>Preference, Binding SID, Priority, SR Policy Name, SR Policy
Candidate Path Name, ENLP, Segment-List, Weight, and Segment Candidate Path Name, ENLP, Segment-List, Weight, and Segment
sub-TLVs are defined in <xref target="SRPOLICYTLV"/>.</t> sub-TLVs are defined in <xref target="SRPOLICYTLV" format="default"/
>.</t>
</li>
<li>
<t>Additional sub-TLVs may be defined in the future.</t> <t>Additional sub-TLVs may be defined in the future.</t>
</list></t> </li>
</ul>
<t>A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV
of type "SR Policy"; such updates MUST be considered malformed and
handled by the "Treat-as-Withdraw" strategy <xref
target="RFC7606"/>.</t>
<t>A Tunnel Encapsulation Attribute <bcp14>MUST NOT</bcp14> contain more
than one TLV
of type "SR Policy"; such updates <bcp14>MUST</bcp14> be considered malf
ormed and
handled by the "treat-as-withdraw" strategy <xref target="RFC7606" forma
t="default"/>.</t>
<t>BGP does not need to perform the validation of the tunnel (i.e., SR <t>BGP does not need to perform the validation of the tunnel (i.e., SR
Policy) itself as indicated in section 6 of <xref target="RFC9012"/>. Policy) itself as indicated in <xref target="RFC9012" sectionFormat="of" section="6"/>.
The validation of the SR Policy information that is advertised using The validation of the SR Policy information that is advertised using
the sub-TLVs specified in <xref target="SRPOLICYTLV"/> is performed by the sub-TLVs specified in <xref target="SRPOLICYTLV" format="default"/> is performed by
the SRPM.</t> the SRPM.</t>
</section> </section>
<section anchor="ENDCOLOR" numbered="true" toc="default">
<section anchor="ENDCOLOR" <name>Applicability of Tunnel Encapsulation Attribute Sub-TLVs</name>
title="Applicability of Tunnel Encapsulation Attribute Sub-TLVs">
<t>The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel <t>The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel
Encapsulation Attribute, as defined in <xref target="RFC9012"/>, are Encapsulation Attribute, as defined in <xref target="RFC9012" format="de fault"/>, are
not utilized for SR Policy encodings. Consequently, their values are not utilized for SR Policy encodings. Consequently, their values are
not relevant within the context of the SR Policy SAFI NLRI. If these not relevant within the context of the SR Policy SAFI NLRI. If these
sub-TLVs are present, a BGP speaker MUST ignore them and MAY remove sub-TLVs are present, a BGP speaker <bcp14>MUST</bcp14> ignore them and <bcp14>MAY</bcp14> remove
them from the Tunnel Encapsulation Attribute during propagation.</t> them from the Tunnel Encapsulation Attribute during propagation.</t>
<t>Similarly, any other sub-TLVs, including those specified in <xref tar
<t>Similarly, any other sub-TLVs, including those specified in <xref get="RFC9012" format="default"/>, that do not have explicitly defined applicabil
target="RFC9012"/>, that do not have explicitly defined applicability ity
to the SR Policy SAFI MUST be ignored by the BGP speaker and MAY be to the SR Policy SAFI <bcp14>MUST</bcp14> be ignored by the BGP speaker
and <bcp14>MAY</bcp14> be
removed from the Tunnel Encapsulation Attribute during removed from the Tunnel Encapsulation Attribute during
propagation.</t> propagation.</t>
</section> </section>
<section anchor="SRPOLICYTLV" numbered="true" toc="default">
<section anchor="SRPOLICYTLV" title="SR Policy Sub-TLVs"> <name>SR Policy Sub-TLVs</name>
<t>This section specifies the sub-TLVs defined for encoding the <t>This section specifies the sub-TLVs defined for encoding the
information about the SR Policy Candidate Path.</t> information about the SR Policy Candidate Path.</t>
<t>Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, <t>Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority,
Policy Name, Policy Candidate Path Name, and Explicit NULL Label SR Policy Name, SR Policy Candidate Path Name, and Explicit NULL Label
Policy are all optional sub-TLVs introduced for the BGP Tunnel Policy are all optional sub-TLVs introduced for the BGP Tunnel
Encapsulation Attribute <xref target="RFC9012"/> being defined in this Encapsulation Attribute <xref target="RFC9012" format="default"/> being defined in this
section.</t> section.</t>
<t>Weight and Segment are sub-TLVs of the Segment-List sub-TLV <t>Weight and Segment are sub-TLVs of the Segment-List sub-TLV
mentioned above.</t> mentioned above.</t>
<t>An early draft version of this document included only the Binding SID
<t>An early version of this document included only the Binding SID sub-TLV that could be used for both SR-MPLS and SRv6 BSIDs. The
sub-TLV that could be used for both SR-MPLS and SRv6 Binding SIDs. The
SRv6 Binding SID TLV was introduced in later versions to support the SRv6 Binding SID TLV was introduced in later versions to support the
advertisement of additional SRv6 capabilities without affecting advertisement of additional SRv6 capabilities without affecting
backward compatibility for early implementations.</t> backward compatibility for early implementations.</t>
<t>The fault management and error handling in the encoding of the <t>The fault management and error handling in the encoding of the
sub-TLVs defined in this section are specified in <xref sub-TLVs defined in this section are specified in <xref target="ERROR" f
target="ERROR"/>. For the TLVs/sub-TLVs that are specified as single ormat="default"/>. For the TLVs/sub-TLVs that are specified as single
instance, only the first instance of that TLV/sub-TLV is used and the instance, only the first instance of that TLV/sub-TLV is used: the
other instances MUST be ignored and MUST NOT considered to be other instances <bcp14>MUST</bcp14> be ignored and <bcp14>MUST NOT</bcp1
4> considered to be
malformed.</t> malformed.</t>
<t>None of the sub-TLVs defined in the following subsections have any
<t>None of the sub-TLVs defined in the following sub-sections have any
effect on the BGP best-path selection or propagation procedures. These effect on the BGP best-path selection or propagation procedures. These
sub-TLVs are not used by the BGP path selection process and are sub-TLVs are not used by the BGP path selection process and are
instead passed on to SRPM as SR Policy Candidate Path information for instead passed on to SRPM as SR Policy Candidate Path information for
further processing described in section 2 of <xref further processing as described in <xref target="RFC9256" sectionFormat=
target="RFC9256"/>.</t> "of" section="2"/>.</t>
<t>The use of SR Policy sub-TLVs is applicable only for the AFI/SAFI
<t>The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI
pairs of (1/73, 2/73). Future documents may extend their applicability pairs of (1/73, 2/73). Future documents may extend their applicability
to other AFI/SAFI.</t> to other AFI/SAFI.</t>
<section anchor="PREFTLV" numbered="true" toc="default">
<section anchor="PREFTLV" title="Preference Sub-TLV"> <name>Preference Sub-TLV</name>
<t>The Preference sub-TLV is used to carry the Preference of an SR <t>The Preference sub-TLV is used to carry the Preference of an SR
Policy candidate path. The contents of this sub-TLV are used by the Policy CP. The contents of this sub-TLV are used by the
SRPM as described in section 2.7 of <xref target="RFC9256"/>.</t> SRPM as described in <xref target="RFC9256" sectionFormat="of" section
="2.7"/>.</t>
<t>The Preference sub-TLV is OPTIONAL and it MUST NOT appear more <t>The Preference sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST N
OT</bcp14> appear more
than once in the SR Policy encoding.</t> than once in the SR Policy encoding.</t>
<t>The Preference sub-TLV has the following format: </t>
<t>The Preference sub-TLV has following format: <figure <figure>
align="center"> <name>Preference Sub-TLV</name>
<artwork align="left"><![CDATA[ 0 1 <artwork align="left" name="" type="" alt=""><![CDATA[
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 | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) | | Preference (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 3: Preference sub-TLV <t>Where:</t>
<dl spacing="normal">
where: ]]></artwork> <dt>Type:</dt><dd>12</dd>
</figure><list style="symbols">
<t>Type: 12</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e., n ot
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
MUST be 6.</t> <bcp14>MUST</bcp14> be 6.</dd>
<t>Flags: 1 octet of flags. No flags are defined in this <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
document. The Flags field MUST be set to zero on transmission document. The Flags field <bcp14>MUST</bcp14> be set to zero on tr
and MUST be ignored on receipt.</t> ansmission
and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
zero on transmission and MUST be ignored on receipt.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<t>Preference: a 4-octet value indicating the Preference of the <dt>Preference:</dt><dd>a 4-octet value indicating the Preference
SR Policy Candidate Path as described in section 2.7 of <xref of the
target="RFC9256"/>.</t> SR Policy CP as described in <xref target="RFC9256" sectionFormat=
</list></t> "of" section="2.7"/>.</dd>
</section>
<section anchor="BINDINGSIDTLV" title="Binding SID Sub-TLV"> </dl>
<t>The Binding SID sub-TLV is used to signal the binding SID related
information of the SR Policy candidate path. The contents of this
sub-TLV are used by the SRPM as described in section 6 in <xref
target="RFC9256"/>.</t>
<t>The Binding SID sub-TLV is OPTIONAL and it MUST NOT appear more </section>
<section anchor="BINDINGSIDTLV" numbered="true" toc="default">
<name>Binding SID Sub-TLV</name>
<t>The Binding SID sub-TLV is used to signal the BSID-related
information of the SR Policy CP. The contents of this
sub-TLV are used by the SRPM as described in <xref target="RFC9256" se
ctionFormat="of" section="6"/>.</t>
<t>The Binding SID sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST
NOT</bcp14> appear more
than once in the SR Policy encoding.</t> than once in the SR Policy encoding.</t>
<t>When the Binding SID sub-TLV is used to signal an SRv6 SID, the <t>When the Binding SID sub-TLV is used to signal an SRv6 SID, the
selection of the corresponding SRv6 Endpoint Behavior <xref selection of the corresponding SRv6 Endpoint Behavior <xref target="RF
target="RFC8986"/> to be instantiated is determined by the headend C8986" format="default"/> to be instantiated is determined by the headend
node. It is RECOMMENDED that the SRv6 Binding SID sub-TLV, as node. It is <bcp14>RECOMMENDED</bcp14> that the SRv6 Binding SID sub-T
defined in Section 2.4.3, be used when signaling an SRv6 Binding SID LV, as
for an SR Policy candidate path. The support for the use of this defined in <xref target="SRV6BINDINGSIDTLV" format="default"/>, be use
Binding SID sub-TLV for signaling of SRv6 Binding SID is retained d when signaling an SRv6 BSID
for an SR Policy CP. The support for the use of this
Binding SID sub-TLV for the signaling of an SRv6 BSID is retained
primarily for backward compatibility with implementations that primarily for backward compatibility with implementations that
followed early versions of this document that had not defined the followed early draft versions of this document that had not defined th e
SRv6 Binding SID sub-TLV.</t> SRv6 Binding SID sub-TLV.</t>
<t>The Binding SID sub-TLV has the following format: </t>
<t>The Binding SID sub-TLV has the following format: <figure <figure>
align="center"> <name>Binding SID Sub-TLV</name>
<artwork align="left"><![CDATA[ 0 1 <artwork align="left" name="" type="" alt=""><![CDATA[
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 | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (variable, optional) | | Binding SID (variable, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Figure 4: Binding SID sub-TLV </figure>
<t>Where:</t>
where: ]]></artwork> <dl spacing="normal">
</figure><list style="symbols"> <dt>Type:</dt><dd>13</dd>
<t>Type: 13</t> <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
not
<t>Length: Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
MUST be one of: 18 when a SRv6 BSID is present, 6 when a SR-MPLS <bcp14>MUST</bcp14> be 18 when a SRv6 BSID is present, 6 when an S
BSID is present, or 2 when no BSID is present.</t> R-MPLS
BSID is present, or 2 when no BSID is present.</dd>
<dt>Flags:</dt><dd><t>1 octet of flags. The following flags are de
fined in
the registry "SR Policy Binding SID Flags" as described in <xref t
arget="IANABSIDFLAGS" format="default"/>:</t>
<t>Flags: 1 octet of flags. The following flags are defined in <figure>
the registry "SR Policy Binding SID Flags" as described in <xref <name>SR Policy Binding SID Flags</name>
target="IANABSIDFLAGS"/>: <figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|I| | |S|I| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: SR Policy Binding SID Flags
]]></artwork> ]]></artwork>
</figure>where:<list> </figure>
<t>S-Flag: This flag encodes the "Specified-BSID-only" <t>Where:</t>
behavior. It is used by SRPM as described in section 6.2.3 <ul spacing="normal">
in <xref target="RFC9256"/>.</t>
<t>I-Flag: This flag encodes the "Drop Upon Invalid" <li>The S-Flag encodes the "Specified-BSID-Only"
behavior. It is used by SRPM as described in section 8.2 in behavior. It is used by SRPM as described in <xref
<xref target="RFC9256"/> to define a specific SR Policy target="RFC9256" sectionFormat="of" section="6.2.3"/>.</li>
forwarding behavior. The flag indicates that the SR Policy <li>The I-Flag encodes the "Drop-Upon-Invalid"
is to perform the "drop upon invalid" behavior when no valid behavior. It is used by SRPM as described in <xref
candidate path (CP) is available for this SR Policy. In this target="RFC9256" sectionFormat="of" section="8.2"/> to
situation, the CP with the highest preference amongst those define a specific SR Policy forwarding behavior. The flag
with the "drop upon invalid" config is made active to drop indicates that the SR Policy is to perform the "Drop-Upon-Inva
traffic steered over the SR Policy.</t> lid" behavior when no valid CP is
available for this SR Policy. In this situation, the CP with
the highest preference amongst those with the "Drop-Upon-Inval
id" behavior is made active to drop traffic steered over
the SR Policy.</li>
<t>The unassigned bits in the Flag octet MUST be set to zero <li>The unassigned bits in the Flags field <bcp14>MUST</bcp14>
upon transmission and MUST be ignored upon receipt.</t> be set to zero
</list></t> upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
ipt.
</li>
</ul></dd>
<t>RESERVED: 1 octet of reserved bits. MUST be set to zero on <dt>RESERVED:</dt><dd>1 octet of reserved bits. <bcp14>MUST</bcp14
transmission and MUST be ignored on receipt.</t> > be set to zero on
transmission and <bcp14>MUST</bcp14> be ignored on receipt.
</dd>
<t>Binding SID: If the length is 2, then no Binding SID is <dt>Binding SID:</dt><dd><t>If the length is 2, then no BSID is
present. If the length is 6 then the Binding SID is encoded in 4 present. If the length is 6, then the BSID is encoded in 4
octets using the format below. Traffic Class (TC), S, and TTL octets using the format below. Traffic Class (TC), S, and TTL
(Total of 12 bits) are RESERVED and MUST be set to zero and MUST (Total of 12 bits) are RESERVED and <bcp14>MUST</bcp14> be set to
be ignored. <figure> zero and <bcp14>MUST</bcp14>
<artwork><![CDATA[ 0 1 be ignored.</t>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding SID Label Encoding
<figure>
<name>Binding SID Label Encoding</name>
<artwork name="" type="" align="left" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The Label field is validated by the SRPM, but MUST </figure>
NOT contain the reserved MPLS label values (0-15). If the length <t>The Label field is validated by the SRPM but <bcp14>MUST
is 18 then the Binding SID contains a 16-octet SRv6 SID.</t> NOT</bcp14> contain the reserved MPLS label values (0-15). If the
</list></t> length
is 18, then the BSID contains a 16-octet SRv6 SID.</t>
</dd>
</dl>
</section> </section>
<section anchor="SRV6BINDINGSIDTLV" numbered="true" toc="default">
<section anchor="SRV6BINDINGSIDTLV" title="SRv6 Binding SID Sub-TLV"> <name>SRv6 Binding SID Sub-TLV</name>
<t>The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding <t>The SRv6 Binding SID sub-TLV is used to signal the SRv6-BSID-relate
SID related information of an SR Policy candidate path. It enables d information of an SR Policy CP. It enables
the specification of the SRv6 Endpoint Behavior <xref the specification of the SRv6 Endpoint Behavior <xref
target="RFC8986"/> to be instantiated on the headend node. The target="RFC8986" format="default"/> to be instantiated on the
contents of this sub-TLV are used by the SRPM as described in headend node. The contents of this sub-TLV are used by the SRPM as
section 6 in <xref target="RFC9256"/>.</t> described in <xref target="RFC9256" sectionFormat="of"
section="6"/>.</t>
<t>The SRv6 Binding SID sub-TLV is OPTIONAL. More than one SRv6 <t>The SRv6 Binding SID sub-TLV is <bcp14>OPTIONAL</bcp14>. More than
Binding SID sub-TLVs MAY be signaled in the same SR Policy encoding one SRv6
Binding SID sub-TLV <bcp14>MAY</bcp14> be signaled in the same SR Poli
cy encoding
to indicate one or more SRv6 SIDs, each with potentially different to indicate one or more SRv6 SIDs, each with potentially different
SRv6 Endpoint Behaviors to be instantiated.</t> SRv6 Endpoint Behaviors to be instantiated.</t>
<t>The SRv6 Binding SID sub-TLV has the following format:</t>
<t>The SRv6 Binding SID sub-TLV has the following format: <figure <figure>
align="center"> <name>SRv6 Binding SID Sub-TLV</name>
<artwork align="left"><![CDATA[ 0 1 <artwork align="left" name="" type="" alt=""><![CDATA[
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 | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Binding SID (16 octets) | | SRv6 Binding SID (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure (optional) // // SRv6 Endpoint Behavior and SID Structure (optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 7: SRv6 Binding SID sub-TLV <t>Where:</t>
<dl spacing="normal">
where: ]]></artwork> <dt>Type:</dt><dd>20</dd>
</figure><list style="symbols">
<t>Type: 20</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is <bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Behavior and SID
present else it MUST be 18.</t> Structure is
present; else, it <bcp14>MUST</bcp14> be 18.</dd>
<t>Flags: 1 octet of flags. The following flags are defined in <dt>Flags:</dt><dd><t>1 octet of flags. The following flags are de fined in
the registry "SR Policy SRv6 Binding SID Flags" as described in the registry "SR Policy SRv6 Binding SID Flags" as described in
<xref target="IANASRV6BSIDFLAGS"/>: <figure align="center"> <xref target="IANASRV6BSIDFLAGS" format="default"/>:</t>
<artwork align="left"><![CDATA[
<figure>
<name>SR Policy SRv6 Binding SID Flags</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|I|B| | |S|I|B| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 8: SR Policy SRv6 Binding SID Flags
]]></artwork> ]]></artwork>
</figure> where:<list> </figure>
<t>S-Flag: This flag encodes the "Specified-BSID-only" <t>Where:</t>
behavior. It is used by SRPM as described in section 6.2.3 <ul spacing="normal">
in <xref target="RFC9256"/>.</t> <li>The S-Flag encodes the "Specified-BSID-Only"
behavior. It is used by SRPM as described
in <xref target="RFC9256" sectionFormat="of" section="6.2.3"/>
.</li>
<t>I-Flag: This flag encodes the "Drop Upon Invalid" <li>The I-Flag encodes the "Drop-Upon-Invalid"
behavior. It is used by SRPM as described in section 8.2 in behavior. It is used by SRPM as described in
<xref target="RFC9256"/>.</t> <xref target="RFC9256" sectionFormat="of" section="8.2"/>.</li
>
<t>B-Flag: This flag, when set, indicates the presence of <li>The B-Flag, when set, indicates the presence of
the SRv6 Endpoint Behavior and SID Structure encoding the "SRv6 Endpoint Behavior &amp; SID Structure" encoding
specified in <xref target="BEHAVIORSTRUCT"/>.</t> specified in <xref target="BEHAVIORSTRUCT" format="default"/>.
</li>
<t>The unassigned bits in the Flag octet MUST be set to zero <li>The unassigned bits in the Flags field <bcp14>MUST</bcp14>
upon transmission and MUST be ignored upon receipt.</t> be set to zero
</list></t> upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
ipt.</li>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to </ul></dd>
zero on transmission and MUST be ignored on receipt.</t>
<t>SRv6 Binding SID: Contains a 16-octet SRv6 SID. The value 0 <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
MAY be used when the controller wants to indicate the desired MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<dt>SRv6 Binding SID:</dt><dd>Contains a 16-octet SRv6 SID. The va
lue 0
<bcp14>MAY</bcp14> be used when the controller wants to indicate t
he desired
SRv6 Endpoint Behavior, SID Structure, or flags without SRv6 Endpoint Behavior, SID Structure, or flags without
specifying the BSID.</t> specifying the BSID.</dd>
<t>SRv6 Endpoint Behavior and SID Structure: Optional, as <dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional, as
defined in <xref target="BEHAVIORSTRUCT"/>. The SRv6 Endpoint defined in <xref target="BEHAVIORSTRUCT" format="default"/>. The S
Behavior and SID Structure MUST NOT be included when the SRv6 Rv6 Endpoint
SID has not been included.</t> Behavior and SID Structure <bcp14>MUST NOT</bcp14> be included whe
</list></t> n the SRv6
</section> SID has not been included.</dd>
<section anchor="SLTLV" title="Segment List Sub-TLV "> </dl>
</section>
<section anchor="SLTLV" numbered="true" toc="default">
<name>Segment List Sub-TLV</name>
<t>The Segment List sub-TLV encodes a single explicit path towards <t>The Segment List sub-TLV encodes a single explicit path towards
the endpoint as described in section 5.1 of <xref the Endpoint as described in <xref target="RFC9256"
target="RFC9256"/>. The Segment List sub-TLV includes the elements sectionFormat="of" section="5.1"/>. The Segment List sub-TLV
of the paths (i.e., segments) as well as an optional Weight includes the elements of the paths (i.e., segments) as well as an
sub-TLV.</t> optional Weight sub-TLV.</t>
<t>The Segment List sub-TLV may exceed 255 bytes in length due to a <t>The Segment List sub-TLV may exceed 255 bytes in length due to a
large number of segments. A 2-octet length is thus required. large number of segments. A 2-octet length is thus required.
According to section 2 of <xref target="RFC9012"/>, the sub-TLV type According to <xref target="RFC9012" sectionFormat="of" section="2"/>,
defines the size of the length field. Therefore, for the Segment the sub-TLV type
defines the size of the Length field. Therefore, for the Segment
List sub-TLV, a code point of 128 or higher is used.</t> List sub-TLV, a code point of 128 or higher is used.</t>
<t>The Segment List sub-TLV is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY<
<t>The Segment List sub-TLV is OPTIONAL and MAY appear multiple /bcp14> appear multiple
times in the SR Policy encoding. The ordering of Segment List times in the SR Policy encoding. The ordering of Segment List
sub-TLVs does not matter since each sub-TLV encodes a Segment sub-TLVs does not matter since each sub-TLV encodes a Segment
List.</t> List.</t>
<t>The Segment List sub-TLV contains zero or more Segment sub-TLVs <t>The Segment List sub-TLV contains zero or more Segment sub-TLVs
and MAY contain a Weight sub-TLV.</t> and <bcp14>MAY</bcp14> contain a Weight sub-TLV.</t>
<t>The Segment List sub-TLV has the following format: </t>
<t>The Segment List sub-TLV has the following format: <figure <figure>
align="center"> <name>Segment List Sub-TLV</name>
<artwork align="left"><![CDATA[ 0 1 <artwork align="left" name="" type="" alt=""><![CDATA[
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 | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// sub-TLVs // // sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 9: Segment List sub-TLV <t>Where:</t>
<dl spacing="normal">
where:]]></artwork> <dt>Type:</dt><dd>128</dd>
</figure><list style="symbols">
<t>Type: 128.</t>
<t>Length: the total length (not including the Type and Length <dt>Length:</dt><dd>The total length (not including the Type and L ength
fields) of the sub-TLVs encoded within the Segment List sub-TLV fields) of the sub-TLVs encoded within the Segment List sub-TLV
in terms of octets.</t> in terms of octets.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to
zero on transmission and MUST be ignored on receipt.</t>
<t>sub-TLVs currently defined: <list> <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
<t>An optional single Weight sub-TLV.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<t>Zero or more Segment sub-TLVs.</t> <dt>sub-TLVs currently defined: </dt><dd>
</list></t> <ul spacing="normal">
</list></t> <li>
<t>An optional single Weight sub-TLV</t>
</li>
<li>
<t>Zero or more Segment sub-TLVs</t>
</li>
</ul>
</dd>
</dl>
<t>Validation of an explicit path encoded by the Segment List <t>Validation of an explicit path encoded by the Segment List
sub-TLV is beyond the scope of BGP and performed by the SRPM as sub-TLV is beyond the scope of BGP and performed by the SRPM as
described in section 5 of <xref target="RFC9256"/>.</t> described in <xref target="RFC9256" sectionFormat="of" section="5"/>.<
/t>
<section anchor="WEIGHTTLV" title="Weight Sub-TLV"> <section anchor="WEIGHTTLV" numbered="true" toc="default">
<name>Weight Sub-TLV</name>
<t>The Weight sub-TLV specifies the weight associated with a given <t>The Weight sub-TLV specifies the weight associated with a given
segment list. The contents of this sub-TLV are used only by the segment list. The contents of this sub-TLV are used only by the
SRPM as described in section 2.11 of <xref target="RFC9256"/>.</t> SRPM as described in <xref target="RFC9256" sectionFormat="of" secti
on="2.11"/>.</t>
<t>The Weight sub-TLV is OPTIONAL and it MUST NOT appear more than <t>The Weight sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT
</bcp14> appear more than
once inside the Segment List sub-TLV.</t> once inside the Segment List sub-TLV.</t>
<t>The Weight sub-TLV has the following format: </t>
<t>The Weight sub-TLV has the following format: <figure <figure>
align="center"> <name>Weight Sub-TLV</name>
<artwork align="left"><![CDATA[ 0 1 <artwork align="left" name="" type="" alt=""><![CDATA[
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 | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 10: Weight sub-TLV <t>Where:</t>
<dl spacing="normal">
where:]]></artwork>
</figure></t>
<t><list style="symbols"> <dt>Type:</dt><dd>9</dd>
<t>Type: 9.</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e ., not
including Type and Length fields) in terms of octets. The including Type and Length fields) in terms of octets. The
value MUST be 6.</t> value <bcp14>MUST</bcp14> be 6.</dd>
<t>Flags: 1 octet of flags. No flags are defined in this <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in thi
document. The Flags field MUST be set to zero on transmission s
and MUST be ignored on receipt.</t> document. The Flags field <bcp14>MUST</bcp14> be set to zero on
transmission
and <bcp14>MUST</bcp14> be ignored on receipt.
</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp1
to zero on transmission and MUST be ignored on receipt.</t> 4>MUST</bcp14> be set
to zero on transmission and <bcp14>MUST</bcp14> be ignored on re
ceipt.</dd>
<t>Weight: 4 octets an unsigned integer value indicating the <dt>Weight:</dt><dd>4 octets carrying an unsigned integer value
weight associated with a segment list as described in section indicating the
2.11 of <xref target="RFC9256"/>. A weight value of zero is weight associated with a segment list as described in
invalid.</t> <xref target="RFC9256" sectionFormat="of" section="2.11"/>. A we
</list></t> ight value of zero is
</section> invalid.</dd>
<section anchor="SEGMENTTLV" title="Segment Sub-TLVs"> </dl>
</section>
<section anchor="SEGMENTTLV" numbered="true" toc="default">
<name>Segment Sub-TLVs</name>
<t>A Segment sub-TLV describes a single segment in a segment list <t>A Segment sub-TLV describes a single segment in a segment list
(i.e., a single element of the explicit path). One or more Segment (i.e., a single element of the explicit path). One or more Segment
sub-TLVs constitute an explicit path of the SR Policy candidate sub-TLVs constitute an explicit path of the SR Policy CP. The conten
path. The contents of these sub-TLVs are used only by the SRPM as ts of these sub-TLVs are used only by the SRPM as
described in section 4 in <xref target="RFC9256"/>.</t> described in <xref target="RFC9256" sectionFormat="of" section="4"/>
.</t>
<t>The Segment sub-TLVs are OPTIONAL and MAY appear multiple times <t>The Segment sub-TLVs are <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</
bcp14> appear multiple times
in the Segment List sub-TLV.</t> in the Segment List sub-TLV.</t>
<t><xref target="RFC9256" sectionFormat="of" section="4"/> defines s
everal Segment
Types:</t>
<dl>
<t>Section 4 of <xref target="RFC9256"/> defines several Segment <dt>Type A:</dt><dd>SR-MPLS Label</dd>
Types:<figure align="center"> <dt>Type B:</dt><dd>SRv6 SID</dd>
<artwork align="left"><![CDATA[Type A: SR-MPLS Label <dt>Type C:</dt><dd>IPv4 Prefix with optional SR Algorithm</dd>
Type B: SRv6 SID <dt>Type D:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SR-MPLS</d
Type C: IPv4 Prefix with optional SR Algorithm d>
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS <dt>Type E:</dt><dd>IPv4 Prefix with Local Interface ID</dd>
Type E: IPv4 Prefix with Local Interface ID <dt>Type F:</dt><dd>IPv4 Addresses for link endpoints as Local, Remote pair</dd>
Type F: IPv4 Addresses for link endpoints as Local, Remote pair <dt>Type G:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Re
Type G: IPv6 Prefix and Interface ID for link endpoints as Local, mote pair for SR-MPLS</dd>
Remote pair for SR-MPLS <dt>Type H:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for
Type H: IPv6 Addresses for link endpoints as Local, Remote pair SR-MPLS</dd>
for SR-MPLS <dt>Type I:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SRv6</dd>
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 <dt>Type J:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Re
Type J: IPv6 Prefix and Interface ID for link endpoints as Local, mote pair for SRv6</dd>
Remote pair for SRv6 <dt>Type K:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for
Type K: IPv6 Addresses for link endpoints as Local, Remote pair SRv6</dd>
for SRv6 </dl>
]]></artwork>
</figure></t>
<t>The following sub-sections specify the sub-TLVs used for <t>The following subsections specify the sub-TLVs used for
Segment Types A and B. The other segment types are specified in Segment Types A and B. The other segment types are specified in
<xref target="I-D.ietf-idr-bgp-sr-segtypes-ext"/>. As specified in <xref target="RFC9831" format="default"/>. As specified in
section 5.1 of <xref target="RFC9256"/>, a mix of SR-MPLS and SRv6 <xref target="RFC9256" sectionFormat="of" section="5.1"/>, a mix of
SR-MPLS and SRv6
segments make the segment-list invalid.</t> segments make the segment-list invalid.</t>
<section anchor="TYPEA" numbered="true" toc="default">
<section anchor="TYPEA" title="Segment Type A"> <name>Segment Type A</name>
<t>The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The <t>The Type A Segment sub-TLV encodes a single SR-MPLS SID. The
format is as follows and is used to encode MPLS Label fields as format is as follows and is used to encode MPLS Label fields as
specified in <xref target="RFC3032"/> <xref target="RFC5462"/>.: specified in <xref target="RFC3032" format="default"/> and <xref t
<figure align="center"> arget="RFC5462" format="default"/>:
<artwork align="left"><![CDATA[ 0 1 </t>
2 3
<figure>
<name>Type A Segment Sub-TLV</name>
<artwork align="left" 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 11: Type A Segment sub-TLV <t>Where:</t>
<dl spacing="normal">
where:]]></artwork> <dt>Type:</dt><dd>1</dd>
</figure><list style="symbols">
<t>Type: 1.</t>
<t>Length: Specifies the length of the value field (i.e., <dt>Length:</dt><dd>Specifies the length of the value field (i .e.,
not including Type and Length fields) in terms of octets. not including Type and Length fields) in terms of octets.
The value MUST be 6.</t> The value <bcp14>MUST</bcp14> be 6.</dd>
<t>Flags: 1 octet of flags as defined in <xref
target="SEGMENTFLAGS"/>.</t>
<t>RESERVED: 1 octet of reserved bits. This field MUST be <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target
set to zero on transmission and MUST be ignored on ="SEGMENTFLAGS" format="default"/>.</dd>
receipt.</t>
<t>Label: 20 bits of label value.</t> <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bc
p14>MUST</bcp14> be
set to zero on transmission and <bcp14>MUST</bcp14> be ignored
on
receipt.</dd>
<t>TC: 3 bits of traffic class.</t> <dt>Label:</dt><dd>20 bits of label value.</dd>
<dt>TC:</dt><dd>3 bits of traffic class.</dd>
<t>S: 1 bit of bottom-of-stack.</t> <dt>S:</dt><dd>1 bit of bottom-of-stack.</dd>
<t>TTL: 1 octet of TTL.</t> <dt>TTL:</dt><dd>1 octet of TTL.</dd>
</list></t>
<t>The following applies to the Type-1 Segment sub-TLV:<list </dl>
style="symbols"> <t>The following applies to the Type-1 Segment sub-TLV:</t>
<t>The S bit MUST be zero upon transmission and MUST be <ul spacing="normal">
<li>
<t>The S bit <bcp14>MUST</bcp14> be zero upon transmission and
<bcp14>MUST</bcp14> be
ignored upon reception.</t> ignored upon reception.</t>
</li>
<li>
<t>If the originator wants the receiver to choose the TC <t>If the originator wants the receiver to choose the TC
value, it sets the TC field to zero.</t> value, it sets the TC field to zero.</t>
</li>
<li>
<t>If the originator wants the receiver to choose the TTL <t>If the originator wants the receiver to choose the TTL
value, it sets the TTL field to 255.</t> value, it sets the TTL field to 255.</t>
</li>
<li>
<t>If the originator wants to recommend a value for these <t>If the originator wants to recommend a value for these
fields, it puts those values in the TC and/or TTL fields, it puts those values in the TC and/or TTL
fields.</t> fields.</t>
</li>
<t>The receiver MAY override the originator's values for <li>
<t>The receiver <bcp14>MAY</bcp14> override the originator's v
alues for
these fields. This would be determined by local policy at these fields. This would be determined by local policy at
the receiver. One possible policy would be to override the the receiver. One possible policy would be to override the
fields only if the fields have the default values specified fields only if the fields have the default values specified
above.</t> above.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="TYPEB" numbered="true" toc="default">
<name>Segment Type B</name>
<t>The Type B Segment sub-TLV encodes a single SRv6 SID. The
format is as follows: </t>
<section anchor="TYPEB" title="Segment Type B"> <figure>
<t>The Type B Segment Sub-TLV encodes a single SRv6 SID. The <name>Type B Segment Sub-TLV</name>
format is as follows: <figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[ 0 1 0 1 2 3
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 | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (16 octets) // // SRv6 SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Endpoint Behavior and SID Structure // // SRv6 Endpoint Behavior and SID Structure //
// (optional, 8 octets) // // (optional, 8 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 12: Type B Segment sub-TLV <t>Where:</t>
<dl spacing="normal">
where:]]></artwork> <dt>Type:</dt><dd>13</dd>
</figure><list style="symbols">
<t>Type: 13.</t>
<t>Length: Specifies the length of the value field (i.e., <dt>Length:</dt><dd>Specifies the length of the value field (i .e.,
not including Type and Length fields) in terms of octets. not including Type and Length fields) in terms of octets.
The value MUST be 26 when the SRv6 Endpoint Behavior and SID The value <bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Beh
Structure is present else it MUST be 18.</t> avior and SID
Structure is present; else, it <bcp14>MUST</bcp14> be 18.
</dd>
<t>Flags: 1 octet of flags as defined in <xref <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target
target="SEGMENTFLAGS"/>.</t> ="SEGMENTFLAGS" format="default"/>.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bc
set to zero on transmission and MUST be ignored on p14>MUST</bcp14> be
receipt.</t> set to zero on transmission and <bcp14>MUST</bcp14> be ignored
on
receipt.</dd>
<t>SRv6 SID: 16 octets of IPv6 address.</t> <dt>SRv6 SID:</dt><dd>16 octets of IPv6 address.</dd>
<t>SRv6 Endpoint Behavior and SID Structure: Optional, as <dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional
defined in <xref target="BEHAVIORSTRUCT"/>. The SRv6 , as
Endpoint Behavior and SID Structure MUST NOT be included defined in <xref target="BEHAVIORSTRUCT" format="default"/>. T
when the SRv6 SID has not been included.</t> he SRv6
</list></t> Endpoint Behavior and SID Structure <bcp14>MUST NOT</bcp14> be
included
when the SRv6 SID has not been included.</dd>
<t>The Sub-TLV code point 2 defined for the advertisement of </dl>
Segment Type B in the earlier versions of this document has been <t>The sub-TLV code point 2 defined for the advertisement of
Segment Type B in the earlier draft versions of this document has
been
deprecated to avoid backward compatibility issues.</t> deprecated to avoid backward compatibility issues.</t>
</section> </section>
<section anchor="SEGMENTFLAGS" numbered="true" toc="default">
<name>SR Policy Segment Flags</name>
<t>The Segment Type sub-TLVs described above may contain the
following SR Policy Segment Flags in their Flags field. Also
refer to <xref target="IANASIDFLAGS" format="default"/>: </t>
<section anchor="SEGMENTFLAGS" title="SR Policy Segment Flags"> <figure>
<t>The Segment Types sub-TLVs described above may contain the <name>SR Policy Segment Flags</name>
following SR Policy Segment Flags in their "Flags" field. Also <artwork align="left" name="" type="" alt=""><![CDATA[
refer to <xref target="IANASIDFLAGS"/>: <figure align="center">
<artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V| |B| | |V| |B| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
<ul spacing="normal">
Figure 22: SR Policy Segment Flags <li> When the V-Flag is set, it is used by SRPM for "SID
verification" as described in <xref target="RFC9256" sectionFo
rmat="of" section="5.1"/>.</li>
]]></artwork> <li>When the B-Flag is set, it indicates the presence of
</figure> where:<list> the "SRv6 Endpoint Behavior &amp; SID Structure" encoding
<t>V-Flag: This flag, when set, is used by SRPM for "SID specified in <xref target="BEHAVIORSTRUCT" format="default"/>.
verification" as described in Section 5.1 of <xref </li>
target="RFC9256"/>.</t>
<t>B-Flag: This flag, when set, indicates the presence of <li>The unassigned bits in the Flags field <bcp14>MUST</bcp14>
the SRv6 Endpoint Behavior and SID Structure encoding be set to zero
specified in <xref target="BEHAVIORSTRUCT"/>.</t> upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
ipt.</li>
<t>The unassigned bits in the Flag octet MUST be set to zero </ul>
upon transmission and MUST be ignored upon receipt.</t>
</list></t>
<t>The following applies to the Segment Flags:<list <t>The following applies to the Segment Flags:</t>
style="symbols">
<t>V-Flag applies to all Segment Types.</t>
<t>B-Flag applies to Segment Type B. If B-Flag appears with <ul spacing="normal">
Segment Type A it MUST be ignored.</t> <li>
</list></t> V-Flag applies to all Segment Types.
</li>
<li>
B-Flag applies to Segment Type B. If B-Flag appears with
Segment Type A, it <bcp14>MUST</bcp14> be ignored.
</li>
</ul>
</section> </section>
<section anchor="BEHAVIORSTRUCT" numbered="true" toc="default">
<name>SRv6 Endpoint Behavior and SID Structure</name>
<t>The Segment Type sub-TLVs described above <bcp14>MAY</bcp14> co
ntain the
SRv6 Endpoint Behavior and SID Structure <xref target="RFC8986" fo
rmat="default"/> encoding as described below: </t>
<section anchor="BEHAVIORSTRUCT" <figure>
title="SRv6 SID Endpoint Behavior and Structure"> <name>SRv6 Endpoint Behavior and SID Structure</name>
<t>The Segment Types sub-TLVs described above MAY contain the <artwork align="left" name="" type="" alt=""><![CDATA[
SRv6 Endpoint Behavior and SID Structure <xref +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
target="RFC8986"/> encoding as described below: <figure
align="center">
<artwork align="left"><![CDATA[+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved | | Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length | | LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
<dl spacing="normal">
Figure 23: SRv6 SID Endpoint Behavior and Structure <dt>Endpoint Behavior:</dt><dd>2 octets. It carries the SRv6 E
ndpoint
Behavior code point for this SRv6 SID as defined in <xref
target="RFC8986" sectionFormat="of" section="10.2"/>. When
set with the value 0xFFFF (i.e., Opaque), the choice of SRv6
Endpoint Behavior is left to the headend.</dd>
]]></artwork> <dt>Reserved:</dt><dd>2 octets of reserved bits. This field <b
</figure> where:<list> cp14>MUST</bcp14> be
<t>Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint set to zero on transmission and <bcp14>MUST</bcp14> be ignored
Behavior code point for this SRv6 SID as defined in section on
10.2 of <xref target="RFC8986"/>. When set with the value receipt.</dd>
0xFFFF (i.e., Opaque), the choice of SRv6 Endpoint Behavior
is left to the headend.</t>
<t>Reserved: 2 octets of reserved bits. This field MUST be <dt>Locator Block Length:</dt><dd>1 octet. SRv6 SID Locator Bl
set to zero on transmission and MUST be ignored on ock
receipt.</t> length in bits.</dd>
<t>Locator Block Length: 1 octet. SRv6 SID Locator Block <dt>Locator Node Length:</dt><dd>1 octet. SRv6 SID Locator Nod
length in bits.</t> e
length in bits.</dd>
<t>Locator Node Length: 1 octet. SRv6 SID Locator Node <dt>Function Length:</dt><dd>1 octet. SRv6 SID Function length
length in bits.</t> in
bits.</dd>
<t>Function Length: 1 octet. SRv6 SID Function length in <dt>Argument Length:</dt><dd>1 octet. SRv6 SID Arguments lengt
bits.</t> h in
bits.</dd>
<t>Argument Length: 1 octet. SRv6 SID Arguments length in </dl>
bits.</t>
</list></t>
<t>The total of the locator block, locator node, function, and <t>The total of the locator block, locator node, function, and
argument lengths MUST be less than or equal to 128.</t> argument lengths <bcp14>MUST</bcp14> be less than or equal to 128. </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ENLPTLV" numbered="true" toc="default">
<section anchor="ENLPTLV" title="Explicit NULL Label Policy Sub-TLV"> <name>Explicit NULL Label Policy Sub-TLV</name>
<t>To steer an unlabeled IP packet into an SR policy for the MPLS <t>To steer an unlabeled IP packet into an SR Policy for the MPLS
data plane, it is necessary to push a label stack of one or more data plane, it is necessary to push a label stack of one or more
labels on that packet.</t> labels on that packet.</t>
<t>The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate <t>The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate
whether an Explicit NULL Label <xref target="RFC3032"/> must be whether an Explicit NULL Label <xref target="RFC3032" format="default" /> must be
pushed on an unlabeled IP packet before any other labels.</t> pushed on an unlabeled IP packet before any other labels.</t>
<t>If an ENLP sub-TLV is not present, the decision of whether to
<t>If an ENLP Sub-TLV is not present, the decision of whether to
push an Explicit NULL label on a given packet is a matter of local push an Explicit NULL label on a given packet is a matter of local
configuration.</t> configuration.</t>
<t>The ENLP sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT</bc
<t>The ENLP sub-TLV is OPTIONAL and it MUST NOT appear more than p14> appear more than
once in the SR Policy encoding.</t> once in the SR Policy encoding.</t>
<t>The contents of this sub-TLV are used by the SRPM as described in <t>The contents of this sub-TLV are used by the SRPM as described in
section 4.1 of <xref target="RFC9256"/>.</t> <xref target="RFC9256" sectionFormat="of" section="4.1"/>.</t>
<figure align="center"> <figure>
<artwork><![CDATA[0 1 2 <name>ENLP Sub-TLV</name>
3 <artwork name="" type="" align="left" 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENLP | | ENLP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 24: ELNP sub-TLV
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<dl spacing="normal">
<t>Where:<list> <dt>Type:</dt><dd>14</dd>
<t>Type: 14.</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
MUST be 3.</t> <bcp14>MUST</bcp14> be 3.</dd>
<t>Flags: 1 octet of flags. No flags are defined in this <dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
document. The Flags field MUST be set to zero on transmission document. The Flags field <bcp14>MUST</bcp14> be set to zero on tr
and MUST be ignored on receipt.</t> ansmission
and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
zero on transmission and MUST be ignored on receipt.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<t>ENLP (Explicit NULL Label Policy): Indicates whether Explicit <dt>ENLP (Explicit NULL Label Policy):</dt><dd><t>Indicates whethe r Explicit
NULL labels are to be pushed on unlabeled IP packets that are NULL labels are to be pushed on unlabeled IP packets that are
being steered into a given SR policy. The following values have being steered into a given SR Policy. The following values have
been currently defined for this field:<list> been currently defined for this field:</t>
<t>1: Push an IPv4 Explicit NULL label on an unlabeled IPv4
packet, but do not push an IPv6 Explicit NULL label on an
unlabeled IPv6 packet.</t>
<t>2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 <dl spacing="normal" indent="6">
packet, but do not push an IPv4 Explicit NULL label on an
unlabeled IPv4 packet.</t>
<t>3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 <dt>1:</dt><dd>Push an IPv4 Explicit NULL label on an unlabele
packet, and push an IPv6 Explicit NULL label on an unlabeled d IPv4
IPv6 packet.</t> packet but do not push an IPv6 Explicit NULL label on an
unlabeled IPv6 packet.</dd>
<t>4: Do not push an Explicit NULL label.</t> <dt>2:</dt><dd>Push an IPv6 Explicit NULL label on an unlabele
</list>This field can have one of the values as specified in d IPv6
<xref target="IANAENLP"/>. The ENLP unassigned values may be packet but do not push an IPv4 Explicit NULL label on an
used for future extensions. Implementations adhering to this unlabeled IPv4 packet.</dd>
document MUST ignore the ENLP Sub-TLV with unrecognized values
(viz. other than 1 through 4). The behavior signaled in this
Sub-TLV MAY be overridden by local configuration by the network
operator based on their deployment requirements. The section 4.1
of <xref target="RFC9256"/> describes the behavior on the
headend for the handling of the explicit null label.</t>
</list></t>
</section>
<section anchor="POLICYPRIORITY" title="Policy Priority Sub-TLV"> <dt>3:</dt><dd>Push an IPv4 Explicit NULL label on an unlabele
<t>An operator MAY set the Policy Priority sub-TLV to indicate the d IPv4
order in which the SR policies are re-computed upon topological packet and push an IPv6 Explicit NULL label on an unlabeled
change. The contents of this sub-TLV are used by the SRPM as IPv6 packet.</dd>
described in section 2.12 of <xref target="RFC9256"/>.</t>
<t>The Priority sub-TLV is OPTIONAL and it MUST NOT appear more than <dt>4:</dt><dd>Do not push an Explicit NULL label.</dd></dl>
once in the SR Policy encoding.</t>
<t>The Priority sub-TLV has following format:</t> <t>This field can have one of the values as specified in <xref
target="IANAENLP" format="default"/>. The ENLP unassigned values
may be used for future extensions. Implementations adhering to
this document <bcp14>MUST</bcp14> ignore the ENLP sub-TLV with
unrecognized values (viz. other than 1 through 4). The behavior
signaled in this sub-TLV <bcp14>MAY</bcp14> be overridden by
local configuration by the network operator based on their
deployment requirements. <xref target="RFC9256"
sectionFormat="of" section="4.1"/> describes the behavior on the
headend for the handling of the Explicit NULL label.</t></dd>
<figure align="center"> </dl>
<artwork><![CDATA[0 1 2 </section>
3 <section anchor="POLICYPRIORITY" numbered="true" toc="default">
<name>SR Policy Priority Sub-TLV</name>
<t>An operator <bcp14>MAY</bcp14> set the SR Policy Priority sub-TLV t
o indicate the
order in which the SR policies are recomputed upon topological
change. The contents of this sub-TLV are used by the SRPM as
described in <xref target="RFC9256" sectionFormat="of" section="2.12"
/>.</t>
<t>The Priority sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT
</bcp14> appear more than
once in the SR Policy encoding.</t>
<t>The Priority sub-TLV has the following format:</t>
<figure>
<name>Priority Sub-TLV</name>
<artwork name="" type="" align="left" 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Priority | RESERVED | | Type | Length | Priority | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Priority sub-TLV
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<t>Where:<list> <dl spacing="normal">
<t>Type: 15</t>
<t>Length: Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets.The value
MUST be 2.</t>
<t>Priority: a 1-octet value indicating the priority as <dt>Type:</dt><dd>15</dd>
specified in section 2.12 of <xref target="RFC9256"/>.</t>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
zero on transmission and MUST be ignored on receipt.</t> not
</list></t> including Type and Length fields) in terms of octets. The value
</section> <bcp14>MUST</bcp14> be 2.</dd>
<section anchor="POLICYCPNAME" <dt>Priority:</dt><dd>A 1-octet value indicating the priority as
title="Policy Candidate Path Name Sub-TLV"> specified in <xref target="RFC9256" sectionFormat="of" section="2.
<t>An operator MAY set the Policy Candidate Path Name sub-TLV to 12"/>.</dd>
attach a symbolic name to the SR Policy candidate path.</t>
<t>Usage of Policy Candidate Path Name sub-TLV is described in <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
section 2.6 of <xref target="RFC9256"/>.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<t>The Policy Candidate Path Name sub-TLV may exceed 255 bytes in </dl>
</section>
<section anchor="POLICYCPNAME" numbered="true" toc="default">
<name>SR Policy Candidate Path Name Sub-TLV</name>
<t>An operator <bcp14>MAY</bcp14> set the SR Policy Candidate Path Nam
e sub-TLV to
attach a symbolic name to the SR Policy CP.</t>
<t>Usage of the SR Policy Candidate Path Name sub-TLV is described in
<xref target="RFC9256" sectionFormat="of" section="2.6"/>.</t>
<t>The SR Policy Candidate Path Name sub-TLV may exceed 255 bytes in
length due to a long name. A 2-octet length is thus required. length due to a long name. A 2-octet length is thus required.
According to section 2 of <xref target="RFC9012"/>, the sub-TLV type According to <xref target="RFC9012" sectionFormat="of" section="2"/>,
defines the size of the length field. Therefore, for the Policy the sub-TLV type
Candidate Path Name sub-TLV a code point of 128 or higher is defines the size of the Length field. Therefore, for the SR Policy
Candidate Path Name sub-TLV, a code point of 128 or higher is
used.</t> used.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name
<t>It is RECOMMENDED that the size of the symbolic name for the for the
candidate path is limited to 255 bytes. Implementations MAY choose CP be limited to 255 bytes. Implementations <bcp14>MAY</bcp14> choose
to truncate long names to 255 bytes when signaling via BGP.</t> to truncate long names to 255 bytes when signaling via BGP.</t>
<t>The SR Policy Candidate Path Name sub-TLV is <bcp14>OPTIONAL</bcp14
>; it <bcp14>MUST
NOT</bcp14> appear more than once in the SR Policy encoding.</t>
<t>The SR Policy Candidate Path Name sub-TLV has the following format:
</t>
<t>The Policy Candidate Path Name sub-TLV is OPTIONAL and it MUST <figure>
NOT appear more than once in the SR Policy encoding.</t> <name>SR Policy Candidate Path Name Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>The Policy Candidate Path Name sub-TLV has following format:</t> 0 1 2 3
<figure align="center">
<artwork><![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 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 | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Policy Candidate Path Name // // SR Policy Candidate Path Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Policy Candidate Path Name sub-TLV
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<dl spacing="normal">
<t>Where:<list> <dt>Type:</dt><dd>129</dd>
<t>Type: 129.</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
is variable.</t> is variable.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
zero on transmission and MUST be ignored on receipt.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<t>Policy Candidate Path Name: Symbolic name for the SR Policy <dt>SR Policy Candidate Path Name:</dt><dd>Symbolic name for the S
candidate path without a NULL terminator with encoding as R Policy
specified in section 2.6 of <xref target="RFC9256"/>.</t> CP without a NULL terminator with encoding as
</list></t> specified in <xref target="RFC9256" sectionFormat="of" section="2.
</section> 6"/>.</dd>
<section anchor="POLICYNAME" title="Policy Name Sub-TLV"> </dl>
<t>An operator MAY set the Policy Name sub-TLV to associate a </section>
symbolic name with the SR Policy for which the candidate path is <section anchor="POLICYNAME" numbered="true" toc="default">
<name>SR Policy Name Sub-TLV</name>
<t>An operator <bcp14>MAY</bcp14> set the SR Policy Name sub-TLV to as
sociate a
symbolic name with the SR Policy for which the CP is
being advertised via the SR Policy NLRI.</t> being advertised via the SR Policy NLRI.</t>
<t>Usage of the SR Policy Name sub-TLV is described in <xref target="R
<t>Usage of Policy Name sub-TLV is described in section 2.1 of <xref FC9256" sectionFormat="of" section="2.1"/>.</t>
target="RFC9256"/>.</t> <t>The SR Policy Name sub-TLV may exceed 255 bytes in length due to a
long SR Policy name. A 2-octet length is thus required. According to
<t>The Policy Name sub-TLV may exceed 255 bytes in length due to a <xref target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV
long policy name. A 2-octet length is thus required. According to type defines the size of the Length field. Therefore, for the SR Polic
section 2 of <xref target="RFC9012"/>, the sub-TLV type defines the y
size of the length field. Therefore, for the Policy Name sub-TLV a Name sub-TLV, a code point of 128 or higher is used.</t>
code point of 128 or higher is used.</t> <t>It is <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name
for the SR
<t>It is RECOMMENDED that the size of the symbolic name for the SR Policy be limited to 255 bytes. Implementations <bcp14>MAY</bcp14> cho
Policy is limited to 255 bytes. Implementations MAY choose to ose to
truncate long names to 255 bytes when signaling via BGP.</t> truncate long names to 255 bytes when signaling via BGP.</t>
<t>The SR Policy Name sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MU
<t>The Policy Name sub-TLV is OPTIONAL and it MUST NOT appear more ST NOT</bcp14> appear more
than once in the SR Policy encoding.</t> than once in the SR Policy encoding.</t>
<t>The SR Policy Name sub-TLV has the following format:</t>
<t>The Policy Name sub-TLV has following format:</t> <figure>
<name>SR Policy Name Sub-TLV</name>
<figure align="center"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[0 1 2 0 1 2 3
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 | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Policy Name // // SR Policy Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Policy Name sub-TLV
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<dl spacing="normal">
<t>Where:<list> <dt>Type:</dt><dd>130</dd>
<t>Type: 130</t>
<t>Length: Specifies the length of the value field (i.e., not <dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
including Type and Length fields) in terms of octets. The value including Type and Length fields) in terms of octets. The value
is variable.</t> is variable.</dd>
<t>RESERVED: 1 octet of reserved bits. This field MUST be set to <dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
zero on transmission and MUST be ignored on receipt.</t> MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
.</dd>
<dt>SR Policy Name:</dt><dd>Symbolic name for the SR Policy withou
t a NULL
terminator with encoding as specified in <xref target="RFC9256" se
ctionFormat="of" section="2.1"/>.</dd>
</dl>
<t>Policy Name: Symbolic name for the SR Policy without a NULL
terminator with encoding as specified in section 2.1 of <xref
target="RFC9256"/>.</t>
</list></t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="EXTCOLOR" numbered="true" toc="default">
<section anchor="EXTCOLOR" title="Color Extended Community"> <name>Color Extended Community</name>
<t>The Color Extended Community <xref target="RFC9012"/> is used to <t>The Color Extended Community <xref target="RFC9012" format="default"/>
is used to
steer traffic corresponding to BGP routes into an SR Policy with steer traffic corresponding to BGP routes into an SR Policy with
matching color value. The Color Extended Community MAY be carried in any matching Color value. The Color Extended Community <bcp14>MAY</bcp14> be c arried in any
BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128
(VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70
(Ethernet VPN, usually known as EVPN). Use of the Color Extended (Ethernet VPN, usually known as EVPN). Use of the Color Extended
Community in BGP UPDATE messages of other AFI/SAFIs is not covered by Community in BGP UPDATE messages of other AFI/SAFIs is not covered by
<xref target="RFC9012"/> and is hence outside the scope of this document <xref target="RFC9012" format="default"/>; hence, it is outside the scope of this document
as well.</t> as well.</t>
<t>Two bits from the Flags field of the Color Extended Community are <t>Two bits from the Flags field of the Color Extended Community are
used as follows to support the requirements of Color-Only steering as used as follows to support the requirements of Color-Only steering as
specified in Section 8.8 of <xref target="RFC9256"/>: <figure specified in <xref target="RFC9256" sectionFormat="of" section="8.8"/>: </
align="center"> t>
<artwork><![CDATA[ 1
<figure>
<name>Color Extended Community Flags</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C O| Unassigned | |C O| Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 28: Color Extended Community Flags <t>The C and O bits together form the Color-Only Type field, which
indicates the various matching criteria between the BGP Next Hop (NH) and
the SR Policy
Endpoint in addition to the matching of the Color value. The following typ
es
are defined:</t>
<dl spacing="normal">
]]></artwork> <dt>Type 0 (bits 00):</dt><dd>Specific Endpoint Match. Request a match
</figure>The CO bits together form the Color-Only Type field which for the
indicates the various matching criteria between BGP NH and SR Policy Endpoint that is the BGP NH.</dd>
endpoint in addition to the matching of the color value. Following types
are defined:<list style="symbols">
<t>Type 0 (bits 00): Specific Endpoint Match: Request match for the
endpoint that is the BGP NH</t>
<t>Type 1 (bits 01): Specific or Null Endpoint Match: Request match <dt>Type 1 (bits 01):</dt><dd>Specific or Null Endpoint Match. Request
for either the endpoint that is the BGP NH or a null endpoint (e.g., a match
like a default gateway)</t> for either the Endpoint that is the BGP NH or a null Endpoint (e.g.,
a default gateway).</dd>
<t>Type 2 (bits 10): Specific, Null, or Any Endpoint Match: Request <dt>Type 2 (bits 10):</dt><dd>Specific, Null, or Any Endpoint Match. R
match for either the endpoint that is the BGP NH or with a null or equest
any endpoint</t> a match for either the Endpoint that is the BGP NH or a null or
any Endpoint.</dd>
<t>Type 3 (bits 11): reserved for future use and SHOULD NOT be used. <dt>Type 3 (bits 11):</dt><dd>Reserved for future use and <bcp14>SHOUL
Upon reception, an implementation MUST treat it like Type 0.</t> D NOT</bcp14> be used.
</list></t> Upon reception, an implementation <bcp14>MUST</bcp14> treat it like Ty
pe 0.</dd>
</dl>
<t>The details of the SR Policy steering mechanisms based on these <t>The details of the SR Policy steering mechanisms based on these
Color-Only types are specified in section 8.8 of <xref Color-Only types are specified in <xref target="RFC9256" sectionFormat="of
target="RFC9256"/>.</t> " section="8.8"/>.</t>
<t>One or more Color Extended Communities <bcp14>MAY</bcp14> be
<t>One or more Color Extended Communities MAY be associated with a BGP associated with a BGP route update. Sections <xref target="RFC9256"
route update. Sections 8.4.1, 8.5.1, and 8.8.2 of <xref sectionFormat="bare" section="8.4.1"/>, <xref target="RFC9256"
target="RFC9256"/> specify the steering behaviors over SR Policies when sectionFormat="bare" section="8.5.1"/>, and <xref target="RFC9256"
sectionFormat="bare" section="8.8.2"/> of <xref target="RFC9256"
format="default"/> specify the steering behaviors over SR Policies when
multiple Color Extended Communities are associated with a BGP route.</t> multiple Color Extended Communities are associated with a BGP route.</t>
</section> </section>
<section anchor="OPERATIONS" numbered="true" toc="default">
<section anchor="OPERATIONS" title="SR Policy Operations"> <name>SR Policy Operations</name>
<t>As mentioned in <xref target="INTRO"/>, BGP is not the actual <t>As mentioned in <xref target="INTRO" format="default"/>, BGP is not the
actual
consumer of an SR Policy NLRI. BGP is in charge of the origination and consumer of an SR Policy NLRI. BGP is in charge of the origination and
propagation of the SR Policy NLRI but its installation and use are propagation of the SR Policy NLRI, but its installation and use are
outside the scope of BGP. The details of SR Policy installation and use outside the scope of BGP. The details of SR Policy installation and use
are specified in <xref target="RFC9256"/>.</t> are specified in <xref target="RFC9256" format="default"/>.</t>
<section anchor="CONFIG" numbered="true" toc="default">
<section anchor="CONFIG" title="Advertisement of SR Policies"> <name>Advertisement of SR Policies</name>
<t>Typically, but not limited to, an SR Policy is computed by a <t>Typically, but not limited to, an SR Policy is computed by a
controller or a path computation engine (PCE) and originated by a BGP controller or a Path Computation Engine (PCE) and originated by a BGP
speaker on its behalf.</t> speaker on its behalf.</t>
<t>Multiple SR Policy NLRIs may be present with the same &lt;Color,
<t>Multiple SR Policy NLRIs may be present with the same &lt;color, Endpoint&gt; tuple but with different distinguishers when these SR
endpoint&gt; tuple but with different distinguishers when these SR
policies are intended for different headends.</t> policies are intended for different headends.</t>
<t>The distinguisher of each SR Policy NLRI prevents undesired BGP <t>The distinguisher of each SR Policy NLRI prevents undesired BGP
route selection among these SR Policy NLRIs and allows their route selection among these SR Policy NLRIs and allows their
propagation across route reflectors <xref target="RFC4456"/>.</t> propagation across RRs <xref target="RFC4456" format="default"/>.</t>
<t>Moreover, one or more route targets <bcp14>SHOULD</bcp14> be attached
<t>Moreover, one or more route targets SHOULD be attached to the to the
advertisement, where each route target identifies one or more intended advertisement, where each route target identifies one or more intended
headends for the advertised SR Policy update.</t> headends for the advertised SR Policy update.</t>
<t>If no route target is attached to the SR Policy NLRI, then it is <t>If no route target is attached to the SR Policy NLRI, then it is
assumed that the originator sends the SR Policy update directly (e.g., assumed that the originator sends the SR Policy update directly (e.g.,
through a BGP session) to the intended receiver. In such a case, the through a BGP session) to the intended receiver. In such a case, the
NO_ADVERTISE community <xref target="RFC1997"/> MUST be attached to NO_ADVERTISE community <xref target="RFC1997" format="default"/> <bcp14>
the SR Policy update (see further details in <xref MUST</bcp14> be attached to
target="PROPAGATE"/>).</t> the SR Policy update (see further details in <xref target="PROPAGATE" fo
rmat="default"/>).</t>
</section> </section>
<section anchor="RECEPT" numbered="true" toc="default">
<section anchor="RECEPT" title="Reception of an SR Policy NLRI"> <name>Reception of an SR Policy NLRI</name>
<t>On reception of an SR Policy NLRI, a BGP speaker first determines <t>On reception of an SR Policy NLRI, a BGP speaker first determines
if it is valid as described in <xref target="ACCEPT"/> and then if it is valid as described in <xref target="ACCEPT"
performs the decision process for selection of the best route (Section format="default"/>; then, the BGP speaker performs the decision process
9.1 of <xref target="RFC4271"/>). The key difference from the base BGP for
decision process is that BGP does not download the selected best selection of the best route (<xref target="RFC4271" sectionFormat="of"
routes of SR Policy SAFI into the forwarding and instead considers section="9.1"/>). The key difference from the base BGP decision
them "usable" for passing on to the SRPM for further processing as process is that BGP does not download the selected best routes of the SR
described in <xref target="USABLE"/>. The selected best route is Policy SAFI into the forwarding; instead, it considers them "usable"
"propagated" (Section 9.1.3 of <xref target="RFC4271"/>) as described for passing on to the SRPM for further processing as described in
in <xref target="PROPAGATE"/> irrespective of its "usability" by the <xref target="USABLE" format="default"/>. The selected best route is
local router.</t> "propagated" (<xref target="RFC4271" sectionFormat="of"
section="9.1.3"/>) as described in <xref target="PROPAGATE"
<section anchor="ACCEPT" title="Validation of an SR Policy NLRI"> format="default"/>, irrespective of its "usability" by the local
<t>When a BGP speaker receives an SR Policy NLRI from a neighbor it router.</t>
MUST first perform validation based on the following rules in <section anchor="ACCEPT" numbered="true" toc="default">
addition to the validation described in <xref target="ERROR"/>: <name>Validation of an SR Policy NLRI</name>
<list style="symbols"> <t>When a BGP speaker receives an SR Policy NLRI from a neighbor, it
<t>The SR Policy NLRI MUST include a distinguisher, color, and <bcp14>MUST</bcp14> first perform validation based on the following ru
endpoint field which implies that the length of the NLRI MUST be les in
addition to the validation described in <xref target="ERROR" format="d
efault"/>:
</t>
<ul spacing="normal">
<li>
<t>The SR Policy NLRI <bcp14>MUST</bcp14> include a distinguisher,
Color, and
Endpoint field that implies that the length of the NLRI <bcp14>MUS
T</bcp14> be
either 12 or 24 octets (depending on the address family of the either 12 or 24 octets (depending on the address family of the
endpoint).</t> Endpoint).</t>
</li>
<t>The SR Policy update MUST have either the NO_ADVERTISE <li>
community or at least one route target extended community in <t>The SR Policy update <bcp14>MUST</bcp14> have either the NO_ADV
IPv4-address format or both. If a router supporting this ERTISE
specification receives an SR Policy update with no route target community, at least one Route Target extended community in
IPv4-address format, or both. If a router supporting this
specification receives an SR Policy update with no Route Target
extended communities and no NO_ADVERTISE community, the update extended communities and no NO_ADVERTISE community, the update
MUST be considered as malformed.</t> <bcp14>MUST</bcp14> be considered to be malformed.</t>
</li>
<t>The Tunnel Encapsulation Attribute MUST be attached to the <li>
BGP Update and MUST have a Tunnel Type TLV set to SR Policy <t>The Tunnel Encapsulation Attribute <bcp14>MUST</bcp14> be attac
(codepoint is 15).</t> hed to the
</list></t> BGP UPDATE message and <bcp14>MUST</bcp14> have a Tunnel Type TLV
set to SR Policy
(code point is 15).</t>
</li>
</ul>
<t>A router that receives an SR Policy update that is not valid <t>A router that receives an SR Policy update that is not valid
according to these criteria MUST treat the update as malformed and according to these criteria <bcp14>MUST</bcp14> treat the update as ma
the SR Policy candidate path MUST NOT be passed to the SRPM.</t> lformed, and
the SR Policy CP <bcp14>MUST NOT</bcp14> be passed to the SRPM.</t>
</section> </section>
<section anchor="USABLE" numbered="true" toc="default">
<section anchor="USABLE" <name>Eligibility for Local Use of an SR Policy NLRI</name>
title="Eligibility for Local Use of an SR Policy NLRI"> <t>An SR Policy NLRI update that does not have a Route Target extended
<t>An SR Policy NLRI update without any route target extended community but does have the NO_ADVERTISE community is considered
community but having the NO_ADVERTISE community is considered
usable.</t> usable.</t>
<t>If one or more route targets are present, then at least one route <t>If one or more route targets are present, then at least one route
target MUST match the BGP Identifier of the receiver for the update target <bcp14>MUST</bcp14> match the BGP Identifier of the receiver fo
to be considered usable. The BGP Identifier is defined in <xref r the update
target="RFC4271"/> as a 4-octet IPv4 address and updated by <xref to be considered usable. The BGP Identifier is defined in <xref target
target="RFC6286"/> as a 4-octet, unsigned, non-zero integer. ="RFC4271" format="default"/> as a 4-octet IPv4 address and is updated by <xref
Therefore, the route target extended community MUST be of the same target="RFC6286" format="default"/> as a 4-octet, unsigned, non-zero integer.
Therefore, the Route Target extended community <bcp14>MUST</bcp14> be
of the same
format.</t> format.</t>
<t>If one or more route targets are present and none matches the <t>If one or more route targets are present, and none matches the
local BGP Identifier, then, while the SR Policy NLRI is valid, it is local BGP Identifier, then, while the SR Policy NLRI is valid, the SR
Policy NLRI is
not usable on the receiver node.</t> not usable on the receiver node.</t>
<t>When the SR Policy tunnel type includes any sub-TLV that is <t>When the SR Policy tunnel type includes any sub-TLV that is
unrecognized or unsupported, the update SHOULD NOT be considered unrecognized or unsupported, the update <bcp14>SHOULD NOT</bcp14> be c
usable. An implementation MAY provide an option for ignoring onsidered
usable. An implementation <bcp14>MAY</bcp14> provide an option for ign
oring
unsupported sub-TLVs.</t> unsupported sub-TLVs.</t>
<t>Once BGP on the receiving node has determined that the SR Policy <t>Once BGP on the receiving node has determined that the SR Policy
NLRI is usable, it passes the SR Policy candidate path to the SRPM. NLRI is usable, it passes the SR Policy CP to the SRPM.
Note that, along with the candidate path details, BGP also passes Note that, along with the CP details, BGP also passes
the originator information for breaking ties in the candidate path the originator information for breaking ties in the CP
selection process as described in section 2.4 of <xref selection process as described in <xref target="RFC9256" sectionFormat
target="RFC9256"/>.</t> ="of" section="2.4"/>.</t>
<t>When an update for an SR Policy NLRI results in its becoming <t>When an update for an SR Policy NLRI results in its becoming
unusable, BGP MUST delete its corresponding SR Policy candidate path unusable, BGP <bcp14>MUST</bcp14> delete its corresponding SR Policy C P
from the SRPM.</t> from the SRPM.</t>
<t>The SRPM applies the rules defined in <xref target="RFC9256"
<t>The SRPM applies the rules defined in section 2 of <xref sectionFormat="of" section="2"/> to determine whether the SR Policy
target="RFC9256"/> to determine whether the SR Policy candidate path CP is valid and to select the active CP for
is valid and to select the active candidate path for a given SR a given SR Policy.</t>
Policy.</t>
</section> </section>
<section anchor="PROPAGATE" numbered="true" toc="default">
<section anchor="PROPAGATE" title="Propagation of an SR Policy"> <name>Propagation of an SR Policy</name>
<t>SR Policy NLRIs that have the NO_ADVERTISE community attached to <t>SR Policy NLRIs that have the NO_ADVERTISE community attached to
them MUST NOT be propagated.</t> them <bcp14>MUST NOT</bcp14> be propagated.</t>
<t>By default, a BGP node receiving an SR Policy NLRI <bcp14>MUST NOT<
<t>By default, a BGP node receiving an SR Policy NLRI MUST NOT /bcp14>
propagate it to any EBGP neighbor. An implementation MAY provide an propagate it to any External BGP (EBGP) neighbor. An implementation <b
cp14>MAY</bcp14> provide an
explicit configuration to override this and enable the propagation explicit configuration to override this and enable the propagation
of valid SR Policy NLRIs to specific EBGP neighbors where the SR of valid SR Policy NLRIs to specific EBGP neighbors where the SR
domain comprises multiple-ASes within a single service provider domain comprises multiple ASes within a single service provider
domain (see <xref target="Security"/> for details).</t> domain (see <xref target="Security" format="default"/> for details).</
t>
<t>A BGP node advertises a received SR Policy NLRI to its IBGP <t>A BGP node advertises a received SR Policy NLRI to its Internal BGP
(IBGP)
neighbors according to normal IBGP propagation rules.</t> neighbors according to normal IBGP propagation rules.</t>
<t>By default, a BGP node receiving an SR Policy NLRI <bcp14>SHOULD NO
<t>By default, a BGP node receiving an SR Policy NLRI SHOULD NOT T</bcp14>
remove route target extended community before propagation. An remove the Route Target extended community before propagation. An
implementation MAY provide support for configuration to filter implementation <bcp14>MAY</bcp14> provide support for configuration to
and/or remove route target extended community before filter
and/or remove the Route Target extended community before
propagation.</t> propagation.</t>
<t>A BGP node <bcp14>MUST NOT</bcp14> alter the SR Policy information
<t>A BGP node MUST NOT alter the SR Policy information carried in carried in
the Tunnel Encapsulation Attribute during propagation.</t> the Tunnel Encapsulation Attribute during propagation.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ERROR" numbered="true" toc="default">
<section anchor="ERROR" title="Error Handling and Fault Management"> <name>Error Handling and Fault Management</name>
<t>This section describes the error handling actions, as described in <t>This section describes the error-handling actions, as described in
<xref target="RFC7606"/>, that are to be performed for the handling of <xref target="RFC7606" format="default"/>, that are to be performed for th
the BGP update messages for BGP SR Policy SAFI.</t> e handling of
the BGP UPDATE messages for the BGP SR Policy SAFI.</t>
<t>A BGP Speaker MUST perform the following syntactic validation of the <t>A BGP speaker <bcp14>MUST</bcp14> perform the following syntactic valid
ation of the
SR Policy NLRI to determine if it is malformed. This includes the SR Policy NLRI to determine if it is malformed. This includes the
validation of the length of each NLRI and the total length of the validation of the length of each NLRI and the total length of the
MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the
validation of the consistency of the NLRI length with the AFI and the validation of the consistency of the NLRI length with the AFI and the
endpoint address as specified in <xref target="SRPOLICYSAFI"/>.</t> endpoint address as specified in <xref target="SRPOLICYSAFI" format="defau
lt"/>.</t>
<t>When the error determined allows for the router to skip the malformed <t>When the error determined allows for the router to skip the malformed
NLRI(s) and continue the processing of the rest of the update message, NLRI(s) and continue the processing of the rest of the BGP UPDATE message,
then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In then it <bcp14>MUST</bcp14> handle such malformed NLRIs as 'treat-as-withd
raw'. In
other cases, where the error in the NLRI encoding results in the other cases, where the error in the NLRI encoding results in the
inability to process the BGP update message (e.g. length related inability to process the BGP UPDATE message (e.g., length-related
encoding errors), then the router SHOULD handle such malformed NLRIs as encoding errors), then the router <bcp14>SHOULD</bcp14> handle such malfor
'AFI/SAFI disable' when other AFI/SAFI besides SR Policy are being med NLRIs as
advertised over the same session. Alternately, the router MUST perform "AFI/SAFI disable" when other AFI/SAFIs besides SR Policy are being
'session reset' when the session is only being used for SR Policy or advertised over the same session. Alternately, the router <bcp14>MUST</bcp
when it 'AFI/SAFI disable' action is not possible.</t> 14> perform
"session reset" when the session is only being used for SR Policy or
when a "AFI/SAFI disable" action is not possible.</t>
<t>The validation of the TLVs/sub-TLVs introduced in this document and <t>The validation of the TLVs/sub-TLVs introduced in this document and
defined in their respective sub-sections of <xref target="SRPOLICYTLV"/> defined in their respective subsections of <xref target="SRPOLICYTLV" form
MUST be performed to determine if they are malformed or invalid. The at="default"/>
<bcp14>MUST</bcp14> be performed to determine if they are malformed or inv
alid. The
validation of the Tunnel Encapsulation Attribute itself and the other validation of the Tunnel Encapsulation Attribute itself and the other
TLVs/sub-TLVs specified in Section 13 of <xref target="RFC9012"/> MUST TLVs/sub-TLVs specified in <xref target="RFC9012" sectionFormat="of" secti on="13"/> <bcp14>MUST</bcp14>
be done as described in that document. In case of any error detected, be done as described in that document. In case of any error detected,
either at the attribute or its TLV/sub-TLV level, the either at the attribute or its TLV/sub-TLV level, the
"treat-as-withdraw" strategy MUST be applied. This is because an SR "treat-as-withdraw" strategy <bcp14>MUST</bcp14> be applied. This is becau
Policy update without a valid Tunnel Encapsulation Attribute (comprising se an SR
Policy update without a valid Tunnel Encapsulation Attribute (comprised
of all valid TLVs/sub-TLVs) is not usable.</t> of all valid TLVs/sub-TLVs) is not usable.</t>
<t>An SR Policy update that is determined not to be valid (and, therefore,
<t>An SR Policy update that is determined to be not valid, and therefore malformed) based on the rules described in <xref target="ACCEPT" format="d
malformed, based on rules described in <xref target="ACCEPT"/> MUST be efault"/> <bcp14>MUST</bcp14> be
handled by the "treat-as-withdraw" strategy.</t> handled by the "treat-as-withdraw" strategy.</t>
<t>The validation of the individual fields of the TLVs/sub-TLVs defined <t>The validation of the individual fields of the TLVs/sub-TLVs defined
in <xref target="SRPOLICYTLV"/> are beyond the scope of BGP as they are in <xref target="SRPOLICYTLV" format="default"/> are beyond the scope of B GP as they are
handled by the SRPM as described in the individual TLV/sub-TLV handled by the SRPM as described in the individual TLV/sub-TLV
sub-sections. A BGP implementation MUST NOT perform semantic subsections. A BGP implementation <bcp14>MUST NOT</bcp14> perform semantic
verification of such fields nor consider the SR Policy update to be verification of such fields nor consider the SR Policy update to be
invalid or not usable based on such validation.</t> invalid or not usable based on such validation.</t>
<t>An implementation <bcp14>SHOULD</bcp14> log any errors found during the
<t>An implementation SHOULD log any errors found during the above above
validation for further analysis.</t> validation for further analysis.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations">
<t>This document uses code point allocations from the following existing <t>This document uses code point allocations from the following existing
registries:<list style="symbols"> registries in the "Subsequent Address Family Identifiers (SAFI) Parameters
<t>Subsequent Address Family Identifiers (SAFI) Parameters " registry group:</t>
registry</t> <ul spacing="normal">
<li>
<t>BGP Tunnel Encapsulation Attribute Tunnel Types registry under <t>The "SAFI Values" registry</t>
the BGP Tunnel Encapsulation registry</t> </li>
</ul>
<t>BGP Tunnel Encapsulation Attribute sub-TLVs registry under the <t>This document uses code point allocations from the following existing r
BGP Tunnel Encapsulation registry</t> egistries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry g
roup:</t>
<t>Color Extended Community Flags registry under the BGP Tunnel <ul spacing="normal">
Encapsulation registry</t> <li>
</list></t> <t>The "BGP Tunnel Encapsulation Attribute Tunnel Types" registry</t>
</li>
<t>This document also requests the creation of the following new <li>
registries: <list style="symbols"> <t>The "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry</t>
<t>SR Policy Segment List Sub-TLVs under the BGP Tunnel </li>
Encapsulation registry</t> <li>
<t>The "Color Extended Community Flags" registry</t>
<t>SR Policy Binding SID Flags under the BGP Tunnel Encapsulation </li>
registry</t> </ul>
<t>This document creates the following new
<t>SR Policy SRv6 Binding SID Flags under the BGP Tunnel registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" reg
Encapsulation registry</t> istry group: </t>
<ul spacing="normal">
<t>SR Policy Segment Flags under the BGP Tunnel Encapsulation <li>
registry</t> <t>The "SR Policy Segment List Sub-TLVs" registry</t>
</li>
<t>Color Extended Community Color-Only Types registry under the BGP <li>
Tunnel Encapsulation registry</t> <t>The "SR Policy Binding SID Flags" registry</t>
</li>
<t>SR Policy ENLP Values under the Segment Routing registry</t> <li>
</list></t> <t>The "SR Policy SRv6 Binding SID Flags" registry</t>
</li>
<li>
<t>The "SR Policy Segment Flags" registry</t>
</li>
<li>
<t>The "Color Extended Community Color-Only Types" registry</t>
</li></ul>
<t>This document creates the following new registry in the "Segment Routin
g" registry group:</t>
<ul spacing="normal">
<li>
<t>The "SR Policy ENLP Values" registry</t>
</li>
</ul>
<section anchor="IANASAFI" <section anchor="IANASAFI" numbered="true" toc="default">
title="Subsequent Address Family Identifiers (SAFI) Parameters"> <name>Subsequent Address Family Identifiers (SAFI) Parameters</name>
<t>This document introduces a SAFI in the registry "Subsequent Address <t>This document registers a SAFI code point in the "SAFI Values" regist
Family Identifiers (SAFI) Parameters" that has been assigned a code ry of the "Subsequent Address
point by IANA. The entry needs to be updated as follows:<figure Family Identifiers (SAFI) Parameters" registry group as follows:</t>
align="center">
<artwork align="center"><![CDATA[Code Point Description
Reference
73 SR Policy SAFI This document
Table 1: BGP SAFI Code Point <table>
<name>BGP SAFI Code Point</name>
<thead>
<tr>
<th>Value</th><th>Description</th><th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>73</td><td>SR Policy SAFI</td><td>RFC 9830</td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANATUNNEL" numbered="true" toc="default">
<name>BGP Tunnel Encapsulation Attribute Tunnel Types</name>
<t>This document registers a Tunnel Type code point in the "BGP Tunnel
Encapsulation Attribute Tunnel Types" registry under the "Border Gateway
Protocol (BGP) Tunnel Encapsulation" registry group.</t>
<section anchor="IANATUNNEL" <table>
title="BGP Tunnel Encapsulation Attribute Tunnel Types"> <name>Tunnel Type Code Point</name>
<t>This document introduces a Tunnel-Type in the registry "BGP Tunnel <thead>
Encapsulation Attribute Tunnel Types" that has been assigned a <tr>
codepoint by IANA. The entry needs to be updated as follows:<figure <th>Value</th><th>Description</th><th>Reference</th>
align="center"> </tr>
<artwork align="center"><![CDATA[Code Point Description </thead>
Reference <tbody>
15 SR Policy This document <tr>
<td>15</td><td>SR Policy</td><td>RFC 9830</td>
Table 2: Tunnel Type Code Point </tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANATUNNSUBTLV" <section anchor="IANATUNNSUBTLV" numbered="true" toc="default">
title="BGP Tunnel Encapsulation Attribute sub-TLVs"> <name>BGP Tunnel Encapsulation Attribute Sub-TLVs</name>
<t>This document defines sub-TLVs in the registry "BGP Tunnel <t>This document defines sub-TLVs in the "BGP Tunnel
Encapsulation Attribute sub-TLVs" that have been assigned code points Encapsulation Attribute Sub-TLVs" registry under the "Border Gateway Pro
by IANA as follows via the early allocation process which needs to be tocol (BGP) Tunnel Encapsulation" registry group.</t>
made permanent:<figure align="center">
<artwork align="center"><![CDATA[Code Point Description
Reference
12 Preference sub-TLV This document
13 Binding SID sub-TLV This document
14 ENLP sub-TLV This document
15 Priority sub-TLV This document
20 SRv6 Binding SID sub-TLV This document
128 Segment List sub-TLV This document
129 Policy Candidate Path Name sub-TLV This document
130 Policy Name sub-TLV This document
Table 3: BGP Tunnel Encapsulation Attribute Code Points <table>
<name>BGP Tunnel Encapsulation Attribute Sub-TLV Code Points</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
<th>Change Controller</th>
</tr>
</thead>
<tbody>
<tr>
<td>12</td>
<td>Preference sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>13</td>
<td>Binding SID sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>14</td>
<td>ENLP sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>15</td>
<td>Priority sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>20</td>
<td>SRv6 Binding SID sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>128</td>
<td>Segment List sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>129</td>
<td>SR Policy Candidate Path Name sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
<tr>
<td>130</td>
<td>SR Policy Name sub-TLV</td>
<td>RFC 9830</td>
<td>IETF</td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANAEXTCOM" numbered="true" toc="default">
<name>Color Extended Community Flags</name>
<t>This document defines the use of 2 bits in the
"Color Extended Community Flags" registry under the "Border Gateway Prot
ocol (BGP) Tunnel Encapsulation"
registry group.</t>
<section anchor="IANAEXTCOM" title="Color Extended Community Flags"> <table>
<t>This document defines the use of 2 bits in the registry called <name>Color Extended Community Flag Bits</name>
"Color Extended Community Flags" under the "BGP Tunnel Encapsulation" <thead>
registry that have been assigned by IANA via the early allocation <tr><th>Bit Position</th><th>Description</th><th>Reference</th></tr>
process to form the Color-Only Types field which needs to be made </thead>
permanent:<figure align="center"> <tbody>
<artwork align="center"><![CDATA[ Bit <tr><td>0-1</td><td>Color-only Types Field</td><td>RFC 9830</td></tr>
Position Description Reference </tbody>
0-1 Color-only Types Field This document </table>
Table 4: Color Extended Community Flag Bits
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANASIDLIST" numbered="true" toc="default">
<name>SR Policy Segment List Sub-TLVs</name>
<t>This document creates a new registry called "SR
Policy Segment List Sub-TLVs" under the "Border Gateway Protocol (BGP) T
unnel Encapsulation"
registry group. The registration policy of this registry is "IETF Review
"
(see <xref target="RFC8126" format="default"/>).</t>
<t>The following initial sub-TLV code points are assigned by this
document:</t>
<section anchor="IANASIDLIST" title="SR Policy Segment List Sub-TLVs"> <table>
<t>This document requests the creation of a new registry called "SR <name>SR Policy Segment List Sub-TLV Code Points</name>
Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation" <thead>
registry. The allocation policy of this registry is "IETF Review" <tr>
according to <xref target="RFC8126"/>.</t> <th>Value</th>
<th>Description</th>
<t>Following initial Sub-TLV codepoints are assigned by this <th>Reference</th>
document:<figure align="center"> </tr>
<artwork align="center"><![CDATA[Value Description </thead>
Reference <tbody>
0 Reserved This document <tr>
1 Segment Type A sub-TLV This document <td>0</td>
2 Deprecated This document <td>Reserved</td>
3-8 Unassigned <td>RFC 9830</td>
9 Weight sub-TLV This document </tr>
10 Deprecated This document <tr>
11 Deprecated This document <td>1</td>
12 Deprecated This document <td>Type A Segment sub-TLV</td>
13 Segment Type B sub-TLV This document <td>RFC 9830</td>
14-255 Unassigned </tr>
<tr>
Table 5: SR Policy Segment List Code Points <td>2</td>
<td>Deprecated</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>3-8</td>
<td colspan="2">Unassigned</td>
</tr>
<tr>
<td>9</td>
<td>Weight sub-TLV</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>10</td>
<td>Deprecated</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>11</td>
<td>Deprecated</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>12</td>
<td>Deprecated</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>13</td>
<td>Type B Segment sub-TLV</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>14-255</td>
<td colspan="2">Unassigned</td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANABSIDFLAGS" numbered="true" toc="default">
<name>SR Policy Binding SID Flags</name>
<t>This document creates a new registry called "SR
Policy Binding SID Flags" under the "Border Gateway Protocol (BGP) Tunne
l Encapsulation"
registry group. The registration policy of this registry is "Standards A
ction"
(see <xref target="RFC8126" format="default"/>).</t>
<t>The following flags are defined:</t>
<section anchor="IANABSIDFLAGS" title="SR Policy Binding SID Flags"> <table>
<t>This document requests the creation of a new registry called "SR <name>SR Policy Binding SID Flags</name>
Policy Binding SID Flags" under the "BGP Tunnel Encapsulation" <thead>
registry. The allocation policy of this registry is "Standards Action" <tr>
according to <xref target="RFC8126"/>.</t> <th>Bit</th>
<th>Description</th>
<t>The following flags are defined:<figure align="center"> <th>Reference</th>
<artwork align="center"><![CDATA[ Bit Description </tr>
Reference </thead>
0 Specified-BSID-Only Flag (S-Flag) This document <tbody>
1 Drop Upon Invalid Flag (I-Flag) This document <tr>
2-7 Unassigned <td>0</td>
<td>Specified-BSID-Only Flag (S-Flag)</td>
Table 6: SR Policy Binding SID Flags <td>RFC 9830</td>
</tr>
<tr>
<td>1</td>
<td>Drop-Upon-Invalid Flag (I-Flag)</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>2-7</td>
<td colspan="2">Unassigned</td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANASRV6BSIDFLAGS" numbered="true" toc="default">
<name>SR Policy SRv6 Binding SID Flags</name>
<t>This document creates a new registry called "SR
Policy SRv6 Binding SID Flags" under the "Border Gateway Protocol (BGP)
Tunnel Encapsulation"
registry group. The registration policy of this registry is "Standards A
ction"
(see <xref target="RFC8126" format="default"/>).</t>
<t>The following flags are defined:</t>
<section anchor="IANASRV6BSIDFLAGS" <table>
title="SR Policy SRv6 Binding SID Flags"> <name>SR Policy SRv6 Binding SID Flags</name>
<t>This document requests the creation of a new registry called "SR <thead>
Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation" <tr>
registry. The allocation policy of this registry is "Standards Action" <th>Bit</th>
according to <xref target="RFC8126"/>.</t> <th>Description</th>
<th>Reference</th>
<t>The following flags are defined:<figure align="center"> </tr>
<artwork align="center"><![CDATA[ Bit Description </thead>
Reference <tbody>
0 Specified-BSID-Only Flag (S-Flag) This document <tr>
1 Drop Upon Invalid Flag (I-Flag) This document <td>0</td>
2 SRv6 Endpoint Behavior & <td>Specified-BSID-Only Flag (S-Flag)</td>
SID Structure Flag (B-Flag) This document <td>RFC 9830</td>
3-7 Unassigned </tr>
<tr>
<td>1</td>
<td>Drop-Upon-Invalid Flag (I-Flag)</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>2</td>
<td>SRv6 Endpoint Behavior &amp; SID Structure Flag (B-Flag)</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>3-7</td>
<td colspan="2">Unassigned</td>
</tr>
</tbody>
</table>
Table 7: SR Policy SRv6 Binding SID Flags
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANASIDFLAGS" numbered="true" toc="default">
<name>SR Policy Segment Flags</name>
<t>This document creates a new registry called "SR
Policy Segment Flags" under the "Border Gateway Protocol (BGP) Tunnel En
capsulation" registry group.
The registration policy of this registry is "IETF Review" (see <xref tar
get="RFC8126" format="default"/>).</t>
<t>The following flags are defined:</t>
<section anchor="IANASIDFLAGS" title="SR Policy Segment Flags"> <table>
<t>This document requests the creation of a new registry called "SR <name>SR Policy Segment Flags</name>
Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry. <thead>
The allocation policy of this registry is "IETF Review" according to <tr>
<xref target="RFC8126"/>.</t> <th>Bit</th>
<th>Description</th>
<t>The following flags are defined:<figure align="center"> <th>Reference</th>
<artwork align="center"><![CDATA[ Bit Description </tr>
Reference </thead>
0 Segment Verification Flag (V-Flag) This document <tbody>
1-2 Unassigned <tr>
3 SRv6 Endpoint Behavior & <td>0</td>
SID Structure Flag (B-Flag) This document <td>Segment Verification Flag (V-Flag)</td>
4-7 Unassigned <td>RFC 9830</td>
</tr>
<tr>
<td>1-2</td>
<td colspan="2">Unassigned</td>
</tr>
<tr>
<td>3</td>
<td>SRv6 Endpoint Behavior &amp; SID Structure Flag (B-Flag)</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>4-7</td>
<td colspan="2">Unassigned</td>
</tr>
</tbody>
</table>
Table 8: SR Policy Segment Flags
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANAEXTCOMCOFIELD" numbered="true" toc="default">
<section anchor="IANAEXTCOMCOFIELD" <name>Color Extended Community Color-Only Types</name>
title="Color Extended Community Color-Only Types"> <t>This document creates a new registry called "Color
<t>This document requests the creation of a new registry called "Color Extended Community Color-Only Types" under the "Border Gateway Protocol
Extended Community Color-Only Types" under the "BGP Tunnel (BGP) Tunnel
Encapsulation" registry for assignment of codepoints (values 0 through Encapsulation" registry group for assignment of code points (values 0 th
rough
3) in the Color-Only Type field of the Color Extended Community Flags 3) in the Color-Only Type field of the Color Extended Community Flags
field. The allocation policy of this registry is "Standards Action" field. The registration policy of this registry is "Standards Action"
according to <xref target="RFC8126"/>.</t> (see <xref target="RFC8126" format="default"/>).</t>
<t>The following types are defined:</t>
<t>The following types are defined:<figure align="center"> <table>
<artwork align="center"><![CDATA[ Type Description <name>Color Extended Community Color-Only Types</name>
Reference <thead>
0 Specific Endpoint Match This document <tr>
1 Specific or Null Endpoint Match This document <th>Type</th>
2 Specific, Null, or Any Endpoint Match This document <th>Description</th>
3 Unassigned This document <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Specific Endpoint Match</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>1</td>
<td>Specific or Null Endpoint Match</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>2</td>
<td>Specific, Null, or Any Endpoint Match</td>
<td>RFC 9830</td>
</tr>
<tr>
<td>3</td>
<td>Unassigned</td>
<td>RFC 9830</td>
</tr>
</tbody>
</table>
Table 9: Color Extended Community Color-Only Types
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANAENLP" numbered="true" toc="default">
<name>SR Policy ENLP Values</name>
<t>IANA will maintain a new registry under the
"Segment Routing" registry group with the registration policy of
"Standards Action" (see <xref target="RFC8126" format="default"/>). The
new registry is
called "SR Policy ENLP Values" and contains the code points allocated
to the ENLP field defined in <xref target="ENLPTLV" format="default"/>.
The registry
contains the following code points:</t>
<section anchor="IANAENLP" title="SR Policy ENLP Values"> <table>
<t>Note to IANA (RFC editor to remove this before publication): The <name>SR Policy ENLP Values</name>
new registry creation request below is also present in the <thead>
draft-ietf-pce-segment-routing-policy-cp. IANA is requested to process <tr>
the registry creation via the first of these two documents to reach <th>Code Point</th>
publication stage and the authors of the other document would update <th>Description</th>
the IANA considerations suitably.</t> <th>Reference</th>
</tr>
<t>This document requests IANA to maintain a new registry under </thead>
"Segment Routing" registry group with the allocation policy of <tbody>
"Standards Action" <xref target="RFC8126"/>. The new registry is <tr>
called "SR Policy ENLP Values" and contains the codepoints allocated <td>0</td>
to the "ENLP" field defined in <xref target="ENLPTLV"/>. The registry <td>Reserved</td>
contains the following codepoints, with initial values, to be assigned <td>RFC 9830</td>
by IANA with the reference set to this document:<figure> </tr>
<artwork><![CDATA[+-------+-----------------------------------+----- <tr>
----------+ <td>1</td>
| Code | | | <td>Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do no
| Point | Description | Reference | t push an IPv6 Explicit NULL label on an unlabeled IPv6 packet</td>
+-------+-----------------------------------+---------------+ <td>RFC 9830</td>
| 0 | Reserved (not to be used) | This document | </tr>
| 1 | Push an IPv4 Explicit NULL label | This document | <tr>
| | on an unlabeled IPv4 packet, but | | <td>2</td>
| | do not push an IPv6 Explicit NULL | | <td>Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do no
| | label on an unlabeled IPv6 packet | | t push an IPv4 Explicit NULL label on an unlabeled IPv4 packet</td>
| 2 | Push an IPv6 Explicit NULL label | This document | <td>RFC 9830</td>
| | on an unlabeled IPv6 packet, but | | </tr>
| | do not push an IPv4 Explicit NULL | | <tr>
| | label on an unlabeled IPv4 packet | | <td>3</td>
| 3 | Push an IPv6 Explicit NULL label | This document | <td>Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet and push
| | on an unlabeled IPv6 packet, and | | an IPv4 Explicit NULL label on an unlabeled IPv4 packet</td>
| | push an IPv4 Explicit NULL label | | <td>RFC 9830</td>
| | on an unlabeled IPv4 packet | | </tr>
| 4 | Do not push an Explicit NULL | This document | <tr>
| | label | | <td>4</td>
| 5-255 | Unassigned | | <td>Do not push an Explicit NULL label</td>
+-------+-----------------------------------+---------------+ <td>RFC 9830</td>
</tr>
Table 10: SR Policy ENLP Values <tr>
<td>5-255</td>
<td colspan="2">Unassigned</td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security mechanisms of the base BGP security model apply to the <t>The security mechanisms of the base BGP security model apply to the
extensions described in this document as well. See the Security extensions described in this document as well. See the Security
Considerations section of <xref target="RFC4271"/> for a discussion of Considerations section of <xref target="RFC4271" format="default"/> for a
BGP security. Also, refer to <xref target="RFC4272"/> and <xref discussion of
target="RFC6952"/> for analysis of security issues for BGP.</t> BGP security. Also, refer to <xref target="RFC4272" format="default"/> and
<xref target="RFC6952" format="default"/> for analysis of security issues for B
GP.</t>
<t>The BGP SR Policy extensions specified in this document enable <t>The BGP SR Policy extensions specified in this document enable
traffic engineering and service programming use-cases within an SR traffic engineering and service programming use cases within an SR
domain as described in <xref target="RFC9256"/>. SR operates within a domain as described in <xref target="RFC9256" format="default"/>. SR opera
trusted SR domain <xref target="RFC8402"/> and its security tes within a
trusted SR domain <xref target="RFC8402" format="default"/>; its security
considerations also apply to BGP sessions when carrying SR Policy considerations also apply to BGP sessions when carrying SR Policy
information. The SR Policies distributed by BGP are expected to be used information. The SR Policies distributed by BGP are expected to be used
entirely within this trusted SR domain which comprises a single AS or entirely within this trusted SR domain, which comprises a single AS or
multiple ASes/domains within a single provider network. Therefore, multiple ASes / domains within a single provider network. Therefore,
precaution is necessary to ensure that the SR Policy information precaution is necessary to ensure that the SR Policy information
advertised via BGP sessions is limited to nodes in a secure manner advertised via BGP sessions is limited to nodes in a secure manner
within this trusted SR domain. BGP peering sessions for address-families within this trusted SR domain. BGP peering sessions for address families
other than SR Policy SAFI may be set up to routers outside the SR other than those that use the SR Policy SAFI may be set up to routers outs
ide the SR
domain. The isolation of BGP SR Policy SAFI peering sessions may be used domain. The isolation of BGP SR Policy SAFI peering sessions may be used
to ensure that the SR Policy information is not advertised by accident to ensure that the SR Policy information is not advertised by accident
or error to an EBGP peering session outside the SR domain.</t> or in error to an EBGP peering session outside the SR domain.</t>
<t>Additionally, it may be a consideration that the export of SR Policy
<t>Additionally, it may be considered that the export of SR Policy
information, as described in this document, constitutes a risk to information, as described in this document, constitutes a risk to
confidentiality of mission-critical or commercially sensitive confidentiality of mission-critical or commercially sensitive
information about the network (more specifically endpoint/node information about the network (more specifically endpoint/node
addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not
automatic and require configuration; thus, it is the responsibility of automatic and require configuration; thus, it is the responsibility of
the network operator to ensure that only trusted nodes (that include the network operator to ensure that only trusted nodes (that include
both routers and controller applications) within the SR domain are both routers and controller applications) within the SR domain are
configured to receive such information.</t> configured to receive such information.</t>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>The specification of BGP models is an ongoing work based on <xref <t>The specification of BGP models is an ongoing work based on <xref targe
target="I-D.ietf-idr-bgp-model"/> and its future extensions are expected t="I-D.ietf-idr-bgp-model" format="default"/>; its future extensions are expecte
d
to cover the SR Policy SAFI. Existing BGP operational procedures also to cover the SR Policy SAFI. Existing BGP operational procedures also
apply to the SAFI specified in this document. The management, apply to the SAFI specified in this document. The management,
operations, and monitoring of BGP speakers and the SR Policy SAFI operations, and monitoring of BGP speakers and the SR Policy SAFI
sessions between them are not very different from other BGP sessions and sessions between them are not very different from other BGP sessions and
can be managed using the same data models.</t> can be managed using the same data models.</t>
<t>The YANG data model for the operation and management of SR Policies <xr
<t>The YANG model for the operation and management of SR Policies <xref ef target="I-D.ietf-spring-sr-policy-yang" format="default"/> reports the SR Pol
target="I-D.ietf-spring-sr-policy-yang"/> reports the SR Policies icies
provisioned via BGP SR Policy SAFI along with their operational provisioned via BGP SR Policy SAFI along with their operational
states.</t> states.</t>
</section> </section>
<section title="Acknowledgments">
<t>The authors of this document would like to thank Shyam Sethuram, John
Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene,
Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Jakob
Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, John
Scudder, Vincent Roca, Brian Haberman, Mohamed Boucadair, Shunwan
Zhuang, Andrew Alston, Jeffrey (Zhaohui) Zhang, Nagendra Nainar, Rajesh
Melarcode Venkateswaran, Nat Kao, Boris Hassanov, Vincent Roca, Russ
Housley, and Dan Romascanu for their comments and review of this
document. The authors would like to thank Susan Hares for her detailed
shepherd review that helped in improving the document.</t>
</section>
<section anchor="Contributors" title="Contributors">
<figure>
<artwork><![CDATA[Eric Rosen
Juniper Networks
US
Email: erosen@juniper.net]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Arjun Sreekantiah
Cisco Systems
US
Email: asreekan@cisco.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Acee Lindem
Cisco Systems
US
Email: acee@cisco.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Siva Sivabalan
Cisco Systems
US
Email: msiva@cisco.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Imtiyaz Mohammad
Arista Networks
India
Email: imtiyaz@arista.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Gaurav Dawra
Cisco Systems
US
Email: gdawra.ietf@gmail.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Peng Shaofu
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Steven Lin
Calix
USA
Email: steven.lin@calix.com]]></artwork>
</figure>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.1997"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8126"?>
<?rfc include="reference.RFC.2545"?> <displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG-MODEL"/>
<displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="BGP-LS-SR-POLIC
<?rfc include="reference.RFC.5462"?> Y"/>
<displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/>
<?rfc include="reference.RFC.4760"?> <references>
<name>References</name>
<?rfc include="reference.RFC.4271"?> <references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
997.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.8
174.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.2
545.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
360.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.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.9
012.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
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.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.8
986.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
272.xml"/>
<?rfc include="reference.RFC.6286"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-idr-bgp-model.xml"/>
<?rfc include="reference.RFC.4360"?> <reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ie
tf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-16">
<front>
<title>Advertisement of Segment Routing Policies using BGP Link-State</tit
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="3" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-16"
/>
<?rfc include="reference.RFC.7606"?> </reference>
<?rfc include="reference.RFC.3032"?> <reference anchor="I-D.ietf-spring-sr-policy-yang" target="https://datatracker.i
etf.org/doc/html/draft-ietf-spring-sr-policy-yang-04">
<front>
<title>YANG Data Model for Segment Routing Policy</title>
<author initials="K." surname="Raza" fullname="Syed Kamran Raza" role="edi
tor">
<organization>Cisco Systems</organization>
</author>
<author initials="T." surname="Saleh" fullname="Tarik Saleh">
<organization>Cisco Systems</organization>
</author>
<author initials="Z." surname="Shunwan" fullname="Zhuang Shunwan">
<organization>Huawei Technologies</organization>
</author>
<author initials="D." surname="Voyer" fullname="Daniel Voyer">
<organization>Bell Canada</organization>
</author>
<author initials="M." surname="Durrani" fullname="Muhammad Durrani">
<organization>Equinix</organization>
</author>
<author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
<organization>SoftBank</organization>
</author>
<author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization>
</author>
<date month="November" day="22" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-policy-yang-04"
/>
<?rfc include="reference.RFC.9012"?> </reference>
<?rfc include="reference.RFC.8402"?> <reference anchor="RFC9831" target="https://www.rfc-editor.org/info/rfc9831">
<front>
<title>Segment Type Extensions for BGP Segment Routing (SR) Policy</title>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="September" year="2025" />
</front>
<seriesInfo name="RFC" value="9831" />
<seriesInfo name='DOI' value='10.17487/RFC9831'/>
<?rfc include="reference.RFC.8660"?> </reference>
<?rfc include="reference.RFC.8754"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
456.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
</references>
</references>
<?rfc include="reference.RFC.9256"?> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors of this document would like to thank <contact
fullname="Shyam Sethuram"/>, <contact fullname="John Scudder"/>,
<contact fullname="Przemyslaw Krol"/>, <contact fullname="Alex
id Bogdanov"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Bruno
Decraene"/>, <contact fullname="Gurusiddesh Nidasesi"/>, <contact
fullname="Kausik Majumdar"/>, <contact fullname="Zafar Ali"/>, <contact
fullname="Swadesh Agarwal"/>, <contact fullname="Jakob Heitz"/>,
<contact fullname="Viral Patel"/>, <contact fullname="Peng Shaofu"/>,
<contact fullname="Cheng Li"/>, <contact fullname="Martin Vigoureux"/>,
<contact fullname="John Scudder"/>, <contact fullname="Vincent Roca"/>,
<contact fullname="Brian Haberman"/>, <contact fullname="Mohamed
Boucadair"/>, <contact fullname="Shunwan Zhuang"/>, <contact
fullname="Andrew Alston"/>, <contact fullname="Jeffrey (Zhaohui)
Zhang"/>, <contact fullname="Nagendra Nainar"/>, <contact
fullname="Rajesh Melarcode Venkateswaran"/>, <contact fullname="Nat
Kao"/>, <contact fullname="Boris Hassanov"/>, <contact fullname="Vincent
Roca"/>, <contact fullname="Russ Housley"/>, and <contact fullname="Dan
Romascanu"/> for their comments and review of this document. The authors
would like to thank <contact fullname="Susan Hares"/> for her detailed
shepherd review that helped in improving the document.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<?rfc include="reference.RFC.8986"?> <contact fullname="Eric Rosen">
</references> <organization>Juniper Networks</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>erosen@juniper.net</email>
</address>
</contact>
<references title="Informational References"> <contact fullname="Arjun Sreekantiah">
<?rfc include="reference.RFC.4272"?> <organization>Cisco Systems</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>asreekan@cisco.com</email>
</address>
</contact>
<?rfc include="reference.I-D.ietf-idr-bgp-model"?> <contact fullname="Acee Lindem">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>acee@cisco.com</email>
</address>
</contact>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-sr-policy"?> <contact fullname="Siva Sivabalan">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>msiva@cisco.com</email>
</address>
</contact>
<?rfc include="reference.I-D.ietf-spring-sr-policy-yang"?> <contact fullname="Imtiyaz Mohammad">
<organization>Arista Networks</organization>
<address>
<postal>
<country>India</country>
</postal>
<email>imtiyaz@arista.com</email>
</address>
</contact>
<?rfc include="reference.I-D.ietf-idr-bgp-sr-segtypes-ext"?> <contact fullname="Gaurav Dawra">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>gdawra.ietf@gmail.com</email>
</address>
</contact>
<?rfc include="reference.RFC.4456"?> <contact fullname="Peng Shaofu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>peng.shaofu@zte.com.cn</email>
</address>
</contact>
<?rfc include="reference.RFC.6952"?> <contact fullname="Steven Lin">
<organization>Calix</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>steven.lin@calix.com</email>
</address>
</contact>
<?rfc include="reference.RFC.9552"?> </section>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 410 change blocks. 
1347 lines changed or deleted 1866 lines changed or added

This html diff was produced by rfcdiff 1.48.