rfc9256xml2.original.xml   rfc9256.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="2"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc inline="yes"?> std" consensus="true"
<?rfc compact="yes"?> docName="draft-ietf-spring-segment-routing-policy-22" number="9256" ipr="trust20
<?rfc subcompact="no"?> 0902" updates="8402"
<rfc category="std" docName="draft-ietf-spring-segment-routing-policy-22" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRef
ipr="trust200902" updates="8402"> s="true" version="3">
<front> <front>
<title abbrev="SR Policy Architecture">Segment Routing Policy <title abbrev="SR Policy Architecture">Segment Routing Policy
Architecture</title> Architecture</title>
<seriesInfo name="RFC" value="9256"/>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Pegasus Parc</street> <extaddr>Pegasus Parc</extaddr>
<street>De kleetlaan 6a</street>
<city>De kleetlaan 6a</city> <city>Diegem</city>
<region>DIEGEM</region>
<code>BRABANT 1831</code>
<country>BELGIUM</country> <code>1831</code>
<country>Belgium</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, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <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="Daniel Voyer" initials="D." surname="Voyer"> <author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization> <organization>Bell Canada</organization>
<address> <address>
<postal> <postal>
<street>671 de la gauchetiere W</street> <street>671 de la gauchetiere W</street>
<city>Montreal</city> <city>Montreal</city>
<region>Quebec</region> <region>Quebec</region>
<code>H3B 2M8</code> <code>H3B 2M8</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.voyer@bell.ca</email> <email>daniel.voyer@bell.ca</email>
</address> </address>
</author> </author>
<author fullname="Alex Bogdanov" initials="A." surname="Bogdanov"> <author fullname="Alex Bogdanov" initials="A." surname="Bogdanov">
<organization>British Telecom</organization> <organization>British Telecom</organization>
<address> <address>
<email>alex.bogdanov@bt.com</email> <email>alex.bogdanov@bt.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-6399</code> <code>98052-6399</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>
<date year="2022" month="July" />
<area>rtg</area>
<workgroup>spring</workgroup>
<date year=""/> <keyword>Segment Routing</keyword>
<keyword>SR Policy</keyword>
<workgroup>SPRING Working Group</workgroup> <keyword>SR-MPLS</keyword>
<keyword>SRv6</keyword>
<keyword>Traffic Engineering</keyword>
<abstract> <abstract>
<t>Segment Routing (SR) allows a node to steer a packet flow along any <t>Segment Routing (SR) allows a node to steer a packet flow along any
path. Intermediate per-path states are eliminated thanks to source path. Intermediate per-path states are eliminated thanks to source
routing. SR Policy is an ordered list of segments (i.e., instructions) routing. SR Policy is an ordered list of segments (i.e., instructions)
that represent a source-routed policy. Packet flows are steered into a that represent a source-routed policy. Packet flows are steered into an
SR Policy on a node where it is instantiated called a headend node. The SR Policy on a node where it is instantiated called a headend node. The
packets steered into an SR Policy carry an ordered list of segments packets steered into an SR Policy carry an ordered list of segments
associated with that SR Policy.</t> associated with that SR Policy.</t>
<t>This document updates RFC 8402 as it details the concepts of SR Policy
<t>This document updates RFC8402 as it details the concepts of SR Policy
and steering into an SR Policy.</t> and steering into an SR Policy.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t>Segment Routing (SR) <xref target="RFC8402"/> allows a node to steer <name>Introduction</name>
<t>Segment Routing (SR) <xref target="RFC8402" format="default"/> allows a
node to steer
a packet flow along any path. The headend is a node where the a packet flow along any path. The headend is a node where the
instructions for source routing (i.e., segments) are written into the instructions for source routing (i.e., segments) are written into the
packet and hence becomes the starting node for a specific segment packet. It hence becomes the starting node for a specific segment
routing path. Intermediate per-path states are eliminated thanks to routing path. Intermediate per-path states are eliminated thanks to
source routing.</t> source routing.</t>
<t>A Segment Routing Policy (SR Policy) <xref target="RFC8402" format="def
<t>A Segment Routing Policy (SR Policy) <xref target="RFC8402"/> is an ault"/> is an
ordered list of segments (i.e., instructions) that represent a ordered list of segments (i.e., instructions) that represent a
source-routed policy. The headend node is said to steer a flow into a SR source-routed policy. The headend node is said to steer a flow into an SR
Policy. The packets steered into an SR Policy have an ordered list of Policy. The packets steered into an SR Policy have an ordered list of
segments associated with that SR Policy written into them. <xref segments associated with that SR Policy written into them. <xref target="R
target="RFC8660"/> describes the representation and processing of this FC8660" format="default"/> describes the representation and processing of this
ordered list of segments as an MPLS label stack for SR-MPLS, while <xref ordered list of segments as an MPLS label stack for SR-MPLS, while <xref t
target="RFC8754"/> and <xref target="RFC8986"/> describe the same for arget="RFC8754" format="default"/> and <xref target="RFC8986" format="default"/>
describe the same for
Segment Routing over IPv6 (SRv6) with the use of the Segment Routing Segment Routing over IPv6 (SRv6) with the use of the Segment Routing
Header (SRH).</t> Header (SRH).</t>
<t><xref target="RFC8402" format="default"/> introduces the SR Policy cons
<t><xref target="RFC8402"/> introduces the SR Policy construct and truct and
provides an overview of how it is leveraged for Segment Routing provides an overview of how it is leveraged for Segment Routing
use-cases. This document updates <xref target="RFC8402"/> to specify use cases. This document updates <xref target="RFC8402" format="default"/> to specify
detailed concepts of SR Policy and steering packets into an SR Policy. detailed concepts of SR Policy and steering packets into an SR Policy.
It applies equally to the SR-MPLS and SRv6 instantiations of segment It applies equally to the SR-MPLS and SRv6 instantiations of segment
routing.</t> routing.</t>
<section anchor="reqlang" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
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 anchor="reqlang" title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="SR-policy" numbered="true" toc="default">
<section anchor="SR-policy" title="SR Policy"> <name>SR Policy</name>
<t>The general concept of SR Policy provides a framework that enables <t>The general concept of SR Policy provides a framework that enables
the instantiation of an ordered list of segments on a node for the instantiation of an ordered list of segments on a node for
implementing a source routing policy for the steering of traffic for a implementing a source routing policy for the steering of traffic for a
specific purpose (e.g. for a specific SLA) from that node.</t> specific purpose (e.g., for a specific Service Level Agreement (SLA)) from
that node.</t>
<t>The Segment Routing architecture <xref target="RFC8402"/> specifies <t>The Segment Routing architecture <xref target="RFC8402" format="default
"/> specifies
that any instruction can be bound to a segment. Thus, an SR Policy can that any instruction can be bound to a segment. Thus, an SR Policy can
be built using any type of Segment Identifier (SID) including those be built using any type of Segment Identifier (SID) including those
associated with topological or service instructions.</t> associated with topological or service instructions.</t>
<t>This section defines the key aspects and constituents of an SR <t>This section defines the key aspects and constituents of an SR
Policy.</t> Policy.</t>
<section anchor="SR-policy-identification" <section anchor="SR-policy-identification" numbered="true" toc="default">
title="Identification of an SR Policy"> <name>Identification of an SR Policy</name>
<t>An SR Policy MUST be identified through the tuple &lt;headend, <t>An SR Policy <bcp14>MUST</bcp14> be identified through the tuple &lt;
color, endpoint&gt;. In the context of a specific headend, an SR Headend,
policy MUST be identified by the &lt;color, endpoint&gt; tuple.</t> Color, Endpoint&gt;. In the context of a specific headend, an SR
Policy <bcp14>MUST</bcp14> be identified by the &lt;Color, Endpoint&gt;
tuple.</t>
<t>The headend is the node where the policy is <t>The headend is the node where the policy is
instantiated/implemented. The headend is specified as an IPv4 or IPv6 instantiated/implemented. The headend is specified as an IPv4 or IPv6
address and MUST resolve to a unique node in the SR domain <xref address and <bcp14>MUST</bcp14> resolve to a unique node in the SR domai
target="RFC8402"/>.</t> n <xref target="RFC8402" format="default"/>.</t>
<t>The endpoint indicates the destination of the policy. The endpoint <t>The endpoint indicates the destination of the policy. The endpoint
is specified as an IPv4 or IPv6 address and SHOULD resolve to a unique is specified as an IPv4 or IPv6 address and <bcp14>SHOULD</bcp14> resolv
node in the domain. In a specific case (refer to <xref e to a unique
target="Steering-optional-bgp-color-only-steering"/>), the endpoint node in the domain. In a specific case (refer to <xref target="Steering-
optional-bgp-color-only-steering" format="default"/>), the endpoint
can be the unspecified address (0.0.0.0 for IPv4, :: for IPv6) and in can be the unspecified address (0.0.0.0 for IPv4, :: for IPv6) and in
this case, the destination of the policy is indicated by the last this case, the destination of the policy is indicated by the last
segment in the segment list(s).</t> segment in the segment list(s).</t>
<t>The color is an unsigned non-zero 32-bit integer value that <t>The color is an unsigned non-zero 32-bit integer value that
associates the SR Policy with an intent or objective (e.g. associates the SR Policy with an intent or objective (e.g.,
low-latency).</t> low latency).</t>
<t>The endpoint and the color are used to automate the steering of <t>The endpoint and the color are used to automate the steering of
service or transport routes on SR Policies (refer to <xref service or transport routes on SR Policies (refer to <xref target="Steer
target="Steering"/>).</t> ing" format="default"/>).</t>
<t>An implementation <bcp14>MAY</bcp14> allow the assignment of a symbol
<t>An implementation MAY allow the assignment of a symbolic name ic name
comprising printable ASCII <xref target="RFC0020"/> characters (i.e., comprising printable ASCII <xref target="RFC0020" format="default"/> cha
racters (i.e.,
0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute
for debugging and troubleshooting purposes. Such symbolic names may for debugging and troubleshooting purposes. Such symbolic names may
identify an SR Policy when the naming scheme ensures uniqueness. The identify an SR Policy when the naming scheme ensures uniqueness. The
SR Policy name MAY also be signaled along with a candidate path of the SR Policy name <bcp14>MAY</bcp14> also be signaled along with a candidat
SR Policy (refer to <xref target="SR-policy-candidate-path"/>). An SR e path of the
Policy MAY have multiple names associated with it in the scenario SR Policy (refer to <xref target="SR-policy-candidate-path" format="defa
ult"/>). An SR
Policy <bcp14>MAY</bcp14> have multiple names associated with it in the
scenario
where the headend receives different SR Policy names along with where the headend receives different SR Policy names along with
different candidate paths for the same SR Policy via the same or different candidate paths for the same SR Policy via the same or
different sources.</t> different sources.</t>
</section> </section>
<section anchor="SR-policy-candidate-path" numbered="true" toc="default">
<section anchor="SR-policy-candidate-path" <name>Candidate Path and Segment List</name>
title="Candidate Path and Segment List">
<t>An SR Policy is associated with one or more candidate paths. A <t>An SR Policy is associated with one or more candidate paths. A
candidate path is the unit for signaling of an SR Policy to a headend candidate path is the unit for signaling of an SR Policy to a headend
via protocol extensions like Path Computation Element (PCE) via protocol extensions like the Path Computation Element
Communication Protocol (PCEP) <xref target="RFC8664"/> <xref Communication Protocol (PCEP) <xref target="RFC8664" format="default"/>
target="I-D.ietf-pce-segment-routing-policy-cp"/> or BGP SR Policy <xref target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> or BGP
<xref target="I-D.ietf-idr-segment-routing-te-policy"/>.</t> SR Policy
<xref target="I-D.ietf-idr-segment-routing-te-policy" format="default"/>
<t>A Segment-List represents a specific source-routed path to send .</t>
<t>A segment list represents a specific source-routed path to send
traffic from the headend to the endpoint of the corresponding SR traffic from the headend to the endpoint of the corresponding SR
policy.</t> Policy.</t>
<t>A candidate path is either dynamic, explicit, or composite.</t> <t>A candidate path is either dynamic, explicit, or composite.</t>
<t>An explicit candidate path is expressed as a segment list or a set
<t>An explicit candidate path is expressed as a Segment-List or a set of segment lists.</t>
of Segment-Lists.</t>
<t>A dynamic candidate path expresses an optimization objective and a <t>A dynamic candidate path expresses an optimization objective and a
set of constraints for a specific data plane (i.e., SR-MPLS or SRv6). set of constraints for a specific data plane (i.e., SR-MPLS or SRv6).
The headend (potentially with the help of a PCE) computes a solution The headend (potentially with the help of a PCE) computes a solution
Segment-List (or set of Segment-Lists) that solves the optimization segment list (or set of segment lists) that solves the optimization
problem.</t> problem.</t>
<t>If a candidate path is associated with a set of segment lists, each
<t>If a candidate path is associated with a set of Segment-Lists, each segment list is associated with weight for weighted load balancing
Segment-List is associated with weight for weighted load balancing (refer to <xref target="SR-policy-instantiation" format="default"/> for
(refer to <xref target="SR-policy-instantiation"/> for details). The details). The
default weight is 1.</t> default weight is 1.</t>
<t>A composite candidate path acts as a container for grouping SR <t>A composite candidate path acts as a container for grouping SR
Policies. The composite candidate path construct enables the Policies. The composite candidate path construct enables the
combination of SR Policies, each with explicit candidate paths and/or combination of SR Policies, each with explicit candidate paths and/or
dynamic candidate paths with potentially different optimization dynamic candidate paths with potentially different optimization
objectives and constraints, for load-balanced steering of packet flows objectives and constraints, for load-balanced steering of packet flows
over its constituent SR Policies. The following criteria apply for over its constituent SR Policies. The following criteria apply for
inclusion of constituent SR Policies using a composite candidate path inclusion of constituent SR Policies using a composite candidate path
under a parent SR Policy:<list style="symbols"> under a parent SR Policy:</t>
<t>the endpoints of the constituent SR Policies and the parent SR <ul spacing="normal">
Policy MUST be identical</t> <li>The endpoints of the constituent SR Policies and the parent SR
Policy <bcp14>MUST</bcp14> be identical.</li>
<t>The colors of each of the constituent SR Policies and the <li>The colors of each of the constituent SR Policies and the
parent SR Policy MUST be different</t> parent SR Policy <bcp14>MUST</bcp14> be different.</li>
<li>The constituent SR Policies <bcp14>MUST NOT</bcp14> use composite
<t>the constituent SR Policies MUST NOT use composite candidate candidate
paths</t> paths.</li>
</list></t> </ul>
<t>Each constituent SR Policy of a composite candidate path is <t>Each constituent SR Policy of a composite candidate path is
associated with weight for load-balancing purposes (refer to <xref associated with weight for load-balancing purposes (refer to <xref targe
target="SR-policy-instantiation"/> for details). The default weight is t="SR-policy-instantiation" format="default"/> for details). The default weight
is
1.</t> 1.</t>
<t><xref target="SR-policy-summary" format="default"/> illustrates an in
<t>The <xref target="SR-policy-summary"/> illustrates an information formation
model for hierarchical relationships between the SR Policy constructs model for hierarchical relationships between the SR Policy constructs
described in this section.</t> described in this section.</t>
</section> </section>
<section anchor="SR-policy-protocol-origin" numbered="true" toc="default">
<name>Protocol-Origin of a Candidate Path</name>
<section anchor="SR-policy-protocol-origin" <t>A headend may be informed about a candidate path for an SR Policy
title="Protocol-Origin of a Candidate Path"> &lt;Color, Endpoint&gt; by various means including: via configuration,
<t>A headend may be informed about a candidate path for an SR Policy PCEP <xref target="RFC8664" format="default"/> <xref target="I-D.ietf-pc
&lt;color, endpoint&gt; by various means including: via configuration, e-segment-routing-policy-cp" format="default"/>, or BGP <xref target="I-D.ietf-i
PCEP <xref target="RFC8664"/> <xref dr-segment-routing-te-policy" format="default"/>.</t>
target="I-D.ietf-pce-segment-routing-policy-cp"/> or BGP <xref
target="I-D.ietf-idr-segment-routing-te-policy"/>.</t>
<t>Protocol-Origin of a candidate path is an 8-bit value associated <t>Protocol-Origin of a candidate path is an 8-bit value associated
with the mechanism or protocol used for signaling/provisioning the SR with the mechanism or protocol used for signaling/provisioning the SR
Policy. It helps identify the protocol/mechanism that provides or Policy. It helps identify the protocol/mechanism that provides or
signals the candidate path and indicates its preference relative to signals the candidate path and indicates its preference relative to
other protocols/mechanisms.</t> other protocols/mechanisms.</t>
<t>The headend assigns different Protocol-Origin values to each
<t>The head-end assigns different Protocol-Origin values to each
source of SR Policy information. The Protocol-Origin value is used as source of SR Policy information. The Protocol-Origin value is used as
a tie-breaker between candidate paths of equal preference, as a tiebreaker between candidate paths of equal Preference, as
described in <xref target="SR-policy-candidate-path-active"/>. The described in <xref target="SR-policy-candidate-path-active" format="defa
table below specifies the RECOMMENDED default values of ult"/>. The
table below specifies the <bcp14>RECOMMENDED</bcp14> default values of
Protocol-Origin:</t> Protocol-Origin:</t>
<table anchor="table_ex" align="center">
<texttable anchor="table_ex" title="Protocol-Origin default values"> <name>Protocol-Origin Default Values</name>
<ttcol align="center">Protocol-Origin</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="center">Protocol-Origin</th>
<th align="left">Description</th>
<c>10</c> </tr>
</thead>
<c>PCEP</c> <tbody>
<tr>
<c>20</c> <td align="center">10</td>
<td align="left">PCEP</td>
<c>BGP SR Policy</c> </tr>
<tr>
<c>30</c> <td align="center">20</td>
<td align="left">BGP SR Policy</td>
<c>Via Configuration</c> </tr>
</texttable> <tr>
<td align="center">30</td>
<td align="left">Via Configuration</td>
</tr>
</tbody>
</table>
<t>Note that the above order is to satisfy the need for having a clear <t>Note that the above order is to satisfy the need for having a clear
ordering and implementations MAY allow modifications of these default ordering, and implementations <bcp14>MAY</bcp14> allow modifications of these default
values assigned to protocols on the headend along similar lines as a values assigned to protocols on the headend along similar lines as a
routing administrative distance. Its application in the candidate path routing administrative distance. Its application in the candidate path
selection is described in <xref selection is described in <xref target="SR-policy-candidate-path-active"
target="SR-policy-candidate-path-active"/>.</t> format="default"/>.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-originator" numbered="true" toc=
<section anchor="SR-policy-candidate-path-originator" "default">
title="Originator of a Candidate Path"> <name>Originator of a Candidate Path</name>
<t>Originator identifies the node which provisioned or signaled the <t>The Originator identifies the node that provisioned or signaled the
candidate path on the headend. The originator is expressed in the form candidate path on the headend. The Originator is expressed in the form
of a 160-bit numerical value formed by the concatenation of the fields of a 160-bit numerical value formed by the concatenation of the fields
of the tuple &lt;Autonomous System Number (ASN), node-address&gt; as of the tuple &lt;Autonomous System Number (ASN), node-address&gt; as
below:</t> below:</t>
<t><list style="symbols"> <dl>
<t>Autonomous System Number (ASN) : represented as a 4-byte <dt>Autonomous System Number (ASN):
number. If 2-byte ASNs are in use, the low-order 16 bits MUST be </dt>
used, and the high-order bits MUST be set to zero.</t> <dd>represented as a 4-byte number. If 2-byte ASNs are in use, the
low-order 16 bits <bcp14>MUST</bcp14> be used, and the high-order
bits <bcp14>MUST</bcp14> be set to 0.
</dd>
<t>Node Address : represented as a 128-bit value. IPv4 addresses <dt>Node Address:
MUST be encoded in the lowest 32 bits, and the high-order bits </dt>
MUST be set to zero.</t> <dd>represented as a 128-bit value. IPv4 addresses
</list></t> <bcp14>MUST</bcp14> be encoded in the lowest 32 bits, and the
high-order bits <bcp14>MUST</bcp14> be set to 0.
</dd>
<t>Its application in the candidate path selection is described in </dl>
<xref target="SR-policy-candidate-path-active"/>.</t>
<t>Its application in the candidate path selection is described in
<xref target="SR-policy-candidate-path-active" format="default"/>.</t>
<t>When provisioning is via configuration, the ASN and node address <t>When provisioning is via configuration, the ASN and node address
MAY be set to either the headend or the provisioning controller/node <bcp14>MAY</bcp14> be set to either the headend or the provisioning cont roller/node
ASN and address. The default value is 0 for both AS and node ASN and address. The default value is 0 for both AS and node
address.</t> address.</t>
<t>When signaling is via PCEP, it is the IPv4 or IPv6 address of the <t>When signaling is via PCEP, it is the IPv4 or IPv6 address of the
PCE and the AS number is expected to be set to 0 by default when not PCE, and the AS number is expected to be set to 0 by default when not
available or known.</t> available or known.</t>
<t>When signaling is via BGP SR Policy, the ASN and node address are
<t>When signaling is via BGP SR Policy, the ASN and Node Address are provided by BGP (refer to <xref target="I-D.ietf-idr-segment-routing-te-
provided by BGP (refer to <xref policy" format="default"/>) on the headend.</t>
target="I-D.ietf-idr-segment-routing-te-policy"/>) on the headend.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-discriminator" numbered="true" t
<section anchor="SR-policy-candidate-path-discriminator" oc="default">
title="Discriminator of a Candidate Path"> <name>Discriminator of a Candidate Path</name>
<t>The Discriminator is a 32-bit value associated with a candidate <t>The Discriminator is a 32-bit value associated with a candidate
path that uniquely identifies it within the context of an SR Policy path that uniquely identifies it within the context of an SR Policy
from a specific Protocol-Origin as specified below:<list from a specific Protocol-Origin as specified below:</t>
style="symbols"> <ul spacing="normal">
<t>When provisioning is via configuration, this is an <li>When provisioning is via configuration, this is a unique
implementation's configuration-model-specific unique identifier identifier for a candidate path; it is specific to the
for a candidate path. The default value is 0.</t> implementation's configuration model. The default value is 0.</li>
<li>When signaling is via PCEP, the method to uniquely signal an
<t>When signaling is via PCEP, the method to uniquely signal an individual candidate path along with its Discriminator is
individual candidate path along with its discriminator is described in <xref target="I-D.ietf-pce-segment-routing-policy-cp" f
described in <xref ormat="default"/>. The default
target="I-D.ietf-pce-segment-routing-policy-cp"/>. The default value is 0.</li>
value is 0.</t> <li>When signaling is via BGP SR Policy, the BGP process receiving
the route provides the distinguisher (refer to <xref
<t>When signaling is via BGP SR Policy, the BGP process receiving target="I-D.ietf-idr-segment-routing-te-policy" format="default"/>) a
the route provides the distinguisher (refer to Section 2.1 of s the Discriminator. Note that
<xref target="I-D.ietf-idr-segment-routing-te-policy"/>) as the the BGP best path selection is applied before the route is supplied
discriminator. Note that the BGP best path selection is applied as a candidate path, so only a single candidate path for a given SR
before the route is supplied as a candidate path, so only a single Policy will be seen for a given Discriminator.</li>
candidate path for a given SR Policy will be seen for a given </ul>
discriminator.</t>
</list></t>
<t>Its application in the candidate path selection is described in <t>Its application in the candidate path selection is described in
<xref target="SR-policy-candidate-path-active"/>.</t> <xref target="SR-policy-candidate-path-active" format="default"/>.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-identification" numbered="true"
<section anchor="SR-policy-candidate-path-identification" toc="default">
title="Identification of a Candidate Path"> <name>Identification of a Candidate Path</name>
<t>A candidate path is identified in the context of a single SR <t>A candidate path is identified in the context of a single SR
Policy.</t> Policy.</t>
<t>A candidate path is not shared across SR Policies.</t> <t>A candidate path is not shared across SR Policies.</t>
<t>A candidate path is not identified by its segment list(s).</t>
<t>A candidate path is not identified by its Segment-List(s).</t> <aside>
<t>If CP1 is a candidate path of SR Policy Pol1 and CP2 is a
<t><list>
<t>If CP1 is a candidate path of SR Policy Pol1 and CP2 is a
candidate path of SR Policy Pol2, then these two candidate paths candidate path of SR Policy Pol2, then these two candidate paths
are independent, even if they happen to have the same are independent, even if they happen to have the same
Segment-List. The Segment-List does not identify a candidate path. segment list. The segment list does not identify a candidate path.
The Segment-List is an attribute of a candidate path.</t> The segment list is an attribute of a candidate path.
</list></t> </t>
</aside>
<t>The identity of a candidate path MUST be uniquely established in <t>The identity of a candidate path <bcp14>MUST</bcp14> be uniquely esta
the context of an SR Policy &lt;headend, color, endpoint&gt; to handle blished in
add, delete or modify operations on them in an unambiguous manner the context of an SR Policy &lt;Headend, Color, Endpoint&gt; to handle
add, delete, or modify operations on them in an unambiguous manner
regardless of their source(s).</t> regardless of their source(s).</t>
<t>The tuple &lt;Protocol-Origin, originator, discriminator&gt; <t>The tuple &lt;Protocol-Origin, Originator, Discriminator&gt;
uniquely identifies a candidate path.</t> uniquely identifies a candidate path.</t>
<t>Candidate paths <bcp14>MAY</bcp14> also be assigned or signaled with
<t>Candidate paths MAY also be assigned or signaled with a symbolic a symbolic
name comprising printable ASCII <xref target="RFC0020"/> characters name comprising printable ASCII <xref target="RFC0020" format="default"/
> characters
(i.e., 0x20 to 0x7E) to serve as a user-friendly attribute for (i.e., 0x20 to 0x7E) to serve as a user-friendly attribute for
debugging and troubleshooting purposes. Such symbolic names MUST NOT debugging and troubleshooting purposes. Such symbolic names <bcp14>MUST NOT</bcp14>
be considered as identifiers for a candidate path. The signaling of be considered as identifiers for a candidate path. The signaling of
the candidate path name via BGP and PCEP is described in <xref the candidate path name via BGP and PCEP is described in <xref target="I
target="I-D.ietf-pce-segment-routing-policy-cp"/> and <xref -D.ietf-idr-segment-routing-te-policy" format="default"/> and <xref target="I-D.
target="I-D.ietf-idr-segment-routing-te-policy"/> respectively.</t> ietf-pce-segment-routing-policy-cp" format="default"/>, respectively.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-preference" numbered="true" toc=
<section anchor="SR-policy-candidate-path-preference" "default">
title="Preference of a Candidate Path"> <name>Preference of a Candidate Path</name>
<t>The preference of the candidate path is used to select the best <t>The Preference of the candidate path is used to select the best
candidate path for an SR Policy. It is a 32-bit value where a higher candidate path for an SR Policy. It is a 32-bit value where a higher
value indicates higher preference and the default preference value is value indicates higher preference and the default Preference value is
100.</t> 100.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that each candidate path of a given
<t>It is RECOMMENDED that each candidate path of a given SR policy has SR Policy has
a different preference.</t> a different Preference.</t>
<t>The signaling of the candidate path Preference via BGP and PCEP is
<t>The signaling of the candidate path preference via BGP and PCEP is described in <xref target="I-D.ietf-idr-segment-routing-te-policy" forma
described in <xref target="I-D.ietf-pce-segment-routing-policy-cp"/> t="default"/> and <xref target="I-D.ietf-pce-segment-routing-policy-cp" format="
and <xref target="I-D.ietf-idr-segment-routing-te-policy"/> default"/>,
respectively.</t> respectively.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-validity" numbered="true" toc="d
<section anchor="SR-policy-candidate-path-validity" efault">
title="Validity of a Candidate Path"> <name>Validity of a Candidate Path</name>
<t>A candidate path is usable when it is valid. The RECOMMEDED <t>A candidate path is usable when it is valid. The <bcp14>RECOMMENDED</
bcp14>
candidate path validity criterion is the validity of at least one of candidate path validity criterion is the validity of at least one of
its constituent Segment-Lists. The validation rules are specified in its constituent segment lists. The validation rules are specified in
<xref target="Path-validity"/>.</t> <xref target="Path-validity" format="default"/>.</t>
</section> </section>
<section anchor="SR-policy-candidate-path-active" numbered="true" toc="def ault">
<section anchor="SR-policy-candidate-path-active" <name>Active Candidate Path</name>
title="Active Candidate Path">
<t>A candidate path is selected when it is valid and it is determined <t>A candidate path is selected when it is valid and it is determined
to be the best path of the SR Policy. The selected path is referred to to be the best path of the SR Policy. The selected path is referred to
as the "active path" of the SR policy in this document.</t> as the "active path" of the SR Policy in this document.</t>
<t>Whenever a new path is learned or an active path is deleted, the <t>Whenever a new path is learned or an active path is deleted, the
validity of an existing path changes or an existing path is changed, validity of an existing path changes, or an existing path is changed,
the selection process MUST be re-executed.</t> the selection process <bcp14>MUST</bcp14> be re-executed.</t>
<t>The candidate path selection process operates primarily on the <t>The candidate path selection process operates primarily on the
candidate path Preference. A candidate path is selected when it is candidate path Preference. A candidate path is selected when it is
valid and it has the highest preference value among all the valid valid and it has the highest Preference value among all the valid
candidate paths of the SR Policy.</t> candidate paths of the SR Policy.</t>
<t>In the case of multiple valid candidate paths of the same <t>In the case of multiple valid candidate paths of the same
preference, the tie-breaking rules are evaluated on the identification Preference, the tie-breaking rules are evaluated on the identification
tuple in the following order until only one valid best path is tuple in the following order until only one valid best path is
selected: <list style="numbers"> selected: </t>
<t>Higher value of Protocol-Origin is selected.</t> <ol spacing="normal" type="1"><li>The higher value of Protocol-Origin is
selected.</li>
<t>If specified by configuration, prefer the existing installed <li>If specified by configuration, prefer the existing installed
path.</t> path.</li>
<li>The lower value of the Originator is selected.</li>
<t>Lower value of originator is selected.</t> <li>Finally, the higher value of the Discriminator is selected.</li>
</ol>
<t>Finally, the higher value of discriminator is selected.</t>
</list></t>
<t>The rules are framed with multiple protocols and sources in mind <t>The rules are framed with multiple protocols and sources in mind
and hence may not follow the logic of a single protocol (e.g. BGP best and hence may not follow the logic of a single protocol (e.g., BGP best
path selection). The motivation behind these rules are as follows: path selection). The motivation behind these rules are as follows:
<list style="symbols"> </t>
<t>The preference, being the primary criterion, allows an operator <ul spacing="normal">
to influence selection across paths thus allowing provisioning of
multiple path options, e.g., CP1 is preferred and if it becomes
invalid then fallback to CP2 and so on. Since preference works
across protocol sources, it also enables (where necessary)
selective override of the default Protocol-Origin preference,
e.g., to prefer a path signaled via BGP SR Policy over what is
configured.</t>
<t>The Protocol-Origin allows an operator to set up a default <li>
selection mechanism across protocol sources, e.g., to prefer The Preference, being the primary criterion, allows an operator to influence
configured over paths signaled via BGP SR Policy or PCEP.</t> selection across paths thus allowing provisioning of multiple path options,
e.g., CP1 is preferred as its Preference value is the highest, and if it
becomes invalid, then CP2 with the next highest Preference value is selected,
and so on. Since Preference works across protocol sources, it also enables
(where necessary) selective override of the default Protocol-Origin
preference, e.g., to prefer a path signaled via BGP SR Policy over what is
configured.</li>
<t>The originator allows an operator to have multiple redundant <li>The Protocol-Origin allows an operator to set up a default
selection mechanism across protocol sources, e.g., to prefer
configured paths over paths signaled via BGP SR Policy or PCEP.</li>
<li>The Originator allows an operator to have multiple redundant
controllers and still maintain a deterministic behavior over which controllers and still maintain a deterministic behavior over which
of them are preferred even if they are providing the same of them are preferred even if they are providing the same
candidate paths for the same SR policies to the headend.</t> candidate paths for the same SR policies to the headend.</li>
<li>The Discriminator performs the final tie-breaking step to ensure
<t>The discriminator performs the final tiebreaking step to ensure
a deterministic outcome of selection regardless of the order in a deterministic outcome of selection regardless of the order in
which candidate paths are signaled across multiple transport which candidate paths are signaled across multiple transport
channels or sessions.</t> channels or sessions.</li>
</list></t> </ul>
<t><xref target="I-D.filsfils-spring-sr-policy-considerations" format="d
<t>Section 4 of <xref efault"/> provides a set
target="I-D.filsfils-spring-sr-policy-considerations"/> provides a set
of examples to illustrate the active candidate path selection of examples to illustrate the active candidate path selection
rules.</t> rules.</t>
</section> </section>
<section anchor="SR-policy-validity" numbered="true" toc="default">
<section anchor="SR-policy-validity" title="Validity of an SR Policy"> <name>Validity of an SR Policy</name>
<t>An SR Policy is valid when it has at least one valid candidate <t>An SR Policy is valid when it has at least one valid candidate
path.</t> path.</t>
</section> </section>
<section anchor="SR-policy-instantiation" numbered="true" toc="default">
<section anchor="SR-policy-instantiation" <name>Instantiation of an SR Policy in the Forwarding Plane</name>
title="Instantiation of an SR Policy in the Forwarding Plane"> <t>Generally, only valid SR policies are instantiated in the
<t>Generally, only valid SR policies are instantiated in the
forwarding plane.</t> forwarding plane.</t>
<t>Only the active candidate path <bcp14>MUST</bcp14> be used for forwar
<t>Only the active candidate path MUST be used for forwarding traffic ding traffic
that is being steered onto that policy except for certain scenarios that is being steered onto that policy except for certain scenarios
such as fast-reroute where a backup candidate path may be used as such as fast reroute where a backup candidate path may be used as
described in <xref target="cp-path-protection"/>.</t> described in <xref target="cp-path-protection" format="default"/>.</t>
<t>If a set of segment lists is associated with the active path of the
<t>If a set of Segment-Lists is associated with the active path of the policy, then the steering is per flow and weighted-ECMP (W-ECMP) based
policy, then the steering is per-flow and weighted-ECMP (W-ECMP) based according to the relative weight of each segment list.</t>
according to the relative weight of each Segment-List.</t> <t>The fraction of the flows associated with a given segment list is
w/&wj;Sw, where w is the weight of the segment list and Sw is the sum of
<t>The fraction of the flows associated with a given Segment-List is the weights of the segment lists of the selected path of the SR
w/Sw, where w is the weight of the Segment-List and Sw is the sum of
the weights of the Segment-Lists of the selected path of the SR
Policy.</t> Policy.</t>
<t>When a composite candidate path is active, the fraction of flows <t>When a composite candidate path is active, the fraction of flows
steered into each constituent SR Policy is equal to the relative steered into each constituent SR Policy is equal to the relative
weight of each constituent SR Policy. Further load balancing of flows weight of each constituent SR Policy. Further load-balancing of flows
steered into a constituent SR Policy is performed based on the weights steered into a constituent SR Policy is performed based on the weights
of the Segment-List of the active candidate path of that constituent of the segment list of the active candidate path of that constituent
SR Policy.</t> SR Policy.</t>
<t>The accuracy of the weighted load-balancing depends on the platform <t>The accuracy of the weighted load-balancing depends on the platform
implementation.</t> implementation.</t>
</section> </section>
<section anchor="SR-policy-priority" numbered="true" toc="default">
<section anchor="SR-policy-priority" title="Priority of an SR Policy"> <name>Priority of an SR Policy</name>
<t>Upon topological change, many policies could be recomputed or <t>Upon topological change, many policies could be re-computed or
revalidated. An implementation MAY provide a per-policy priority revalidated. An implementation <bcp14>MAY</bcp14> provide a per-policy p
riority
configuration. The operator may set this field to indicate the order configuration. The operator may set this field to indicate the order
in which the policies should be re-computed. Such a priority is in which the policies should be re-computed. Such a priority is
represented by an integer in the range (0, 255) where the lowest value represented by an integer in the range (0, 255) where the lowest value
is the highest priority. The default value of priority is 128.</t> is the highest priority. The default value of priority is 128.</t>
<t>An SR Policy may comprise multiple candidate paths received from
<t>An SR Policy may comprise multiple Candidate Paths received from the same or different sources. A candidate path <bcp14>MAY</bcp14> be si
the same or different sources. A candidate path MAY be signaled with a gnaled with a
priority value. When an SR Policy has multiple candidate paths with priority value. When an SR Policy has multiple candidate paths with
distinct signaled non-default priority values and the SR Policy itself distinct signaled non-default priority values and the SR Policy itself
does not have a priority value configured, the SR Policy as a whole does not have a priority value configured, the SR Policy as a whole
takes the lowest value (i.e., the highest priority) amongst these takes the lowest value (i.e., the highest priority) amongst these
signaled priority values.</t> signaled priority values.</t>
</section> </section>
<section anchor="SR-policy-summary" numbered="true" toc="default">
<section anchor="SR-policy-summary" title="Summary"> <name>Summary</name>
<t>In summary, the information model is the following:</t> <t>In summary, the information model is the following:</t>
<dl newline="false" spacing="compact" indent="0">
<t><?rfc subcompact="yes"?> <list hangIndent="50" style="hanging"> <dt>SR Policy POL1</dt>
<t <dd> &lt;Headend = H1, Color = 1, Endpoint = E1&gt;
hangText="SR policy POL1 &lt;headend = H1, color = 1, endpoint = E1& </dd>
gt;"/> <dt>Candidate Path CP1</dt>
<dd>&lt;Protocol-Origin = 20, Originator = 64511:192.0.2.1, Discrimina
<t tor = 1&gt;
hangText=" Candidate-path CP1 &lt;protocol-origin = 20, originat </dd>
or = 64511:192.0.2.1, discriminator = 1&gt;"/> <dt> Preference</dt>
<dd>200
<t hangText=" Preference 200"/> </dd>
<dt> Priority</dt>
<t hangText=" Priority 10"/> <dd>10
</dd>
<t <dt> Segment List 1 </dt>
hangText=" Segment List 1 &lt;SID11...SID1i&gt;, Weight W1" <dd>&lt;SID11...SID1i&gt;, Weight W1
/> </dd>
<dt> Segment List 2 </dt>
<t <dd>&lt;SID21...SID2j&gt;, Weight W2
hangText=" Segment List 2 &lt;SID21...SID2j&gt;, Weight W2" </dd>
/> <dt> Candidate Path CP2 </dt>
<dd>&lt;Protocol-Origin = 20, Originator = 64511:192.0.2.2, Discrimina
<t tor = 2&gt;
hangText=" Candidate-path CP2 &lt;protocol-origin = 20, originat </dd>
or = 64511:192.0.2.2, discriminator = 2&gt;"/> <dt> Preference</dt>
<dd>100
<t hangText=" Preference 100"/> </dd>
<dt> Priority</dt>
<t hangText=" Priority 10"/> <dd>10
</dd>
<t <dt> Segment List 3</dt>
hangText=" Segment List 3 &lt;SID31...SID3i&gt;, Weight W3" <dd> &lt;SID31...SID3i&gt;, Weight W3
/> </dd>
<dt> Segment List 4 </dt>
<t <dd>&lt;SID41...SID4j&gt;, Weight W4
hangText=" Segment List 4 &lt;SID41...SID4j&gt;, Weight W4" </dd>
/> </dl>
</list></t> <t>The SR Policy POL1 is identified by the tuple &lt;Headend, Color,
Endpoint&gt;. It has two candidate paths: CP1 and CP2. Each is
<t>The SR Policy POL1 is identified by the tuple &lt;headend, color, identified by a tuple &lt;Protocol-Origin, Originator,
endpoint&gt;. It has two candidate paths CP1 and CP2. Each is Discriminator&gt; within the scope of POL1. CP1 is the active
identified by a tuple &lt;protocol-origin, originator, candidate path (it is valid and has the highest Preference). The two
discriminator&gt; within the scope of POL1. CP1 is the active segment lists of CP1 are installed as the forwarding instantiation of
candidate path (it is valid and has the highest preference). The two SR Policy POL1. Traffic steered on POL1 is flow-based hashed on
Segment-Lists of CP1 are installed as the forwarding instantiation of segment list &lt;SID11...SID1i&gt; with a ratio W1/(W1+W2).</t>
SR policy POL1. Traffic steered on POL1 is flow-based hashed on
Segment-List &lt;SID11...SID1i&gt; with a ratio W1/(W1+W2).</t>
<t>The information model of SR Policy POL100 having a composite <t>The information model of SR Policy POL100 having a composite
candidate path is the following:</t> candidate path is the following:</t>
<dl newline="false" spacing="compact" indent="50">
<t><?rfc subcompact="yes"?> <list hangIndent="50" style="hanging"> <dt>SR Policy POL100 &lt;Headend = H1, Color = 100, Endpoint = E1&gt;<
<t /dt>
hangText="SR policy POL100 &lt;headend = H1, color = 100, endpoint = <dd/>
E1&gt;"/> <dt> Candidate Path CP1 &lt;Protocol-Origin = 20, Originator = 645
11:192.0.2.1, Discriminator = 1&gt;</dt>
<t <dd/>
hangText=" Candidate-path CP1 &lt;protocol-origin = 20, originat <dt> Preference 200</dt>
or = 64511:192.0.2.1, discriminator = 1&gt;"/> <dd/>
<dt> SR Policy &lt;Color = 1&gt;, Weight W1</dt>
<t hangText=" Preference 200"/> <dd/>
<dt> SR Policy &lt;Color = 2&gt;, Weight W2</dt>
<t hangText=" SR policy &lt;color = 1&gt;, Weight W1"/> <dd/>
</dl>
<t hangText=" SR policy &lt;color = 2&gt;, Weight W2"/>
</list></t>
<t>The constituent SR Policies POL1 and POL2 have an information model <t>The constituent SR Policies POL1 and POL2 have an information model
as described at the start of this section. They are referenced only by as described at the start of this section. They are referenced only by
color in the composite candidate path since their headend and endpoint color in the composite candidate path since their headend and endpoint
are identical to the POL100. The valid Segment-Lists of the active are identical to the POL100. The valid segment lists of the active
candidate path of POL1 and POL2 are installed in the forwarding. candidate path of POL1 and POL2 are installed in the forwarding.
Traffic steered on POL100 is flow-based hashed on POL1 with a Traffic steered on POL100 is hashed on a per-flow basis on POL1 with a
proportion W1/(W1+W2). Within the POL1, the flow-based hashing over proportion W1/(W1+W2). Within the POL1, the flow-based hashing over
its Segment-Lists are performed as described earlier in this its segment lists are performed as described earlier in this
section.</t> section.</t>
</section> </section>
</section> </section>
<section anchor="SR-database" numbered="true" toc="default">
<section anchor="SR-database" title="Segment Routing Database"> <name>Segment Routing Database</name>
<t>An SR Policy computation node (e.g. headend or controller) maintains <t>An SR Policy computation node (e.g., headend or controller) maintains
the Segment Routing Database (SR-DB). The SR-DB is a conceptual database the Segment Routing Database (SR-DB). The SR-DB is a conceptual database
to illustrate the various pieces of information and their sources that to illustrate the various pieces of information and their sources that
may help in SR Policy computation and validation. There is no specific may help in SR Policy computation and validation. There is no specific
requirement for an implementation to create a new database as such.</t> requirement for an implementation to create a new database as such.</t>
<t>An SR headend leverages the SR-DB to validate explicit candidate <t>An SR headend leverages the SR-DB to validate explicit candidate
paths and compute dynamic candidate paths.</t> paths and compute dynamic candidate paths.</t>
<t>The information in the SR-DB may include: </t>
<t>The information in the SR-DB may include: <list style="symbols"> <ul spacing="compact">
<t>IGP information (topology, IGP metrics based on IS-IS <xref <li>IGP information (topology, IGP metrics based on IS-IS <xref target="
target="RFC1195"/> and OSPF <xref target="RFC2328"/> <xref RFC1195" format="default"/> and OSPF <xref target="RFC2328" format="default"/> <
target="RFC5340"/>)</t> xref target="RFC5340" format="default"/>)</li>
<li>Segment Routing information (such as Segment Routing Global
<t>Segment Routing information (such as Segment Routing Global
Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP
Peering SID, SRv6 SIDs) <xref target="RFC8402"/> <xref Peering SID, SRv6 SIDs) <xref target="RFC8402" format="default"/> <xre
target="RFC8986"/></t> f target="RFC8986" format="default"/></li>
<li>TE Link Attributes (such as TE metric, Shared Risk Link Groups,
<t>TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group) <xref target="RFC5305" format="d
attribute-flag, extended admin group) <xref target="RFC5305"/> <xref efault"/> <xref target="RFC3630" format="default"/> <xref target="RFC5329" forma
target="RFC3630"/> <xref target="RFC5329"/>.</t> t="default"/></li>
<li>Extended TE Link attributes (such as latency, loss) <xref target="RF
<t>Extended TE Link attributes (such as latency, loss) <xref C8570" format="default"/> <xref target="RFC7471" format="default"/></li>
target="RFC8570"/> <xref target="RFC7471"/></t> <li>Inter-AS Topology information <xref target="RFC9086" format="default
"/></li>
<t>Inter-AS Topology information <xref target="RFC9086"/>.</t> </ul>
</list></t>
<t>The attached domain topology may be learned via protocol/mechanisms <t>The attached domain topology may be learned via protocol/mechanisms
such as IGP, BGP-LS or NETCONF.</t> such as IGP, Border Gateway Protocol - Link State (BGP-LS), or NETCONF.</t
>
<t>A non-attached (remote) domain topology may be learned via <t>A non-attached (remote) domain topology may be learned via
protocol/mechanisms such as BGP-LS or NETCONF.</t> protocol/mechanisms such as BGP-LS or NETCONF.</t>
<t>In some use cases, the SR-DB may only contain the attached domain
<t>In some use-cases, the SR-DB may only contain the attached domain
topology while in others, the SR-DB may contain the topology of multiple topology while in others, the SR-DB may contain the topology of multiple
domains and in this case, it is multi-domain capable.</t> domains and in this case, it is multi-domain capable.</t>
<t>The SR-DB may also contain the SR Policies instantiated in the <t>The SR-DB may also contain the SR Policies instantiated in the
network. This can be collected via BGP-LS <xref network. This can be collected via BGP-LS <xref
target="I-D.ietf-idr-te-lsp-distribution"/> or PCEP <xref target="I-D.ietf-idr-te-lsp-distribution" format="default"/> or PCEP
target="RFC8231"/>, <xref <xref target="RFC8231" format="default"/> (along with <xref
target="I-D.ietf-pce-segment-routing-policy-cp"/>, and <xref target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> and
target="I-D.ietf-pce-binding-label-sid"/>. This information allows to <xref target="I-D.ietf-pce-binding-label-sid" format="default"/>). This
build an end-to-end policy on the basis of intermediate SR policies (see information allows to build an end-to-end policy on the basis of
<xref target="Binding-SID"/> for further details).</t> intermediate SR policies (see <xref target="Binding-SID"
format="default"/> for further details).</t>
<t>The SR-DB may also contain the Maximum SID Depth (MSD) capability of <t>The SR-DB may also contain the Maximum SID Depth (MSD) capability of
nodes in the topology. This can be collected via IS-IS <xref nodes in the topology. This can be collected via IS-IS <xref target="RFC84
target="RFC8491"/>, OSPF <xref target="RFC8476"/>, BGP-LS <xref 91" format="default"/>, OSPF <xref target="RFC8476" format="default"/>, BGP-LS <
target="RFC8814"/> or PCEP <xref target="RFC8664"/>.</t> xref target="RFC8814" format="default"/>, or PCEP <xref target="RFC8664" format=
"default"/>.</t>
<t>The use of the SR-DB for path computation and for the validation of <t>The use of the SR-DB for path computation and for the validation of
optimization objective and constraints of paths is outside the scope of optimization objective and constraints of paths is outside the scope of
this document. Some implementation aspects related to path computation this document. Some implementation aspects related to path computation
are covered in <xref are covered in <xref target="I-D.filsfils-spring-sr-policy-considerations"
target="I-D.filsfils-spring-sr-policy-considerations"/>.</t> format="default"/>.</t>
</section> </section>
<section anchor="SID-List" numbered="true" toc="default">
<section anchor="SID-List" title="Segment Types"> <name>Segment Types</name>
<t>A Segment-List is an ordered set of segments represented as &lt;S1, <t>A segment list is an ordered set of segments represented as &lt;S1,
S2, ... Sn&gt; where S1 is the first segment.</t> S2, ... Sn&gt; where S1 is the first segment.</t>
<t>Based on the desired data plane, either the MPLS label stack or the
<t>Based on the desired dataplane, either the MPLS label stack or the SRv6 Segment Routing Header <xref target="RFC8754" format="default"/> is b
SRv6 Segment Routing Header <xref target="RFC8754"/> is built from the uilt from the
Segment-List. However, the Segment-List itself can be specified using segment list. However, the segment list itself can be specified using
different segment-descriptor types and the following are currently different segment-descriptor types and the following are currently
defined:</t> defined:</t>
<dl newline="true" spacing="compact" indent="6">
<dt>Type A: SR-MPLS Label:</dt>
<t><list hangIndent="6" style="hanging"> <dd>
<t hangText="Type A: SR-MPLS Label:"><vspace/>An MPLS label <t>An MPLS label
corresponding to any of the segment types defined for SR-MPLS (as corresponding to any of the segment types defined for SR-MPLS (as
defined in <xref target="RFC8402"/> or other SR-MPLS specifications) defined in <xref target="RFC8402" format="default"/> or other SR-MPLS specifications)
can be used. Additionally, special purpose labels like explicit-null can be used. Additionally, special purpose labels like explicit-null
or in general any MPLS label MAY also be used. E.g. this type can be or in general any MPLS label <bcp14>MAY</bcp14> also be used. For exam ple, this type can be
used to specify a label representation that maps to an optical used to specify a label representation that maps to an optical
transport path on a packet transport node. <vspace transport path on a packet transport node. </t>
blankLines="1"/></t> <t/>
</dd>
<t hangText="Type B: SRv6 SID:"><vspace/>An IPv6 address <dt>Type B: SRv6 SID:</dt>
<dd>
<t>An IPv6 address
corresponding to any of the SID behaviors for SRv6 (as defined in corresponding to any of the SID behaviors for SRv6 (as defined in
<xref target="RFC8986"/> or other SRv6 specifications) can be used. <xref target="RFC8986" format="default"/> or other SRv6 specifications
Optionally, the SRv6 SID behavior (as defined in <xref ) can be used.
target="RFC8986"/> or other SRv6 specifications) and structure (as Optionally, the SRv6 SID behavior (as defined in <xref target="RFC8986
defined in <xref target="RFC8986"/>) MAY also be provided for the " format="default"/> or other SRv6 specifications) and structure (as
defined in <xref target="RFC8986" format="default"/>) <bcp14>MAY</bcp1
4> also be provided for the
headend to perform validation of the SID when using it for building headend to perform validation of the SID when using it for building
the Segment List.<vspace blankLines="1"/></t> the segment list.</t>
<t/>
<t </dd>
hangText="Type C: IPv4 Prefix with optional SR Algorithm:"><vspace/>In <dt>Type C: IPv4 Prefix with optional SR Algorithm:</dt>
<dd>
<t>In
this case, the headend is required to resolve the specified IPv4 this case, the headend is required to resolve the specified IPv4
Prefix Address to the SR-MPLS label corresponding to its Prefix SID Prefix Address to the SR-MPLS label corresponding to its Prefix SID
segment (as defined in <xref target="RFC8402"/>). The SR algorithm segment (as defined in <xref target="RFC8402" format="default"/>). The
(refer to Section 3.1.1 of <xref target="RFC8402"/>) to be used MAY SR algorithm
also be provided. <vspace blankLines="1"/></t> (refer to <xref target="RFC8402" sectionFormat="of" section="3.1.1" fo
rmat="default"/>) to be used <bcp14>MAY</bcp14>
<t also be provided. </t>
hangText="Type D: IPv6 Global Prefix with optional SR Algorithm for SR <t/>
-MPLS:"><vspace/>In </dd>
<dt>Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:</
dt>
<dd>
<t>In
this case, the headend is required to resolve the specified IPv6 this case, the headend is required to resolve the specified IPv6
Global Prefix Address to the SR-MPLS label corresponding to its Global Prefix Address to the SR-MPLS label corresponding to its
Prefix SID segment (as defined in <xref target="RFC8402"/>). The SR Prefix SID segment (as defined in <xref target="RFC8402" format="defau
Algorithm (refer to Section 3.1.1 of <xref target="RFC8402"/>) to be lt"/>). The SR
used MAY also be provided. <vspace blankLines="1"/></t> Algorithm (refer to <xref target="RFC8402" sectionFormat="of" section=
"3.1.1" format="default"/>) to be
<t used <bcp14>MAY</bcp14> also be provided. </t>
hangText="Type E: IPv4 Prefix with Local Interface ID:"><vspace/>This <t/>
type allows identification of Adjacency SID or BGP Peer Adjacency </dd>
SID (as defined in <xref target="RFC8402"/>) SR-MPLS label for <dt>Type E: IPv4 Prefix with Local Interface ID:</dt>
<dd>
<t>This
type allows for identification of an Adjacency SID or BGP Peer Adjacen
cy
SID (as defined in <xref target="RFC8402" format="default"/>) SR-MPLS
label for
point-to-point links including IP unnumbered links. The headend is point-to-point links including IP unnumbered links. The headend is
required to resolve the specified IPv4 Prefix Address to the Node required to resolve the specified IPv4 Prefix Address to the node
originating it and then use the Local Interface ID to identify the originating it and then use the Local Interface ID to identify the
point-to-point link whose adjacency is being referred to. The Local point-to-point link whose adjacency is being referred to. The Local
Interface ID link descriptor follows semantics as specified in <xref Interface ID link descriptor follows semantics as specified in <xref t
target="RFC5307"/>. This type can also be used to indicate arget="RFC5307" format="default"/>. This type can also be used to indicate
indirection into a layer 2 interface (i.e., without IP address) like indirection into a layer 2 interface (i.e., without IP address) like
a representation of an optical transport path or a layer 2 Ethernet a representation of an optical transport path or a layer 2 Ethernet
port or circuit at the specified node. <vspace blankLines="1"/></t> port or circuit at the specified node. </t>
<t/>
<t </dd>
hangText="Type F: IPv4 Addresses for link endpoints as Local, Remote p <dt>Type F: IPv4 Addresses for link endpoints as Local, Remote pair:</dt
air:"><vspace/>This >
type allows identification of Adjacency SID or BGP Peer Adjacency <dd>
SID (as defined in <xref target="RFC8402"/>) SR-MPLS label for <t>This
type allows for identification of an Adjacency SID or BGP Peer Adjacen
cy
SID (as defined in <xref target="RFC8402" format="default"/>) SR-MPLS
label for
links. The headend is required to resolve the specified IPv4 Local links. The headend is required to resolve the specified IPv4 Local
Address to the Node originating it and then use the IPv4 Remote Address to the node originating it and then use the IPv4 Remote
Address to identify the link adjacency being referred to. The Local Address to identify the link adjacency being referred to. The Local
and Remote Address pair link descriptors follow semantics as and Remote Address pair link descriptors follow semantics as
specified in <xref target="RFC7752"/>. <vspace blankLines="1"/></t> specified in <xref target="RFC7752" format="default"/>. </t>
<t/>
<t </dd>
hangText="Type G: IPv6 Prefix and Interface ID for link endpoints as L <dt>Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Re
ocal, Remote pair for SR-MPLS:"><vspace/>This mote pair for SR-MPLS:</dt>
type allows identification of Adjacency SID or BGP Peer Adjacency <dd>
SID (as defined in <xref target="RFC8402"/>) label for links <t>This
type allows for identification of an Adjacency SID or BGP Peer Adjacen
cy
SID (as defined in <xref target="RFC8402" format="default"/>) label fo
r links
including those with only Link-Local IPv6 addresses. The headend is including those with only Link-Local IPv6 addresses. The headend is
required to resolve the specified IPv6 Prefix Address to the Node required to resolve the specified IPv6 Prefix Address to the node
originating it and then use the Local Interface ID to identify the originating it and then use the Local Interface ID to identify the
point-to-point link whose adjacency is being referred to. For other point-to-point link whose adjacency is being referred to. For other
than point-to-point links, additionally the specific adjacency over than point-to-point links, additionally the specific adjacency over
the link needs to be resolved using the Remote Prefix and Interface the link needs to be resolved using the Remote Prefix and Interface
ID. The Local and Remote pair of Prefix and Interface ID link ID. The Local and Remote pair of Prefix and Interface ID link
descriptor follows semantics as specified in <xref descriptor follows semantics as specified in <xref target="RFC7752" fo
target="RFC7752"/>. This type can also be used to indicate rmat="default"/>. This type can also be used to indicate
indirection into a layer 2 interface (i.e., without IP address) like indirection into a layer 2 interface (i.e., without IP address) like
a representation of an optical transport path or a layer 2 Ethernet a representation of an optical transport path or a layer 2 Ethernet
port or circuit at the specified node. <vspace blankLines="1"/></t> port or circuit at the specified node. </t>
<t/>
<t </dd>
hangText="Type H: IPv6 Addresses for link endpoints as Local, Remote p <dt>Type H: IPv6 Addresses for link endpoints as Local, Remote pair for
air for SR-MPLS:"><vspace/>This SR-MPLS:</dt>
type allows identification of Adjacency SID or BGP Peer Adjacency <dd>
SID (as defined in <xref target="RFC8402"/>) label for links with <t>This
type allows for identification of an Adjacency SID or BGP Peer Adjacen
cy
SID (as defined in <xref target="RFC8402" format="default"/>) label fo
r links with
Global IPv6 addresses. The headend is required to resolve the Global IPv6 addresses. The headend is required to resolve the
specified Local IPv6 Address to the Node originating it and then use specified Local IPv6 Address to the node originating it and then use
the Remote IPv6 Address to identify the link adjacency being the Remote IPv6 Address to identify the link adjacency being
referred to. The Local and Remote Address pair link descriptors referred to. The Local and Remote Address pair link descriptors
follow semantics as specified in <xref target="RFC7752"/>. <vspace follow semantics as specified in <xref target="RFC7752" format="defaul
blankLines="1"/></t> t"/>. </t>
<t/>
<t </dd>
hangText="Type I: IPv6 Global Prefix with optional SR Algorithm for SR <dt>Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6:</dt>
v6:"><vspace/>The <dd>
<t>The
headend is required to resolve the specified IPv6 Global Prefix headend is required to resolve the specified IPv6 Global Prefix
Address to an SRv6 SID corresponding to a Prefix SID segment (as Address to an SRv6 SID corresponding to a Prefix SID segment (as
defined in <xref target="RFC8402"/>), such as a SID associated with defined in <xref target="RFC8402" format="default"/>), such as a SID a
the End behavior (as defined in <xref target="RFC8986"/>) of the ssociated with
node which is originating the prefix. The SR Algorithm (refer to the End behavior (as defined in <xref target="RFC8986" format="default
Section 3.1.1 of <xref target="RFC8402"/>), the SRv6 SID behavior "/>) of the
(as defined in <xref target="RFC8986"/> or other SRv6 node that is originating the prefix. The SR Algorithm (refer to
specifications) and structure (as defined in <xref <xref target="RFC8402" sectionFormat="of" section="3.1.1" format="defa
target="RFC8986"/>) MAY also be provided.<vspace ult"/>), the SRv6 SID behavior
blankLines="1"/></t> (as defined in <xref target="RFC8986" format="default"/> or other SRv6
specifications), and structure (as defined in <xref target="RFC8986" f
<t ormat="default"/>) <bcp14>MAY</bcp14> also be provided.</t>
hangText="Type J: IPv6 Prefix and Interface ID for link endpoints as L <t/>
ocal, Remote pair for SRv6:"><vspace/>This </dd>
type allows identification of an SRv6 SID corresponding to an <dt>Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Re
Adjacency SID or BGP Peer Adjacency SID (as defined in <xref mote pair for SRv6:</dt>
target="RFC8402"/>), such as a SID associated with the End.X <dd>
behavior (as defined in <xref target="RFC8986"/>) associated with <t>This
type allows for identification of an SRv6 SID corresponding to an
Adjacency SID or BGP Peer Adjacency SID (as defined in <xref target="R
FC8402" format="default"/>), such as a SID associated with the End.X
behavior (as defined in <xref target="RFC8986" format="default"/>) ass
ociated with
link or adjacency with only Link-Local IPv6 addresses. The headend link or adjacency with only Link-Local IPv6 addresses. The headend
is required to resolve the specified IPv6 Prefix Address to the Node is required to resolve the specified IPv6 Prefix Address to the node
originating it and then use the Local Interface ID to identify the originating it and then use the Local Interface ID to identify the
point-to-point link whose adjacency is being referred to. For other point-to-point link whose adjacency is being referred to. For other
than point-to-point links, additionally the specific adjacency needs than point-to-point links, additionally the specific adjacency needs
to be resolved using the Remote Prefix and Interface ID. The Local to be resolved using the Remote Prefix and Interface ID. The Local
and Remote pair of Prefix and Interface ID link descriptor follows and Remote pair of Prefix and Interface ID link descriptor follows
semantics as specified in <xref target="RFC7752"/>. The SR Algorithm semantics as specified in <xref target="RFC7752" format="default"/>. T
(refer to Section 3.1.1 of <xref target="RFC8402"/>), the SRv6 SID he SR Algorithm
behavior (as defined in <xref target="RFC8986"/> or other SRv6 (refer to <xref target="RFC8402" sectionFormat="of" section="3.1.1" fo
specifications) and structure (as defined in <xref rmat="default"/>), the SRv6 SID
target="RFC8986"/>) MAY also be provided.<vspace behavior (as defined in <xref target="RFC8986" format="default"/> or o
blankLines="1"/></t> ther SRv6
specifications), and structure (as defined in <xref target="RFC8986" f
<t ormat="default"/>) <bcp14>MAY</bcp14> also be provided.</t>
hangText="Type K: IPv6 Addresses for link endpoints as Local, Remote p <t/>
air for SRv6:"><vspace/>This </dd>
type allows identification of an SRv6 SID corresponding to an <dt>Type K: IPv6 Addresses for link endpoints as Local, Remote pair for
Adjacency SID or BGP Peer Adjacency SID (as defined in <xref SRv6:</dt>
target="RFC8402"/>), such as a SID associated with the End.X <dd>
behavior (as defined in <xref target="RFC8986"/>) associated with <t>This type allows for identification of an SRv6 SID corresponding to
link or adjacency with Global IPv6 addresses. The headend is an Adjacency SID or BGP Peer Adjacency SID (as defined in <xref
required to resolve the specified Local IPv6 Address to the Node target="RFC8402" format="default"/>), such as a SID associated with
originating it and then use the Remote IPv6 Address to identify the the End.X behavior (as defined in <xref target="RFC8986"
link adjacency being referred to. The Local and Remote Address pair format="default"/>) associated with link or adjacency with Global
link descriptors follow semantics as specified in <xref IPv6 addresses. The headend is required to resolve the specified
target="RFC7752"/>. The SR Algorithm (refer to Section 3.1.1 of Local IPv6 Address to the node originating it and then use the
<xref target="RFC8402"/>), the SRv6 SID behavior (as defined in Remote IPv6 Address to identify the link adjacency being referred
<xref target="RFC8986"/> or other SRv6 specifications) and structure to. The Local and Remote Address pair link descriptors follow
(as defined in <xref target="RFC8986"/>) MAY also be semantics as specified in <xref target="RFC7752"
provided.<vspace blankLines="1"/></t> format="default"/>. The SR Algorithm (refer to <xref
</list></t> target="RFC8402" sectionFormat="of" section="3.1.1"
format="default"/>), the SRv6 SID behavior (as defined in <xref
target="RFC8986" format="default"/> or other SRv6 specifications),
and structure (as defined in <xref target="RFC8986"
format="default"/>) <bcp14>MAY</bcp14> also be provided.</t>
<t/>
</dd>
</dl>
<t>When the algorithm is not specified for the SID types above which <t>When the algorithm is not specified for the SID types above which
optionally allow for it, the headend SHOULD use the Strict Shortest Path optionally allow for it, the headend <bcp14>SHOULD</bcp14> use the Strict
algorithm if available and otherwise, it SHOULD use the default Shortest Shortest Path
Path algorithm. The specification of the algorithm enables the use of algorithm if available and otherwise, it <bcp14>SHOULD</bcp14> use the def
the IGP Flex Algorithm <xref target="I-D.ietf-lsr-flex-algo"/> specific ault Shortest
SIDs in SR Policy.</t> Path algorithm.
<t>For SID types C-through-K, a SID value MAY also be optionally
provided to the headend for verification purposes. <xref
target="Path-validity-explicit"/>. describes the resolution and
verification of the SIDs and Segment Lists on the headend.</t>
<t>When building the MPLS label stack or the IPv6 Segment list from the
Segment List, the node instantiating the policy MUST interpret the set
of Segments as follows: <list style="symbols">
<t>The first Segment represents the topmost label or the first IPv6
segment. It identifies the active segment the traffic will be
directed toward along the explicit SR path.</t>
<t>The last Segment represents the bottommost label or the last IPv6 The specification of the algorithm enables the use of SIDs specific to
segment the traffic will be directed toward along the explicit SR the IGP Flex Algorithm <xref target="I-D.ietf-lsr-flex-algo"
path.</t> format="default"/> in SR Policy.</t>
</list></t>
<section anchor="Explicit-Null" title="Explicit Null"> <t>For SID types C through K, a SID value <bcp14>MAY</bcp14> also be optio
<t>A Type A SID MAY be any MPLS label, including special purpose nally
provided to the headend for verification purposes. <xref target="Path-vali
dity-explicit" format="default"/> describes the resolution and
verification of the SIDs and segment lists on the headend.</t>
<t>When building the MPLS label stack or the SRv6 SID list from the
segment list, the node instantiating the policy <bcp14>MUST</bcp14> interp
ret the set
of Segments as follows: </t>
<ul spacing="compact">
<li>The first Segment represents the topmost MPLS label or the first
SRv6 SID. It identifies the active segment the traffic will be
directed toward along the explicit SR path.</li>
<li>The last segment represents the bottommost MPLS label or the last
SRv6 SID the traffic will be directed toward along the explicit SR
path.</li>
</ul>
<section anchor="Explicit-Null" numbered="true" toc="default">
<name>Explicit Null</name>
<t>A Type A SID <bcp14>MAY</bcp14> be any MPLS label, including special
purpose
labels.</t> labels.</t>
<t>For example, assuming that the desired traffic-engineered path from <t>For example, assuming that the desired traffic-engineered path from
a headend 1 to an endpoint 4 can be expressed by the Segment-List a headend 1 to an endpoint 4 can be expressed by the segment list
&lt;16002, 16003, 16004&gt; where 16002, 16003 and 16004 respectively &lt;16002, 16003, 16004&gt; where 16002, 16003, and 16004, respectively,
refer to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 refer to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6
traffic can be traffic-engineered from nodes 1 to 4 via the previously traffic can be traffic-engineered from nodes 1 to 4 via the previously
described path using an SR Policy with Segment-List &lt;16002, 16003, described path using an SR Policy with segment list &lt;16002, 16003,
16004, 2&gt; where the MPLS label value of 2 represents the "IPv6 16004, 2&gt; where the MPLS label value of 2 represents the "IPv6
Explicit NULL Label".</t> Explicit NULL Label".</t>
<t>The penultimate node before node 4 will pop 16004 and will forward <t>The penultimate node before node 4 will pop 16004 and will forward
the frame on its directly connected interface to node 4.</t> the frame on its directly connected interface to node 4.</t>
<t>The endpoint receives the traffic with the top label "2", which
<t>The endpoint receives the traffic with the top label "2" which
indicates that the payload is an IPv6 packet.</t> indicates that the payload is an IPv6 packet.</t>
<t>When steering unlabeled IPv6 BGP destination traffic using an SR <t>When steering unlabeled IPv6 BGP destination traffic using an SR
policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit Policy composed of segment list(s) based on IPv4 SIDs, the Explicit
Null Label Policy is processed as specified in <xref Null Label Policy is processed as specified in <xref target="I-D.ietf-id
target="I-D.ietf-idr-segment-routing-te-policy"/>) Section 2.4.5. When r-segment-routing-te-policy" format="default"/>. When
an &ldquo;IPv6 Explicit NULL label&rdquo; is not present as the bottom an "IPv6 Explicit NULL label" is not present as the bottom
label, the headend SHOULD automatically impose one. Refer to <xref label, the headend <bcp14>SHOULD</bcp14> automatically impose one. Refer
target="Steering"/> for more details.</t> to <xref target="Steering" format="default"/> for more details.</t>
</section> </section>
</section> </section>
<section anchor="Path-validity" numbered="true" toc="default">
<section anchor="Path-validity" title="Validity of a Candidate Path"> <name>Validity of a Candidate Path</name>
<section anchor="Path-validity-explicit" title="Explicit Candidate Path"> <section anchor="Path-validity-explicit" numbered="true" toc="default">
<t>An explicit candidate path is associated with a Segment-List or a <name>Explicit Candidate Path</name>
set of Segment-Lists.</t> <t>An explicit candidate path is associated with a segment list or a
set of segment lists.</t>
<t>An explicit candidate path is provisioned by the operator directly <t>An explicit candidate path is provisioned by the operator directly
or via a controller.</t> or via a controller.</t>
<t>The computation/logic that leads to the choice of the segment list
<t>The computation/logic that leads to the choice of the Segment-List
is external to the SR Policy headend. The SR Policy headend does not is external to the SR Policy headend. The SR Policy headend does not
compute the Segment-List. The SR Policy headend only confirms its compute the segment list. The SR Policy headend only confirms its
validity.</t> validity.</t>
<t>An explicit candidate path <bcp14>MAY</bcp14> consist of a single exp
<t>An explicit candidate path MAY consist of a single explicit licit
Segment-List containing only an implicit-null label to indicate segment list containing only an implicit-null label to indicate
pop-and-forward behavior. The Binding SID (BSID) is popped and the pop-and-forward behavior. The Binding SID (BSID) is popped and the
traffic is forwarded based on the inner label or an IP lookup in the traffic is forwarded based on the inner label or an IP lookup in the
case of unlabeled IP packets. Such an explicit path can serve as a case of unlabeled IP packets. Such an explicit path can serve as a
fallback or path of last resort for traffic being steered into an SR fallback or path of last resort for traffic being steered into an SR
Policy using its BSID (refer to Section 8.3).</t> Policy using its BSID (refer to <xref target="Steering-Incoming-BSID"/>)
.</t>
<t>A Segment-List of an explicit candidate path MUST be declared <t>A segment list of an explicit candidate path <bcp14>MUST</bcp14> be d
invalid when any of the following is true: <list style="symbols"> eclared
<t>It is empty.</t> invalid when any of the following is true: </t>
<ul spacing="compact">
<t>Its weight is 0.</t> <li>It is empty.</li>
<li>Its weight is 0.</li>
<t>It comprises a mix of SR-MPLS and SRv6 segment types.</t> <li>It comprises a mix of SR-MPLS and SRv6 segment types.</li>
<li>The headend is unable to perform path resolution for the first
<t>The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s).</li>
SID into one or more outgoing interface(s) and next-hop(s).</t> <li>The headend is unable to perform SID resolution for any
non-first SID of type C through K into an MPLS label or an SRv6
<t>The headend is unable to perform SID resolution for any SID.</li>
non-first SID of type C-through-K into an MPLS label or an SRv6 <li>The headend verification fails for any SID for which
SID.</t> verification has been explicitly requested.</li>
</ul>
<t>The headend verification fails for any SID for which
verification has been explicitly requested.</t>
</list></t>
<t>"Unable to perform path resolution" means that the headend has no <t>"Unable to perform path resolution" means that the headend has no
path to the SID in its SR database.</t> path to the SID in its SR database.</t>
<t>SID verification is performed when the headend is explicitly <t>SID verification is performed when the headend is explicitly
requested to verify SID(s) by the controller via the signaling requested to verify SID(s) by the controller via the signaling
protocol used. Implementations MAY provide a local configuration protocol used. Implementations <bcp14>MAY</bcp14> provide a local config
option to enable verification on a global or per policy or per uration
candidate path basis.</t> option to enable verification on a global or per-policy or per-candidate
path basis.</t>
<t>"Verification fails" for a SID means any of the following:<list <t>"Verification fails" for a SID means any of the following:</t>
style="symbols"> <ul spacing="compact">
<t>The headend is unable to find the SID in its SR-DB</t> <li>The headend is unable to find the SID in its SR-DB</li>
<li>The headend detects a mismatch between the SID value provided
<t>The headend detects a mismatch between the SID value provided
and the SID value resolved by context provided for SIDs of type and the SID value resolved by context provided for SIDs of type
C-through-K in its SR-DB.</t> C through K in its SR-DB.</li>
<li>The headend is unable to perform SID resolution for any
<t>The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6
non-first SID of type C-through-K into an MPLS label or an SRv6 SID.</li>
SID.</t> </ul>
</list></t>
<t>In multi-domain deployments, it is expected that the headend may be <t>In multi-domain deployments, it is expected that the headend may be
unable to verify the reachability of the SIDs in remote domains. Types unable to verify the reachability of the SIDs in remote domains. Types
A or B MUST be used for the SIDs for which the reachability cannot be A or B <bcp14>MUST</bcp14> be used for the SIDs for which the reachabili
verified. Note that the first SID MUST always be reachable regardless ty cannot be
verified. Note that the first SID <bcp14>MUST</bcp14> always be reachabl
e regardless
of its type.</t> of its type.</t>
<t>Additionally, a segment list <bcp14>MAY</bcp14> be declared invalid w
<t>Additionally, a Segment-List MAY be declared invalid when both of hen both of
the conditions below are met : <list style="symbols"> the conditions below are met : </t>
<t>Its last segment is not a Prefix SID (including BGP Peer <ul spacing="compact">
<li>Its last segment is not a Prefix SID (including BGP Peer
Node-SID) advertised by the node specified as the endpoint of the Node-SID) advertised by the node specified as the endpoint of the
corresponding SR policy.</t> corresponding SR Policy.</li>
<li>Its last segment is not an Adjacency SID (including BGP Peer
<t>Its last segment is not an Adjacency SID (including BGP Peer
Adjacency SID) of any of the links present on neighbor nodes and Adjacency SID) of any of the links present on neighbor nodes and
that terminate on the node specified as the endpoint of the that terminate on the node specified as the endpoint of the
corresponding SR policy.</t> corresponding SR Policy.</li>
</list></t> </ul>
<t>An explicit candidate path is invalid as soon as it has no valid <t>An explicit candidate path is invalid as soon as it has no valid
Segment-List.</t> segment list.</t>
<t>Additionally, an explicit candidate path <bcp14>MAY</bcp14> be declar
<t>Additionally, an explicit candidate path MAY be declared invalid ed invalid
when its constituent segment lists (valid or invalid) are using when its constituent segment lists (valid or invalid) are using
segment types of different SR data planes.</t> segment types of different SR data planes.</t>
</section> </section>
<section anchor="Path-validity-dynamic" numbered="true" toc="default">
<section anchor="Path-validity-dynamic" title="Dynamic Candidate Path"> <name>Dynamic Candidate Path</name>
<t>A dynamic candidate path is specified as an optimization objective <t>A dynamic candidate path is specified as an optimization objective
and constraints.</t> and a set of constraints.</t>
<t>The headend of the policy leverages its SR database to compute a <t>The headend of the policy leverages its SR database to compute a
Segment-List ("solution Segment-List") that solves this optimization segment list ("solution segment list") that solves this optimization
problem for either the SR-MPLS or the SRv6 data-plane as problem for either the SR-MPLS or the SRv6 data plane as
specified.</t> specified.</t>
<t>The headend re-computes the solution segment list any time the
<t>The headend re-computes the solution Segment-List any time the
inputs to the problem change (e.g., topology changes).</t> inputs to the problem change (e.g., topology changes).</t>
<t>When the local computation is not possible (e.g., a policy's <t>When the local computation is not possible (e.g., a policy's
tail-end is outside the topology known to the headend) or not desired, tail end is outside the topology known to the headend) or not desired,
the headend may rely on an external entity. For example, a path the headend may rely on an external entity. For example, a path
computation request may be sent to a PCE supporting PCEP extensions computation request may be sent to a PCE supporting PCEP extensions
specified in <xref target="RFC8664"/>.</t> specified in <xref target="RFC8664" format="default"/>.</t>
<t>If no solution is found to the optimization objective and <t>If no solution is found to the optimization objective and
constraints, then the dynamic candidate path MUST be declared constraints, then the dynamic candidate path <bcp14>MUST</bcp14> be decl ared
invalid.</t> invalid.</t>
<t><xref target="I-D.filsfils-spring-sr-policy-considerations" format="d
<t>Section 3 of <xref efault"/> discusses some
target="I-D.filsfils-spring-sr-policy-considerations"/> discusses some
of the optimization objectives and constraints that may be considered of the optimization objectives and constraints that may be considered
by a dynamic candidate path. It illustrates some of the desirable by a dynamic candidate path. It illustrates some of the desirable
properties of the computation of the solution Segment-List.</t> properties of the computation of the solution segment list.</t>
</section> </section>
<section anchor="Path-validity-composite" numbered="true" toc="default">
<section anchor="Path-validity-composite" <name>Composite Candidate Path</name>
title="Composite Candidate Path">
<t>A composite candidate path is specified as a group of its <t>A composite candidate path is specified as a group of its
constituent SR Policies.</t> constituent SR Policies.</t>
<t>A composite candidate path is valid when it has at least one valid <t>A composite candidate path is valid when it has at least one valid
constituent SR Policy.</t> constituent SR Policy.</t>
</section> </section>
</section> </section>
<section anchor="Binding-SID" numbered="true" toc="default">
<name>Binding SID</name>
<section anchor="Binding-SID" title="Binding SID"> <t>The Binding SID (BSID) is fundamental to Segment Routing <xref target="
<t>The Binding SID (BSID) is fundamental to Segment Routing <xref RFC8402" format="default"/>. It provides scaling, network opacity, and service
target="RFC8402"/>. It provides scaling, network opacity, and service independence. <xref target="I-D.filsfils-spring-sr-policy-considerations"
independence. Section 6 of <xref format="default"/> illustrates some
target="I-D.filsfils-spring-sr-policy-considerations"/> illustrates some
of these benefits. This section describes the association of BSID with of these benefits. This section describes the association of BSID with
an SR Policy.</t> an SR Policy.</t>
<section anchor="Binding-SID-candidate-path" numbered="true" toc="default"
<section anchor="Binding-SID-candidate-path" >
title="BSID of a candidate path"> <name>BSID of a Candidate Path</name>
<t>Each candidate path MAY be defined with a BSID.</t> <t>Each candidate path <bcp14>MAY</bcp14> be defined with a BSID.</t>
<t>Candidate paths of the same SR Policy <bcp14>SHOULD</bcp14> have the
<t>Candidate Paths of the same SR policy SHOULD have the same same
BSID.</t> BSID.</t>
<t>Candidate paths of different SR Policies <bcp14>MUST NOT</bcp14> have
<t>Candidate Paths of different SR policies MUST NOT have the same the same
BSID.</t> BSID.</t>
</section> </section>
<section anchor="Binding-SID-sr-policy" numbered="true" toc="default">
<section anchor="Binding-SID-sr-policy" title="BSID of an SR Policy"> <name>BSID of an SR Policy</name>
<t>The BSID of an SR Policy is the BSID of its active candidate <t>The BSID of an SR Policy is the BSID of its active candidate
path.</t> path.</t>
<t>When the active candidate path has a specified BSID, the SR Policy <t>
uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is When the active candidate path has a specified BSID, the SR Policy
available (i.e., not associated with any other usage: e.g. label used uses that BSID if this value (label in MPLS, IPv6 address in SRv6)
by some other MPLS forwarding entry, SRv6 SID used in some other is available. A BSID is available when its value is not associated
context, to another SID, to another SR Policy, outside the range of with any other usage, e.g., a label used by some other MPLS
SRv6 Locators).</t> forwarding entry or an SRv6 SID used in some other context (such as
to another segment, to another SR Policy, or that it is outside the
range of SRv6 Locators).
</t>
<t>In the case of SR-MPLS, SRv6 BSIDs (e.g. with the behavior End.BM <t>In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM
<xref target="RFC8986"/>) MAY be associated with the SR Policy in <xref target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> be associa
ted with the SR Policy in
addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs
(e.g. with different behaviors like End.B6.Encap and End.B6.Encap.Red (e.g., with different behaviors like End.B6.Encaps and End.B6.Encaps.Red
<xref target="RFC8986"/>) MAY be associated with the SR Policy.</t> <xref target="RFC8986" format="default"/>) <bcp14>MAY</bcp14> be associa
ted with the SR Policy.</t>
<t>Optionally, instead of only checking that the BSID of the active <t>Optionally, instead of only checking that the BSID of the active
path is available, a headend MAY check that it is available within the path is available, a headend <bcp14>MAY</bcp14> check that it is availab le within the
given SID range i.e., Segment Routing Local Block (SRLB) as specified given SID range i.e., Segment Routing Local Block (SRLB) as specified
in <xref target="RFC8402"/>.</t> in <xref target="RFC8402" format="default"/>.</t>
<t>When the specified BSID is not available (optionally is not in the <t>When the specified BSID is not available (optionally is not in the
SRLB), an alert message MUST be generated via mechanisms like SRLB), an alert message <bcp14>MUST</bcp14> be generated via mechanisms like
syslog.</t> syslog.</t>
<t>In the cases (as described above) where SR Policy does not have a <t>In the cases (as described above) where SR Policy does not have a
BSID available, then the SR Policy MAY dynamically bind a BSID to BSID available, the SR Policy <bcp14>MAY</bcp14> dynamically bind a BSID
itself. Dynamically bound BSID SHOULD use an available SID outside the to
itself. Dynamically bound BSIDs <bcp14>SHOULD</bcp14> use an available S
ID outside the
SRLB.</t> SRLB.</t>
<t>Assuming that at time t the BSID of the SR Policy is B1, if at time <t>Assuming that at time t the BSID of the SR Policy is B1, if at time
t+dt a different candidate path becomes active and this new active t+dt a different candidate path becomes active and this new active
path does not have a specified BSID or its BSID is specified but is path does not have a specified BSID or its BSID is specified but is
not available (e.g. it is in use by something else), then the SR not available (e.g., it is in use by something else), then the SR
Policy MAY keep the previous BSID B1.</t> Policy <bcp14>MAY</bcp14> keep the previous BSID B1.</t>
<t>The association of an SR Policy with a BSID thus <bcp14>MAY</bcp14> c
<t>The association of an SR Policy with a BSID thus MAY change over hange over
the life of the SR Policy (e.g., upon active path change). Hence, the the life of the SR Policy (e.g., upon active path change). Hence, the
BSID SHOULD NOT be used as an identification of an SR Policy.</t> BSID <bcp14>SHOULD NOT</bcp14> be used as an identification of an SR Pol
icy.</t>
<section anchor="Binding-SID-sr-policy-unspecified-bsid" numbered="true"
toc="default">
<name>Frequent Use Case : Unspecified BSID</name>
<section anchor="Binding-SID-sr-policy-unspecified-bsid"
title="Frequent use-case : unspecified BSID">
<t>All the candidate paths of the same SR Policy can have an <t>All the candidate paths of the same SR Policy can have an
unspecified BSID.</t> unspecified BSID.</t>
<t>In such a case, a BSID <bcp14>MAY</bcp14> be dynamically bound to t
<t>In such a case, a BSID MAY be dynamically bound to the SR Policy he SR Policy
as soon as the first valid candidate path is received. That BSID is as soon as the first valid candidate path is received. That BSID is
kept through the life of the SR Policy and across changes of active kept through the life of the SR Policy and across changes of the activ e
candidate path.</t> candidate path.</t>
</section> </section>
<section anchor="Binding-SID-policy-same-bsid" numbered="true" toc="defa
<section anchor="Binding-SID-policy-same-bsid" ult">
title="Frequent use-case: all specified to the same BSID"> <name>Frequent Use Case: All Specified to the Same BSID</name>
<t>All the paths of the SR Policy can have the same specified <t>All the paths of the SR Policy can have the same specified
BSID.</t> BSID.</t>
</section> </section>
<section anchor="Binding-SID-specified-bsid" numbered="true" toc="defaul
<section anchor="Binding-SID-specified-bsid" t">
title="Specified-BSID-only"> <name>Specified-BSID-only</name>
<t>An implementation MAY support the configuration of the <t>An implementation <bcp14>MAY</bcp14> support the configuration of t
he
Specified-BSID-only restrictive behavior on the headend for all SR Specified-BSID-only restrictive behavior on the headend for all SR
Policies or individual SR Policies. Further, this restrictive Policies or individual SR Policies. Further, this restrictive
behavior MAY also be signaled on a per SR Policy basis to the behavior <bcp14>MAY</bcp14> also be signaled on a per-SR-Policy basis to the
headend.</t> headend.</t>
<t>When this restrictive behavior is enabled, if the candidate path <t>When this restrictive behavior is enabled, if the candidate path
has an unspecified BSID or if the specified BSID is not available has an unspecified BSID or if the specified BSID is not available
when the candidate path becomes active then no BSID is bound to it when the candidate path becomes active, then no BSID is bound to it
and the candidate path is considered invalid. An alert MUST be and the candidate path is considered invalid. An alert <bcp14>MUST</bc
p14> be
triggered for this error via mechanisms like syslog. Other candidate triggered for this error via mechanisms like syslog. Other candidate
paths MUST then be evaluated for becoming the active candidate paths <bcp14>MUST</bcp14> then be evaluated for becoming the active ca ndidate
path.</t> path.</t>
</section> </section>
</section> </section>
<section anchor="Binding-SID-forwarding" numbered="true" toc="default">
<section anchor="Binding-SID-forwarding" title="Forwarding Plane"> <name>Forwarding Plane</name>
<t>A valid SR Policy results in the installation of a BSID-keyed entry <t>A valid SR Policy results in the installation of a BSID-keyed entry
in the forwarding plane with the action of steering the packets in the forwarding plane with the action of steering the packets
matching this entry to the selected path of the SR Policy.</t> matching this entry to the selected path of the SR Policy.</t>
<t>If the Specified-BSID-only restrictive behavior is enabled and the <t>If the Specified-BSID-only restrictive behavior is enabled and the
BSID of the active path is not available (optionally not in the SRLB), BSID of the active path is not available (optionally not in the SRLB),
then the SR Policy does not install any entry indexed by a BSID in the then the SR Policy does not install any entry indexed by a BSID in the
forwarding plane.</t> forwarding plane.</t>
</section> </section>
<section anchor="BSID-to-tunnel" numbered="true" toc="default">
<section anchor="BSID-to-tunnel" title="Non-SR usage of Binding SID"> <name>Non-SR Usage of Binding SID</name>
<t>An implementation MAY choose to associate a Binding SID with any <t>An implementation <bcp14>MAY</bcp14> choose to associate a Binding SI
type of interface (e.g. a layer 3 termination of an Optical Circuit) D with any
or a tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE type of interface (e.g., a layer 3 termination of an Optical Circuit)
tunnel, etc). This enables the use of other non-SR enabled interfaces or a tunnel (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
and tunnels as segments in an SR Policy Segment-List without the need tunnel, etc). This enables the use of other non-SR-enabled interfaces
and tunnels as segments in an SR Policy segment list without the need
of forming routing protocol adjacencies over them.</t> of forming routing protocol adjacencies over them.</t>
<t>The details of this kind of usage are beyond the scope of this <t>The details of this kind of usage are beyond the scope of this
document. A specific packet-optical integration use case is described document. A specific packet-optical integration use case is described
in <xref target="I-D.anand-spring-poi-sr"/>.</t> in <xref target="I-D.anand-spring-poi-sr" format="default"/>.</t>
</section> </section>
</section>
<section anchor="Policy-state" title="SR Policy State"> </section>
<t>The SR Policy State is maintained on the headend to represent the <section anchor="Policy-state" numbered="true" toc="default">
<name>SR Policy State</name>
<t>The SR Policy state is maintained on the headend to represent the
state of the policy and its candidate paths. This is to provide an state of the policy and its candidate paths. This is to provide an
accurate representation of whether the SR Policy is being instantiated accurate representation of whether the SR Policy is being instantiated
in the forwarding plane and which of its candidate paths and in the forwarding plane and which of its candidate paths and
segment-list(s) are active. The SR Policy state MUST also reflect the segment list(s) are active. The SR Policy state <bcp14>MUST</bcp14> also r eflect the
reason when a policy and/or its candidate path is not active due to reason when a policy and/or its candidate path is not active due to
validation errors or not being preferred. The operational state validation errors or not being preferred. The operational state
information reported for SR Policies are specified in <xref information reported for SR Policies are specified in <xref target="I-D.ie
target="I-D.ietf-spring-sr-policy-yang"/>.</t> tf-spring-sr-policy-yang" format="default"/>.</t>
<t>The SR Policy state can be reported by the headend node via BGP-LS <t>The SR Policy state can be reported by the headend node via BGP-LS
<xref target="I-D.ietf-idr-te-lsp-distribution"/> or PCEP <xref <xref target="I-D.ietf-idr-te-lsp-distribution" format="default"/> or PCEP
target="RFC8231"/> and <xref <xref target="RFC8231" format="default"/> <xref target="I-D.ietf-pce-binding-la
target="I-D.ietf-pce-binding-label-sid"/>.</t> bel-sid" format="default"/>.</t>
<t>SR Policy state on the headend also includes traffic accounting <t>SR Policy state on the headend also includes traffic accounting
information for the flows being steered via the policies. The details of information for the flows being steered via the policies. The details of
the SR Policy accounting are beyond the scope of this document. The the SR Policy accounting are beyond the scope of this document. The
aspects related to the SR traffic counters and their usage in the aspects related to the SR traffic counters and their usage in the
broader context of traffic accounting in an SR network are covered in broader context of traffic accounting in an SR network are covered in
<xref target="I-D.filsfils-spring-sr-traffic-counters"/> and <xref <xref target="I-D.filsfils-spring-sr-traffic-counters" format="default"/>
target="I-D.ali-spring-sr-traffic-accounting"/> respectively.</t> and <xref target="I-D.ali-spring-sr-traffic-accounting" format="default"/>, resp
ectively.</t>
<t>Implementations MAY support an administrative state to control <t>Implementations <bcp14>MAY</bcp14> support an administrative state to c
locally provisioned policies via mechanisms like CLI or NETCONF.</t> ontrol
locally provisioned policies via mechanisms like command-line interface (C
LI) or NETCONF.</t>
</section> </section>
<section anchor="Steering" title="Steering into an SR Policy"> <section anchor="Steering" numbered="true" toc="default">
<name>Steering into an SR Policy</name>
<t>A headend can steer a packet flow into a valid SR Policy in various <t>A headend can steer a packet flow into a valid SR Policy in various
ways:</t> ways:</t>
<ul spacing="compact">
<t><list style="symbols"> <li>Incoming packets have an active SID matching a local BSID at the
<t>Incoming packets have an active SID matching a local BSID at the headend.</li>
headend.</t> <li>Per-Destination Steering: incoming packets match a BGP/Service
route, which recurses on an SR Policy.</li>
<t>Per-destination Steering: incoming packets match a BGP/Service <li>Per-Flow Steering: incoming packets match or recurse on a
route which recurses on an SR policy.</t> forwarding array of which some of the entries are SR Policies.</li>
<li>Policy-Based Steering: incoming packets match a routing policy
<t>Per-flow Steering: incoming packets match or recurse on a that directs them on an SR Policy.</li>
forwarding array of which some of the entries are SR Policies.</t> </ul>
<section anchor="Steering-validity" numbered="true" toc="default">
<t>Policy-based Steering: incoming packets match a routing policy <name>Validity of an SR Policy</name>
that directs them on an SR policy.</t>
</list></t>
<section anchor="Steering-validity" title="Validity of an SR Policy">
<t>An SR Policy is invalid when all its candidate paths are invalid as <t>An SR Policy is invalid when all its candidate paths are invalid as
described in <xref target="Path-validity"/> and <xref described in Sections <xref target="SR-policy-validity" format="counter"
target="SR-policy-validity"/>.</t> /> and <xref target="Path-validity" format="counter"/>.</t>
<t>By default, upon transitioning to the invalid state, </t>
<t>By default, upon transitioning to the invalid state, <list <ul spacing="compact">
style="symbols"> <li>an SR Policy and its BSID are removed from the forwarding
<t>an SR Policy and its BSID are removed from the forwarding plane.</li>
plane.</t> <li>any steering of a service (Pseudowire (PW)), destination
(BGP-VPN), flow or packet on the related SR Policy is disabled and
<t>any steering of a service (Pseudowire (PW)), destination
(BGP-VPN), flow or packet on the related SR policy is disabled and
the related service, destination, flow, or packet is routed per the related service, destination, flow, or packet is routed per
the classic forwarding table (e.g. longest-match to the the classic forwarding table (e.g., longest match to the
destination or the recursing next-hop).</t> destination or the recursing next-hop).</li>
</list></t> </ul>
</section> </section>
<section anchor="Steering-drop" numbered="true" toc="default">
<name>Drop-upon-Invalid SR Policy</name>
<section anchor="Steering-drop" title="Drop upon invalid SR Policy"> <t>An SR Policy <bcp14>MAY</bcp14> be enabled for the Drop-Upon-Invalid
<t>An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior: behavior. This would entail the following:
<list style="symbols"> </t>
<t>an invalid SR Policy and its BSID is kept in the forwarding <ul spacing="compact">
plane with an action to drop.</t> <li>an invalid SR Policy and its BSID is kept in the forwarding
plane with an action to drop.</li>
<t>any steering of a service (PW), destination (BGP-VPN), flow or <li>any steering of a service (PW), destination (BGP-VPN), flow, or
packet on the related SR policy is maintained with the action to packet on the related SR Policy is maintained with the action to
drop all of this traffic.</t> drop all of this traffic.</li>
</list>The drop-upon-invalid behavior has been deployed in use-cases </ul>
<t>The Drop-Upon-Invalid behavior has been deployed in use cases
where the operator wants some PW to only be transported on a path with where the operator wants some PW to only be transported on a path with
specific constraints. When these constraints are no longer met, the specific constraints. When these constraints are no longer met, the
operator wants the PW traffic to be dropped. Specifically, the operator wants the PW traffic to be dropped. Specifically, the
operator does not want the PW to be routed according to the IGP operator does not want the PW to be routed according to the IGP
shortest path to the PW endpoint.</t> shortest path to the PW endpoint.</t>
</section> </section>
<section anchor="Steering-Incoming-BSID" numbered="true" toc="default">
<section anchor="Steering-Incoming-BSID" <name>Incoming Active SID is a BSID</name>
title="Incoming Active SID is a BSID">
<t>Let us assume that headend H has a valid SR Policy P of <t>Let us assume that headend H has a valid SR Policy P of
Segment-List &lt;S1, S2, S3&gt; and BSID B.</t> segment list &lt;S1, S2, S3&gt; and BSID B.</t>
<t>In the case of SR-MPLS, when H receives a packet K with label stack <t>In the case of SR-MPLS, when H receives a packet K with label stack
&lt;B, L2, L3&gt;, H pops B and pushes &lt;S1, S2, S3&gt; and forwards &lt;B, L2, L3&gt;, H pops B and pushes &lt;S1, S2, S3&gt; and forwards
the resulting packet according to SID S1. <list> the resulting packet according to SID S1. </t>
<t>"Forwarding the resulting packet according to S1" means: If S1 <aside>
<t> "Forwards the resulting packet according to SID S1" means: If S1
is an Adj-SID or a PHP-enabled prefix SID advertised by a is an Adj-SID or a PHP-enabled prefix SID advertised by a
neighbor, H sends the resulting packet with label stack &lt;S2, neighbor, H sends the resulting packet with label stack &lt;S2,
S3, L2, L3&gt; on the outgoing interface associated with S1; Else S3, L2, L3&gt; on the outgoing interface associated with S1; Else,
H sends the resulting packet with label stack &lt;S1, S2, S3, L2, H sends the resulting packet with label stack &lt;S1, S2, S3, L2,
L3&gt; along the path of S1.</t> L3&gt; along the path of S1.</t>
</list></t> </aside>
<t>In the case of SRv6, the processing is similar and follows the SR <t>In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of <xref Policy headend behaviors as specified in <xref target="RFC8986" sectionF
target="RFC8986"/>.</t> ormat="of" section="5" format="default"/>.</t>
<t>H has steered the packet into the SR Policy P.</t>
<t>H has steered the packet into the SR policy P.</t>
<t>H did not have to classify the packet. The classification was done <t>H did not have to classify the packet. The classification was done
by a node upstream of H (e.g., the source of the packet or an by a node upstream of H (e.g., the source of the packet or an
intermediate ingress edge node of the SR domain) and the result of intermediate ingress edge node of the SR domain) and the result of
this classification was efficiently encoded in the packet header as a this classification was efficiently encoded in the packet header as a
BSID.</t> BSID.</t>
<t>This is another key benefit of the segment routing in general and <t>This is another key benefit of the segment routing in general and
the binding SID in particular: the ability to encode a classification the binding SID in particular: the ability to encode a classification
and the resulting steering in the packet header to better scale and and the resulting steering in the packet header to better scale and
simplify intermediate aggregation nodes.</t> simplify intermediate aggregation nodes.</t>
<t>When Drop-Upon-Invalid (refer to <xref target="Steering-drop" format=
<t>When Drop-Upon-Invalid (refer <xref target="Steering-drop"/>) is "default"/>) is
not in use, for an invalid SR Policy P, its BSID B is not in the not in use, for an invalid SR Policy P, its BSID B is not in the
forwarding plane and hence the packet K is dropped by H.</t> forwarding plane and hence, the packet K is dropped by H.</t>
</section> </section>
<section anchor="Steering-per-destination" <section anchor="Steering-per-destination" numbered="true" toc="default">
title="Per-Destination Steering"> <name>Per-Destination Steering</name>
<t>This section describes how a headend applies steering of flows <t>This section describes how a headend applies steering of flows
corresponding to BGP routes over SR Policy using the Color Extended corresponding to BGP routes over SR Policy using the Color Extended
community <xref target="RFC9012"/>.</t> community <xref target="RFC9012" format="default"/>.</t>
<t>In the case of SR-MPLS, let us assume that headend H: </t>
<t>In the case of SR-MPLS, let us assume that headend H: <list <ul spacing="compact">
style="symbols"> <li>learns a BGP route R/r via next-hop N, Color Extended community
<t>learns a BGP route R/r via next-hop N, Color Extended community C, and VPN label V.</li>
C and VPN label V.</t> <li>has a valid SR Policy P to (color = C, endpoint = N) of
segment list &lt;S1, S2, S3&gt; and BSID B.</li>
<t>has a valid SR Policy P to (color = C, endpoint = N) of <li>has a BGP policy that matches on the Color Extended community C
Segment-List &lt;S1, S2, S3&gt; and BSID B.</t> and allows its usage as SLA steering information.</li>
</ul>
<t>has a BGP policy that matches on the Color Extended community C
and allows its usage as SLA steering information.</t>
</list></t>
<t>If all these conditions are met, H installs R/r in RIB/FIB with <t>If all these conditions are met, H installs R/r in RIB/FIB with
next-hop = SR Policy P of BSID B instead of via N.</t> next-hop = SR Policy P of BSID B instead of via N.</t>
<t>Indeed, H's local BGP policy and the received BGP route indicate <t>Indeed, H's local BGP policy and the received BGP route indicate
that the headend should associate R/r with an SR Policy path to that the headend should associate R/r with an SR Policy path to
endpoint N with the SLA associated with color C. The headend, endpoint N with the SLA associated with color C. The headend,
therefore, installs the BGP route on that policy.</t> therefore, installs the BGP route on that policy.</t>
<t>This can be implemented by using the BSID as a generalized next-hop <t>This can be implemented by using the BSID as a generalized next-hop
and installing the BGP route on that generalized next-hop.</t> and installing the BGP route on that generalized next-hop.</t>
<t>When H receives a packet K with a destination matching R/r, H <t>When H receives a packet K with a destination matching R/r, H
pushes the label stack &lt;S1, S2, S3, V&gt; and sends the resulting pushes the label stack &lt;S1, S2, S3, V&gt; and sends the resulting
packet along the path to S1.</t> packet along the path to S1.</t>
<t>Note that any SID associated with the BGP route is inserted after <t>Note that any SID associated with the BGP route is inserted after
the Segment-List of the SR Policy (i.e., &lt;S1, S2, S3, V&gt;).</t> the segment list of the SR Policy (i.e., &lt;S1, S2, S3, V&gt;).</t>
<t>In the case of SRv6, the processing is similar and follows the SR <t>In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of <xref Policy headend behaviors as specified in <xref target="RFC8986" sectionF
target="RFC8986"/>.</t> ormat="of" section="5" format="default"/>.</t>
<t>The same behavior applies to any type of service route: any <t>The same behavior applies to any type of service route: any
AFI/SAFI of BGP <xref target="RFC4760"/> or LISP <xref AFI/SAFI of BGP <xref target="RFC4760" format="default"/> or the Locator
target="RFC6830"/> for both IPv4/IPv6.</t> /ID Separation Protocol (LISP) <xref target="RFC6830" format="default"/> for bot
h IPv4/IPv6.</t>
<t>In a BGP multi-path scenario, the BGP route MAY be resolved over a <t>In a BGP multi-path scenario, the BGP route <bcp14>MAY</bcp14> be res
olved over a
mix of paths that include those that are steered over SR Policies and mix of paths that include those that are steered over SR Policies and
others resolved via the normal BGP nexthop resolution. Implementations others resolved via the normal BGP next-hop resolution. Implementations
MAY provide options to prefer one type over the other or other forms <bcp14>MAY</bcp14> provide options to prefer one type over the other or
other forms
of local policy to determine the paths that are selected.</t> of local policy to determine the paths that are selected.</t>
<section anchor="Steering-per-destination-colors" numbered="true" toc="d
<section anchor="Steering-per-destination-colors" efault">
title="Multiple Colors"> <name>Multiple Colors</name>
<t>When a BGP route has multiple Color Extended communities each <t>When a BGP route has multiple Color Extended communities each
with a valid SR Policy, the BGP process installs the route on the SR with a valid SR Policy, the BGP process installs the route on the SR
Policy giving preference to the Color Extended community with the Policy giving preference to the Color Extended community with the
highest numerical value.</t> highest numerical value.</t>
<t>Let us assume that headend H: </t>
<t>Let us assume that headend H: <list style="symbols"> <ul spacing="compact">
<t>learns a BGP route R/r via next-hop N, Color Extended <li>learns a BGP route R/r via next-hop N, Color Extended
communities C1 and C2.</t> communities C1 and C2.</li>
<li>has a valid SR Policy P1 to (color = C1, endpoint = N) of
<t>has a valid SR Policy P1 to (color = C1, endpoint = N) of segment list &lt;S1, S2, S3&gt; and BSID B1.</li>
Segment-List &lt;S1, S2, S3&gt; and BSID B1.</t> <li>has a valid SR Policy P2 to (color = C2, endpoint = N) of
segment list &lt;S4, S5, S6&gt; and BSID B2.</li>
<t>has a valid SR Policy P2 to (color = C2, endpoint = N) of <li>has a BGP policy that matches the Color Extended communities
Segment-List &lt;S4, S5, S6&gt; and BSID B2.</t> C1 and C2 and allows their usage as SLA steering information</li>
</ul>
<t>has a BGP policy that matches the Color Extended communities <t> If all these conditions are met, H installs R/r in RIB/FIB
C1 and C2 and allows their usage as SLA steering information</t>
</list> If all these conditions are met, H installs R/r in RIB/FIB
with next-hop = SR Policy P2 of BSID=B2 (instead of N) because C2 with next-hop = SR Policy P2 of BSID=B2 (instead of N) because C2
&gt; C1.</t> &gt; C1.</t>
<t>When the SR Policy with a specific color is not instantiated or <t>When the SR Policy with a specific color is not instantiated or
in the down/inactive state, the SR Policy with the next highest in the down/inactive state, the SR Policy with the next highest
numerical value of color is considered.</t> numerical value of color is considered.</t>
</section> </section>
</section> </section>
<section anchor="Steering-per-dynamic-BSID" numbered="true" toc="default">
<section anchor="Steering-per-dynamic-BSID" <name>Recursion on an On-Demand Dynamic BSID</name>
title="Recursion on an on-demand dynamic BSID">
<t>In the previous section, it was assumed that H had a <t>In the previous section, it was assumed that H had a
pre-established "explicit" SR Policy (color C, endpoint N).</t> pre-established "explicit" SR Policy (color C, endpoint N).</t>
<t>In this section, independent of the a priori existence of any
<t>In this section, independent of the a-priori existence of any explicit candidate path of the SR Policy (C, N), it is to be noted
explicit candidate path of the SR policy (C, N), it is to be noted
that the BGP process at headend node H triggers the instantiation of a that the BGP process at headend node H triggers the instantiation of a
dynamic candidate path for the SR policy (C, N) as soon as: <list dynamic candidate path for the SR Policy (C, N) as soon as: </t>
style="symbols"> <ul spacing="compact">
<t>the BGP process learns of a route R/r via N and with Color <li>the BGP process learns of a route R/r via N and with Color
Extended community C.</t> Extended community C.</li>
<li>a local policy at node H authorizes the on-demand SR Policy
<t>a local policy at node H authorizes the on-demand SR Policy
path instantiation and maps the color to a dynamic SR Policy path path instantiation and maps the color to a dynamic SR Policy path
optimization template.</t> optimization template.</li>
</list></t> </ul>
<section anchor="Steering-per-dynamic-BSID-color" numbered="true" toc="d
<section anchor="Steering-per-dynamic-BSID-color" efault">
title="Multiple Colors"> <name>Multiple Colors</name>
<t>When a BGP route R/r via N has multiple Color Extended <t>When a BGP route R/r via N has multiple Color Extended
communities Ci (with i=1 ... n), an individual on-demand SR Policy communities Ci (with i=1 ... n), an individual on-demand SR Policy
dynamic path request (color Ci, endpoint N) is triggered for each dynamic path request (color Ci, endpoint N) is triggered for each
color Ci. The SR Policy that is used for steering is then determined color Ci. The SR Policy that is used for steering is then determined
as described in <xref as described in <xref target="Steering-per-destination-colors" format=
target="Steering-per-destination-colors"/>.</t> "default"/>.</t>
</section> </section>
</section> </section>
<section anchor="Steering-per-flow" numbered="true" toc="default">
<section anchor="Steering-per-flow" title="Per-Flow Steering"> <name>Per-Flow Steering</name>
<t>This section provides an example of how a headend might apply <t>This section provides an example of how a headend might apply
per-flow steering in practice.</t> per-flow steering in practice.</t>
<t>Let us assume that headend H: </t>
<t>Let us assume that headend H: <list style="symbols"> <ul spacing="compact">
<t>has a valid SR Policy P1 to (color = C1, endpoint = N) of <li>has a valid SR Policy P1 to (color = C1, endpoint = N) of
Segment-List &lt;S1, S2, S3&gt; and BSID B1.</t> segment list &lt;S1, S2, S3&gt; and BSID B1.</li>
<li>has a valid SR Policy P2 to (color = C2, endpoint = N) of
<t>has a valid SR Policy P2 to (color = C2, endpoint = N) of segment list &lt;S4, S5, S6&gt; and BSID B2.</li>
Segment-List &lt;S4, S5, S6&gt; and BSID B2.</t> <li>is configured to instantiate an array of paths to N where the
entry 0 is the IGP path to N, color C1 is the first entry, and
<t>is configured to instantiate an array of paths to N where the
entry 0 is the IGP path to N, color C1 is the first entry and
color C2 is the second entry. The index into the array is called a color C2 is the second entry. The index into the array is called a
Forwarding Class (FC). The index can have values 0 to 7, Forwarding Class (FC). The index can have values 0 to 7,
especially when derived from the MPLS TC bits <xref especially when derived from the MPLS TC bits <xref target="RFC5462"
target="RFC5462"/>.</t> format="default"/>.</li>
<li>is configured to match flows in its ingress interfaces (upon
<t>is configured to match flows in its ingress interfaces (upon
any field such as Ethernet destination/source/VLAN/TOS or IP any field such as Ethernet destination/source/VLAN/TOS or IP
destination/source/DSCP or transport ports etc.) and color them destination/source/Differentiated Services Code Point (DSCP), or tra
with an internal per-packet forwarding-class variable (0, 1 or 2 nsport ports etc.), and color them
in this example).</t> with an internal per-packet forwarding-class variable (0, 1, or 2
</list></t> in this example).</li>
</ul>
<t>If all these conditions are met, H installs in RIB/FIB: <list <t>If all these conditions are met, H installs in RIB/FIB: </t>
style="symbols"> <ul spacing="compact">
<t>N via recursion on an array A (instead of the immediate <li>N via recursion on an array A (instead of the immediate
outgoing link associated with the IGP shortest-path to N).</t> outgoing link associated with the IGP shortest path to N).</li>
<li>Entry A(0) set to the immediate outgoing link of the IGP
<t>Entry A(0) set to the immediate outgoing link of the IGP shortest path to N.</li>
shortest-path to N.</t> <li>Entry A(1) set to SR Policy P1 of BSID=B1.</li>
<li>Entry A(2) set to SR Policy P2 of BSID=B2.</li>
<t>Entry A(1) set to SR Policy P1 of BSID=B1.</t> </ul>
<t>Entry A(2) set to SR Policy P2 of BSID=B2.</t>
</list></t>
<t>H receives three packets K, K1, and K2 on its incoming interface. <t>H receives three packets K, K1, and K2 on its incoming interface.
These three packets either longest-match on N or more likely on a These three packets either longest match on N or more likely on a
BGP/service route which recurses on N. H colors these 3 packets BGP/service route that recurses on N. H colors these 3 packets
respectively with forwarding-class 0, 1, and 2.</t> respectively with forwarding-class 0, 1, and 2.</t>
<t>As a result, for SR-MPLS: </t>
<t>As a result, for SR-MPLS: <list style="symbols"> <ul spacing="compact">
<t>H forwards K along the shortest path to N (i.e., pushes the <li>H forwards K along the shortest path to N (i.e., pushes the
Prefix-SID of N).</t> Prefix-SID of N).</li>
<li>H pushes &lt;S1, S2, S3&gt; on packet K1 and forwards the
<t>H pushes &lt;S1, S2, S3&gt; on packet K1 and forwards the resulting frame along the shortest path to S1.</li>
resulting frame along the shortest path to S1.</t> <li>H pushes &lt;S4, S5, S6&gt; on packet K2 and forwards the
resulting frame along the shortest path to S4.</li>
<t>H pushes &lt;S4, S5, S6&gt; on packet K2 and forwards the </ul>
resulting frame along the shortest path to S4.</t>
</list></t>
<t>For SRv6, the processing is similar and the segment lists of the <t>For SRv6, the processing is similar and the segment lists of the
individual SR Policies P1 and P2 are enforced for packets K1 and K2 individual SR Policies P1 and P2 are enforced for packets K1 and K2
using the SR Policy headend behaviors as specified in section 5 of using the SR Policy headend behaviors as specified in <xref
<xref target="RFC8986"/>.</t> target="RFC8986" sectionFormat="of" section="5"
format="default"/>.</t>
<t>If the local configuration does not specify any explicit forwarding <t>If the local configuration does not specify any explicit forwarding
information for an entry of the array, then this entry is filled with information for an entry of the array, then this entry is filled with
the same information as entry 0 (i.e., the IGP shortest path).</t> the same information as entry 0 (i.e., the IGP shortest path).</t>
<t>If the SR Policy mapped to an entry of the array becomes invalid, <t>If the SR Policy mapped to an entry of the array becomes invalid,
then this entry is filled with the same information as entry 0. When then this entry is filled with the same information as entry 0. When
all the array entries have the same information as entry0, the all the array entries have the same information as entry 0, the
forwarding entry for N is updated to bypass the array and point forwarding entry for N is updated to bypass the array and point
directly to its outgoing interface and next-hop.</t> directly to its outgoing interface and next-hop.</t>
<t>The array index values (e.g., 0, 1, and 2) and the notion of
<t>The array index values (e.g. 0, 1, and 2) and the notion of forwarding class are implementation specific and only meant to
forwarding-class are implementation-specific and only meant to
describe the desired behavior. The same can be realized by other describe the desired behavior. The same can be realized by other
mechanisms.</t> mechanisms.</t>
<t>This realizes per-flow steering: different flows bound to the same <t>This realizes per-flow steering: different flows bound to the same
BGP endpoint are steered on different IGP or SR Policy paths.</t> BGP endpoint are steered on different IGP or SR Policy paths.</t>
<t>A headend <bcp14>MAY</bcp14> support options to apply per-flow steeri
<t>A headend MAY support options to apply per-flow steering only for ng only for
traffic matching specific prefixes (e.g. specific IGP or BGP traffic matching specific prefixes (e.g., specific IGP or BGP
prefixes).</t> prefixes).</t>
</section> </section>
<section anchor="Steering-policy-based" numbered="true" toc="default">
<section anchor="Steering-policy-based" title="Policy-based Routing"> <name>Policy-Based Routing</name>
<t>Finally, headend H MAY be configured with a local routing policy <t>Finally, headend H <bcp14>MAY</bcp14> be configured with a local rout
which overrides any BGP/IGP path and steers a specified packet on an ing policy
that overrides any BGP/IGP path and steers a specified packet on an
SR Policy. This includes the use of mechanisms like IGP Shortcut for SR Policy. This includes the use of mechanisms like IGP Shortcut for
automatic routing of IGP prefixes over SR Policies intended for such automatic routing of IGP prefixes over SR Policies intended for such
purpose.</t> purpose.</t>
</section> </section>
<section anchor="Steering-optional-bgp" numbered="true" toc="default">
<section anchor="Steering-optional-bgp" <name>Optional Steering Modes for BGP Destinations</name>
title="Optional Steering Modes for BGP Destinations"> <section anchor="Steering-optional-bgp-color-only-steering" numbered="tr
<section anchor="Steering-optional-bgp-color-only-steering" ue" toc="default">
title="Color-Only BGP Destination Steering"> <name>Color-Only BGP Destination Steering</name>
<t>In the previous section, it is seen that the steering on an SR <t>In the previous section, it is seen that the steering on an SR
Policy is governed by the matching of the BGP route's next-hop N and Policy is governed by the matching of the BGP route's next-hop N and
the authorized Color Extended community C with an SR Policy defined the authorized Color Extended community C with an SR Policy defined
by the tuple (N, C).</t> by the tuple (N, C).</t>
<t>This is the most likely form of BGP destination steering and the <t>This is the most likely form of BGP destination steering and the
one recommended for most use-cases.</t> one recommended for most use cases.</t>
<t>This section defines an alternative steering mechanism based only <t>This section defines an alternative steering mechanism based only
on the Color Extended community.</t> on the Color Extended community.</t>
<t>Three types of steering modes are defined.</t> <t>Three types of steering modes are defined.</t>
<t>For the default, Type 0, the BGP destination is steered as <t>For the default, Type 0, the BGP destination is steered as
follows:</t> follows:</t>
<t><list hangIndent="50" style="hanging"> <sourcecode type="pseudocode">
<t IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
hangText=" IF there is a valid SR Policy (N, C) where N is the endpoint address and C is a color;
IPv4 or IPv6"/> Steer into SR Policy (N, C);
ELSE;
<t hangText=" endpoint address and C is a color;"/> Steer on the IGP path to the next-hop N.
</sourcecode>
<t hangText=" Steer into SR Policy (N, C);"/>
<t hangText=" ELSE;"/>
<t hangText=" Steer on the IGP path to the next-hop N."/>
</list></t>
<t>This is the classic case described in this document previously <t>This is the classic case described in this document previously
and what is recommended in most scenarios.</t> and what is recommended in most scenarios.</t>
<t>For Type 1, the BGP destination is steered as follows:</t> <t>For Type 1, the BGP destination is steered as follows:</t>
<t><list hangIndent="50" style="hanging"> <sourcecode type="pseudocode">
<t IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
hangText=" IF there is a valid SR Policy (N, C) where N is the endpoint address and C is a color;
IPv4 or IPv6"/> Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C) of the
<t hangText=" endpoint address and C is a color;"/> same address-family of N;
Steer into SR Policy (null endpoint, C);
<t hangText=" Steer into SR Policy (N, C);"/> ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
<t Steer into SR Policy (any null endpoint, C);
hangText=" ELSE IF there is a valid SR Policy (null endpoint, C ELSE;
) of the"/> Steer on the IGP path to the next-hop N.
</sourcecode>
<t hangText=" same address-family of N;"/>
<t hangText=" Steer into SR Policy (null endpoint, C);"/>
<t hangText=" ELSE IF there is any valid SR Policy"/>
<t
hangText=" (any address-family null endpoint, C);"/>
<t
hangText=" Steer into SR Policy (any null endpoint, C);"/>
<t hangText=" ELSE;"/>
<t hangText=" Steer on the IGP path to the next-hop N."/>
</list></t>
<t>For Type 2, the BGP destination is steered as follows:</t>
<t><list hangIndent="50" style="hanging">
<t
hangText=" IF there is a valid SR Policy (N, C) where N is an I
Pv4 or IPv6"/>
<t hangText=" endpoint address and C is a color;"/>
<t hangText=" Steer into SR Policy (N, C);"/>
<t
hangText=" ELSE IF there is a valid SR Policy (null endpoint, C
)"/>
<t hangText=" of the same address-family of N;"/>
<t hangText=" Steer into SR Policy (null endpoint, C);"/>
<t hangText=" ELSE IF there is any valid SR Policy"/>
<t
hangText=" (any address-family null endpoint, C);"/>
<t
hangText=" Steer into SR Policy (any null endpoint, C);"/>
<t
hangText=" ELSE IF there is any valid SR Policy (any endpoint,
C)"/>
<t hangText=" of the same address-family of N;"/>
<t hangText=" Steer into SR Policy (any endpoint, C);"/>
<t hangText=" ELSE IF there is any valid SR Policy"/>
<t hangText=" (any address-family endpoint, C);"/>
<t
hangText=" Steer into SR Policy (any address-family endpoin
t, C);"/>
<t hangText=" ELSE;"/>
<t hangText=" Steer on the IGP path to the next-hop N."/> <t>For Type 2, the BGP destination is steered as follows:</t>
</list></t> <sourcecode type="pseudocode">
IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C)
of the same address-family of N;
Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C);
ELSE IF there is any valid SR Policy (any endpoint, C)
of the same address-family of N;
Steer into SR Policy (any endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family endpoint, C);
Steer into SR Policy (any address-family endpoint, C);
ELSE;
Steer on the IGP path to the next-hop N.
</sourcecode>
<t>The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits <t>The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits
set to the 0 value).</t> set to the 0 value).</t>
<t>Please refer to <xref target="I-D.ietf-idr-segment-routing-te-polic
<t>Please refer to <xref y" format="default"/> for the updates to
target="I-D.ietf-idr-segment-routing-te-policy"/> for the updates to
the BGP Color Extended community for the implementation of these the BGP Color Extended community for the implementation of these
mechanisms.</t> mechanisms.</t>
</section> </section>
<section anchor="Steering-optional-bgp-multi-color" numbered="true" toc=
"default">
<name>Multiple Colors and CO flags</name>
<section anchor="Steering-optional-bgp-multi-color"
title="Multiple Colors and CO flags">
<t>The steering preference is first based on the highest Color <t>The steering preference is first based on the highest Color
Extended community value and then Color-Only steering type for the Extended community value and then Color-Only steering type for the
color. Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1&gt;C2 color. Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1&gt;C2.
The steering preference order is: <list style="symbols"> The steering preference order is: </t>
<t>SR policy (NH, C1).</t> <ul spacing="compact">
<li>SR Policy (NH, C1).</li>
<t>SR policy (null, C1).</t> <li>SR Policy (null, C1).</li>
<li>SR Policy (NH, C2).</li>
<t>SR policy (NH, C2).</t> <li>SR Policy (null, C2).</li>
<li>IGP to NH.</li>
<t>SR policy (null, C2).</t> </ul>
<t>IGP to NH.</t>
</list></t>
</section> </section>
<section anchor="Steering-optional-bgp-drop-on-invalid" numbered="true"
<section anchor="Steering-optional-bgp-drop-on-invalid" toc="default">
title="Drop upon Invalid"> <name>Drop-upon-Invalid</name>
<t>This document defined earlier that when all the following <t>This document defined earlier that when all the following
conditions are met, H installs R/r in RIB/FIB with next-hop = SR conditions are met, H installs R/r in RIB/FIB with next-hop = SR
Policy P of BSID B instead of via N. <list style="symbols"> Policy P of BSID B instead of via N. </t>
<t>H learns a BGP route R/r via next-hop N, Color Extended <ul spacing="compact">
community C.</t> <li>H learns a BGP route R/r via next-hop N, Color Extended
community C.</li>
<t>H has a valid SR Policy P to (color = C, endpoint = N) of <li>H has a valid SR Policy P to (color = C, endpoint = N) of
Segment-List &lt;S1, S2, S3&gt; and BSID B.</t> segment list &lt;S1, S2, S3&gt; and BSID B.</li>
<li>H has a BGP policy that matches the Color Extended community
<t>H has a BGP policy that matches the Color Extended community C and allows its usage as SLA steering information.</li>
C and allows its usage as SLA steering information.</t> </ul>
</list></t> <t>This behavior is extended by noting that the BGP Policy may
require the BGP steering to always stay on the SR Policy whatever
<t>This behavior is extended by noting that the BGP policy may
require the BGP steering to always stay on the SR policy whatever
its validity.</t> its validity.</t>
<t>This is the "drop-upon-invalid" option described in <xref target="S
<t>This is the "drop upon invalid" option described in <xref teering-drop" format="default"/> applied to BGP-based steering.</t>
target="Steering-drop"/> applied to BGP-based steering.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="protection" numbered="true" toc="default">
<section anchor="protection" title="Recovering from Network Failures"> <name>Recovering from Network Failures</name>
<section anchor="Local-protection-tilfa" <section anchor="Local-protection-tilfa" numbered="true" toc="default">
title="Leveraging TI-LFA local protection of the constituent IGP <name>Leveraging TI-LFA Local Protection of the Constituent IGP Segments
segments"> </name>
<t>In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) <t>In any topology, Topology-Independent Loop-Free Alternate (TI-LFA)
<xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> provides a <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa" format="default"/>
50msec local protection technique for IGP SIDs. The backup path is provides a
computed on a per IGP SID basis along the post-convergence path.</t> 50 msec local protection technique for IGP SIDs. The backup path is
computed on a per-IGP-SID basis along the post-convergence path.</t>
<t>In a network that has deployed TI-LFA, an SR Policy built on the <t>In a network that has deployed TI-LFA, an SR Policy built on the
basis of TI-LFA protected IGP segments leverages the local protection basis of TI-LFA protected IGP segments leverages the local protection
of the constituent segments. Since TI-LFA protection is based on IGP of the constituent segments. Since TI-LFA protection is based on IGP
computation, there are cases where the path used during the computation, there are cases where the path used during the
fast-reroute time window may not meet the exact constraints of the SR fast-reroute time window may not meet the exact constraints of the SR
Policy.</t> Policy.</t>
<t>In a network that has deployed TI-LFA, an SR Policy instantiated <t>In a network that has deployed TI-LFA, an SR Policy instantiated
only with non-protected Adj SIDs does not benefit from any local only with non-protected Adj SIDs does not benefit from any local
protection.</t> protection.</t>
</section> </section>
<section anchor="Local-protection-policy" numbered="true" toc="default">
<section anchor="Local-protection-policy" <name>Using an SR Policy to Locally Protect a Link</name>
title="Using an SR Policy to locally protect a link"> <figure anchor="PROTECTION">
<t><figure anchor="PROTECTION" <name>Local Protection Using SR Policy</name>
title="Local protection using SR Policy"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ 1----2-----6----7
| | | |
1----2-----6----7 4----3-----9----8
| | | |
4----3-----9----8
]]></artwork> ]]></artwork>
</figure> An SR Policy can be instantiated at node 2 to protect link </figure>
2to6. A typical explicit Segment-List would be &lt;3, 9, 6&gt;.</t>
<t>A typical use-case occurs for links outside an IGP domain: e.g. 1, <t> An SR Policy can be instantiated at node 2 to protect link
2-to-6. A typical explicit segment list would be &lt;3, 9, 6&gt;.</t>
<t>A typical use case occurs for links outside an IGP domain: e.g., 1,
2, 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 2, 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are
part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 part of IGP/SR sub-domain 2. In such a case, links 2-to-6 and 3to9
cannot benefit from TI-LFA automated local protection. The SR Policy cannot benefit from TI-LFA automated local protection. The SR Policy
with Segment-List &lt;3, 9, 6&gt; on node 2 can be locally configured with segment list &lt;3, 9, 6&gt; on node 2 can be locally configured
to be a fast-reroute backup path for the link 2to6.</t> to be a fast-reroute backup path for the link 2-to-6.</t>
</section> </section>
<section anchor="cp-path-protection" numbered="true" toc="default">
<section anchor="cp-path-protection" <name>Using a Candidate Path for Path Protection</name>
title="Using a Candidate Path for Path Protection">
<t>An SR Policy allows for multiple candidate paths, of which at any <t>An SR Policy allows for multiple candidate paths, of which at any
point in time there is a single active candidate path that is point in time there is a single active candidate path that is
provisioned in the forwarding plane and used for traffic steering. provisioned in the forwarding plane and used for traffic steering.
However, another (lower preference) candidate path MAY be designated However, another (lower preference) candidate path <bcp14>MAY</bcp14> be designated
as the backup for a specific or all (active) candidate path(s). The as the backup for a specific or all (active) candidate path(s). The
following options are possible:<list style="symbols"> following options are possible:</t>
<t>A pair of disjoint candidate paths are provisioned with one of <ul spacing="compact">
them as primary and the other is identified as its backup.</t> <li>A pair of disjoint candidate paths are provisioned with one of
them as primary and the other identified as its backup.</li>
<t>A specific candidate path is provisioned as the backup for any <li>A specific candidate path is provisioned as the backup for any
(active) candidate path.</t> (active) candidate path.</li>
<li>The headend picks the next (lower) preference valid candidate
<t>The headend picks the next (lower) preference valid candidate path as the backup for the active candidate path.</li>
path as the backup for the active candidate path.</t> </ul>
</list></t> <t>The headend <bcp14>MAY</bcp14> compute a priori and validate such bac
kup candidate
<t>The headend MAY compute a-priori and validate such backup candidate
paths as well as provision them into the forwarding plane as a backup paths as well as provision them into the forwarding plane as a backup
for the active path. The backup candidate path may be dynamically for the active path. The backup candidate path may be dynamically
computed or explicitly provisioned in such a way that they provide the computed or explicitly provisioned in such a way that they provide the
most appropriate alternative for the active candidate path. A fast most appropriate alternative for the active candidate path. A fast-rerou
re-route mechanism MAY then be used to trigger sub 50msec switchover te mechanism <bcp14>MAY</bcp14> then be used to trigger sub-50 msec switchover
from the active to the backup candidate path in the forwarding plane. from the active to the backup candidate path in the forwarding plane.
Mechanisms like Bidirectional Forwarding Detection (BFD) MAY be used Mechanisms like Bidirectional Forwarding Detection (BFD) <bcp14>MAY</bcp 14> be used
for fast detection of such failures.</t> for fast detection of such failures.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document specifies in detail the SR Policy construct introduced <t>This document specifies in detail the SR Policy construct introduced
in <xref target="RFC8402"/> and its instantiation on a router supporting in <xref target="RFC8402" format="default"/> and its instantiation on a ro
SR along with descriptions of mechanisms for steering of traffic flows uter supporting
over it. Therefore, the security considerations of <xref SR along with descriptions of mechanisms for the steering of traffic flows
target="RFC8402"/> apply. The security consideration related to SR-MPLS over it. Therefore, the security considerations of <xref target="RFC8402"
<xref target="RFC8660"/> and SRv6 <xref target="RFC8754"/> <xref format="default"/> apply. The security consideration related to SR-MPLS
target="RFC8986"/> also apply.</t> <xref target="RFC8660" format="default"/> and SRv6 <xref target="RFC8754"
format="default"/> <xref target="RFC8986" format="default"/> also apply.</t>
<t>The endpoint of the SR Policy, other than in the case of a null <t>The endpoint of the SR Policy, other than in the case of a null
endpoint, uniquely identifies the tail-end node of the segment routed endpoint, uniquely identifies the tail-end node of the segment routed
path. If an address that is used as an endpoint for an SR Policy is path. If an address that is used as an endpoint for an SR Policy is
advertised by more than one node due to a misconfiguration or spoofing advertised by more than one node due to a misconfiguration or spoofing
and the same is advertised via an IGP, the traffic steered over the SR and the same is advertised via an IGP, the traffic steered over the SR
Policy may end up getting diverted to an undesired node resulting is Policy may end up getting diverted to an undesired node resulting in
misrouting. Mechanisms for detection of duplicate prefix advertisement misrouting. Mechanisms for detection of duplicate prefix advertisement
can be used to identify and correct such scenarios. The details of these can be used to identify and correct such scenarios. The details of these
mechanisms are outside the scope of this document.</t> mechanisms are outside the scope of this document.</t>
<t><xref target="Steering" format="default"/> specifies mechanisms for the
<t>The <xref target="Steering"/> specifies mechanism for steering of steering of
traffic flows corresponding to BGP routes over SR Policies matching the traffic flows corresponding to BGP routes over SR Policies matching the
color value signaled via the BGP Color Extended Community attached with color value signaled via the BGP Color Extended Community attached with
the BGP routes. Misconfiguration or error in setting of the Color the BGP routes. Misconfiguration or error in setting of the Color
Extended Community with the BGP routes can result in forwarding of Extended Community with the BGP routes can result in the forwarding of
packets for those routes along undesired paths.</t> packets for those routes along undesired paths.</t>
<t>In Sections <xref target="SR-policy-identification" format="counter"/>
<t>In <xref target="SR-policy-identification"/> and <xref and <xref target="SR-policy-candidate-path-identification" format="counter"/>, t
target="SR-policy-candidate-path-identification"/>, the document he document
mentions that a symbolic name MAY be signaled along with a candidate mentions that a symbolic name <bcp14>MAY</bcp14> be signaled along with a
path for the SR Policy and for the SR Policy Candidate Path candidate
path for the SR Policy and for the SR Policy Candidate Path,
respectively. While the value of symbolic names for display clarity is respectively. While the value of symbolic names for display clarity is
indisputable, as with any unrestricted freeform text received from indisputable, as with any unrestricted free-form text received from
external parties, there can be no absolute assurance that the external parties, there can be no absolute assurance that the
information the text purports to show is accurate or even truthful. For information the text purports to show is accurate or even truthful. For
this reason, users of implementations that display such information this reason, users of implementations that display such information
would be well-advised not to rely on it without question and to use the would be well advised not to rely on it without question and to use the
specific identifiers of the SR Policy and SR Policy Candidate Path for specific identifiers of the SR Policy and SR Policy Candidate Path for
validation. Furthermore, implementations that display such information validation. Furthermore, implementations that display such information
might wish to display it in such a fashion as to differentiate it from might wish to display it in such a fashion as to differentiate it from
known-good information. (Such display conventions are inherently known-good information. (Such display conventions are inherently
implementation-specific; one example might be use of a distinguished implementation specific; one example might be use of a distinguished
text color or style for information that should be treated with text color or style for information that should be treated with
caution.)</t> caution.)</t>
<t>This document does not define any new protocol extensions and does <t>This document does not define any new protocol extensions and does
not introduce any further security considerations.</t> not introduce any further security considerations.</t>
</section> </section>
<section anchor="MGMT" numbered="true" toc="default">
<section anchor="MGMT" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>This document specifies in detail the SR Policy construct introduced <t>This document specifies in detail the SR Policy construct introduced
in <xref target="RFC8402"/> and its instantiation on a router supporting in <xref target="RFC8402" format="default"/> and its instantiation on a ro
SR along with descriptions of mechanisms for steering of traffic flows uter supporting
over it. Therefore, the manageability considerations of <xref SR along with descriptions of mechanisms for the steering of traffic flows
target="RFC8402"/> apply.</t> over it. Therefore, the manageability considerations of <xref target="RFC8
402" format="default"/> apply.</t>
<t>A YANG model for the configuration and operation of SR Policy has <t>A YANG model for the configuration and operation of SR Policy has
been defined in <xref target="I-D.ietf-spring-sr-policy-yang"/>.</t> been defined in <xref target="I-D.ietf-spring-sr-policy-yang" format="defa ult"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>The document requests IANA to create a new sub-registry called <t>IANA has created a new subregistry called
"Segment Types" under the top-level "Segment Routing" registry that was "Segment Types" under the "Segment Routing" registry that was
created by <xref target="RFC8986"/>. This sub-registry maintains the created by <xref target="RFC8986" format="default"/>. This subregistry mai
alphabetic identifiers for the segment types (as specified in section 4) ntains the
that may be used within a Segment List of an SR Policy. The alphabetical alphabetic identifiers for the segment types (as specified in <xref target
="SID-List"/>)
that may be used within a segment list of an SR Policy. The alphabetical
identifiers run from A to Z and may be extended on exhaustion with the identifiers run from A to Z and may be extended on exhaustion with the
identifiers AA to AZ, BA to BZ, and so on through till ZZ. This identifiers AA to AZ, BA to BZ, and so on, through ZZ. This
sub-registry would follow the Specification Required allocation policy subregistry follows the Specification Required allocation policy
as specified in <xref target="RFC8126"/>.</t> as specified in <xref target="RFC8126" format="default"/>.</t>
<t>The initial registrations for this subregistry are as follows:</t>
<t>The initial registrations for this sub-registry are as follows:</t> <table anchor="table_iana" align="center">
<name>Segment Types</name>
<texttable anchor="table_iana" title="Initial IANA Registration"> <thead>
<ttcol align="center">Value</ttcol> <tr>
<th align="center">Value</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="center">Reference</th>
<ttcol align="center">Reference</ttcol> </tr>
</thead>
<c>A</c> <tbody>
<tr>
<c>SR-MPLS Label</c> <td align="center">A</td>
<td align="left">SR-MPLS Label</td>
<c>[This.ID]</c> <td align="center">RFC 9256</td>
</tr>
<c>B</c> <tr>
<td align="center">B</td>
<td align="left">SRv6 SID</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">C</td>
<td align="left">IPv4 Prefix with optional SR Algorithm</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">D</td>
<td align="left">IPv6 Global Prefix with optional SR Algorithm for S
R-MPLS</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">E</td>
<td align="left">IPv4 Prefix with Local Interface ID</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">F</td>
<td align="left">IPv4 Addresses for link endpoints as Local, Remote
pair</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">G</td>
<td align="left">IPv6 Prefix and Interface ID for link endpoints as
Local, Remote
pair for SR-MPLS</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">H</td>
<td align="left">IPv6 Addresses for link endpoints as Local, Remote
pair for
SR-MPLS</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">I</td>
<td align="left">IPv6 Global Prefix with optional SR Algorithm for S
Rv6</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">J</td>
<td align="left">IPv6 Prefix and Interface ID for link endpoints as
Local, Remote
pair for SRv6</td>
<td align="center">RFC 9256</td>
</tr>
<tr>
<td align="center">K</td>
<td align="left">IPv6 Addresses for link endpoints as Local, Remote
pair for
SRv6</td>
<td align="center">RFC 9256</td>
</tr>
</tbody>
</table>
<section anchor="guidance" numbered="true" toc="default">
<name>Guidance for Designated Experts</name>
<t>The Designated Expert (DE) is expected to ascertain the existence
of suitable documentation (a specification) as described in <xref target
="RFC8126" format="default"/> and to verify that the document is permanently and
publicly available. The DE is also expected to check the clarity of
purpose and use of the requested assignment. Additionally, the DE must
verify that any request for one of these assignments has been made
available for review and comment within the IETF: the DE will post the
request to the SPRING Working Group mailing list (or a successor
mailing list designated by the IESG). If the request comes from within
the IETF, it should be documented in an Internet-Draft. Lastly, the DE
must ensure that any other request for a code point does not conflict
with work that is active or already published within the IETF.</t>
</section>
</section>
<c>SRv6 SID</c> </middle>
<back>
<c>[This.ID]</c> <displayreference target="I-D.ietf-pce-binding-label-sid" to="PCEP-BSID-LABEL"/>
<displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-SR-PO
LICY-CP"/>
<displayreference target="I-D.ietf-idr-te-lsp-distribution" to="BGP-LS-TE-POLICY
" />
<displayreference target="I-D.ietf-idr-segment-routing-te-policy" to="BGP-SR-POL
ICY"/>
<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/
>
<displayreference target="I-D.ietf-lsr-flex-algo" to="IGP-FLEX-ALGO"/>
<displayreference target="I-D.ali-spring-sr-traffic-accounting" to="SR-TRAFFIC-A
CCOUNTING"/>
<displayreference target="I-D.filsfils-spring-sr-policy-considerations" to="SR-P
OLICY-CONSID"/>
<displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/>
<displayreference target="I-D.anand-spring-poi-sr" to="POI-SR"/>
<displayreference target="I-D.filsfils-spring-sr-traffic-counters" to="SR-TRAFFI
C-COUNTERS"/>
<c>C</c> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8660.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8754.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9012.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1195.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2328.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5462.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6830.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3630.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5305.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5307.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5329.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8570.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7471.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8491.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8664.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8814.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9086.xml"/>
<c>IPv4 Prefix with optional SR Algorithm</c> <reference anchor="I-D.ietf-pce-binding-label-sid">
<front>
<title>Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
</title>
<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
<organization/>
</author>
<c>[This.ID]</c> <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<c>D</c> <author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization/>
</author>
<c>IPv6 Global Prefix with optional SR Algorithm for SR-MPLS</c> <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization/>
</author>
<c>[This.ID]</c> <author initials='C' surname='Li' fullname='Cheng Li' role='editor'>
<organization/>
</author>
<c>E</c> <date month='March' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-pce-binding-label-sid-15'/>
</reference>
<c>IPv4 Prefix with Local Interface ID</c> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-segment-routing-policy-cp.xml"/>
<c>[This.ID]</c> <reference anchor="I-D.ietf-idr-te-lsp-distribution">
<front>
<title>Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
</title>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization/>
</author>
<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role="edit
or">
<organization/>
</author>
<author initials='J' surname='Dong' fullname='Jie Dong' role="editor">
<organization/>
</author>
<author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
<organization/>
</author>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization/>
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization/>
</author>
<date month='April' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idr-te-lsp-distribution-17'/
>
</reference>
<c>F</c> <reference anchor="I-D.ietf-idr-segment-routing-te-policy">
<front>
<title>Advertising Segment Routing Policies in BGP
</title>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' >
<organization/>
</author>
<c>IPv4 Addresses for link endpoints as Local, Remote pair</c> <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<c>[This.ID]</c> <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='edit
or'>
<organization/>
</author>
<c>G</c> <author initials='P' surname='Mattes' fullname='Paul Mattes'>
<organization/>
</author>
<c>IPv6 Prefix and Interface ID for link endpoints as Local, Remote <author initials='D' surname='Jain' fullname='Dhanendra Jain'>
pair for SR-MPLS</c> <organization/>
</author>
<c>[This.ID]</c> <author initials='S' surname='Lin' fullname='Steven Lin'>
<organization/>
</author>
<date month='June' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-idr-segment-routing-te-polic
y-18'/>
</reference>
<c>H</c> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-rtgwg-segment-routing-ti-lfa.xml"/>
<c>IPv6 Addresses for link endpoints as Local, Remote pair for <reference anchor="I-D.ietf-lsr-flex-algo">
SR-MPLS</c> <front>
<title>IGP Flexible Algorithm
</title>
<author initials='P' surname='Psenak' fullname='Peter Psenak' role='editor'>
<organization/>
</author>
<c>[This.ID]</c> <author initials='S' surname='Hegde' fullname='Shraddha Hegde'>
<organization/>
</author>
<c>I</c> <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<c>IPv6 Global Prefix with optional SR Algorithm for SRv6</c> <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar'>
<organization/>
</author>
<c>[This.ID]</c> <author initials='A' surname='Gulko' fullname='Arkadiy Gulko'>
<organization/>
</author>
<c>J</c> <date month='May' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-lsr-flex-algo-20'/>
</reference>
<c>IPv6 Prefix and Interface ID for link endpoints as Local, Remote <reference anchor="I-D.ietf-spring-sr-policy-yang">
pair for SRv6</c> <front>
<title>YANG Data Model for Segment Routing Policy
</title>
<author initials='K' surname='Raza' fullname='Kamran Raza' role="editor">
<organization/>
</author>
<c>[This.ID]</c> <author initials='S' surname='Sawaya' fullname='Robert Sawaya'>
<organization/>
</author>
<c>K</c> <author initials='Z' surname='Shunwan' fullname='Zhuang Shunwan'>
<organization/>
</author>
<c>IPv6 Addresses for link endpoints as Local, Remote pair for <author initials='D' surname='Voyer' fullname='Daniel Voyer'>
SRv6</c> <organization/>
</author>
<c>[This.ID]</c> <author initials='M' surname='Durrani' fullname='Muhammad Durrani'>
</texttable> <organization/>
</author>
<section anchor="guidance" title="Guidance for Designated Experts"> <author initials='S' surname='Matsushima' fullname='Satoru Matsushima'>
<t>The Designated Expert (DE) is expected to ascertain the existence <organization/>
of suitable documentation (a specification) as described in <xref </author>
target="RFC8126"/> and to verify that the document is permanently and
publicly available. The DE is also expected to check the clarity of
purpose and use of the requested assignment. Additionally, the DE must
verify that any request for one of these assignments has been made
available for review and comment within the IETF: the DE will post the
request to the SPRING Working Group mailing list (or a successor
mailing list designated by the IESG). If the request comes from within
the IETF, it should be documented in an Internet-Draft. Lastly, the DE
must ensure that any other request for a code point does not conflict
with work that is active or already published within the IETF.</t>
</section>
</section>
<section anchor="Acknowledgement" title="Acknowledgement"> <author initials='V' surname='Beeram' fullname='Vishnu Pavan Beeram'>
<t>The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger <organization/>
Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, Jim </author>
Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, Matthew <date month='April' year='2021'/>
Bocci, Cullen Jennings, and Carlos Bernardos for their review comments </front>
and suggestions.</t> <seriesInfo name='Internet-Draft' value='draft-ietf-spring-sr-policy-yang-01'/>
</section> </reference>
<section anchor="Contributors" title="Contributors"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<t>The following people have contributed to this document:<figure> .anand-spring-poi-sr.xml"/>
<artwork><![CDATA[Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Zafar Ali
Cisco Systems
Email: zali@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Jose Liste
Cisco Systems
Email: jliste@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Francois Clad
Cisco Systems
Email: fclad@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Kamran Raza
Cisco Systems
Email: skraza@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Mike Koldychev
Cisco Systems
Email: mkoldych@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Shraddha Hegde
Juniper Networks
Email: shraddha@juniper.net]]></artwork>
</figure><figure>
<artwork><![CDATA[Steven Lin
Google, Inc.
Email: stevenlin@google.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Przemyslaw Krol
Google, Inc.
Email: pkrol@google.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Martin Horneffer
Deutsche Telekom
Email: martin.horneffer@telekom.de]]></artwork>
</figure><figure>
<artwork><![CDATA[Dirk Steinberg
Steinberg Consulting
Email: dws@steinbergnet.net]]></artwork>
</figure><figure>
<artwork><![CDATA[Bruno Decraene
Orange Business Services
Email: bruno.decraene@orange.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Stephane Litkowski
Orange Business Services
Email: stephane.litkowski@orange.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Luay Jalil
Verizon
Email: luay.jalil@verizon.com]]></artwork>
</figure></t>
</section>
</middle>
<back> <reference anchor="I-D.ali-spring-sr-traffic-accounting">
<references title="Normative References"> <front>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211 <title>Traffic Accounting in Segment Routing Networks
9.xml"?> </title>
<author initials='Z' surname='Ali' fullname='Zafar Ali'>
<organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817 <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
4.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.840 <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar'>
2.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.866 <author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
0.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.898 <author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
6.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.875 <author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
4.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.812 <author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
6.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.775 <author initials='D' surname='Voyer' fullname='Voyer'>
2.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.901 <author initials='R' surname='Morton' fullname='Rick Morton'>
2.xml"?> <organization/>
</references> </author>
<references title="Informative References"> <author initials='G' surname='Dawra' fullname='Gaurav Dawra'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.002 <organization/>
0.xml"?> </author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.119 <date month='May' year='2022'/>
5.xml"?> </front>
<seriesInfo name='Internet-Draft' value='draft-ali-spring-sr-traffic-accounting-
07'/>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.232 <reference anchor="I-D.filsfils-spring-sr-policy-considerations">
8.xml"?> <front>
<title>SR Policy Implementation and Deployment Considerations
</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.534 <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role="edit
0.xml"?> or">
<organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.546 <author initials='P' surname='Krol' fullname='Przemyslaw Krol'>
2.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.683 <author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
0.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.476 <author initials='P' surname='Mattes' fullname='Paul Mattes'>
0.xml"?> <organization/>
</author>
<date month='April' day='24' year='2022'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-filsfils-spring-sr-policy-conside
rations-09'/>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.363 <reference anchor="I-D.filsfils-spring-sr-traffic-counters">
0.xml"?> <front>
<title>Segment Routing Traffic Accounting Counters
</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.530 <author initials='Z' surname='Ali' fullname='Zafar Ali' role="editor">
5.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.530 <author initials='M' surname='Horneffer' fullname='Martin Horneffer'>
7.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.532 <author initials='D' surname='Voyer' fullname='Daniel Voyer'>
9.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.857 <author initials='M' surname='Durrani' fullname='Muhammad Durrani'>
0.xml"?> <organization/>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.747 <author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
1.xml"?> <organization/>
</author>
<date month='October' year='2021'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-filsfils-spring-sr-traffic-counte
rs-02'/>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.823 </references>
1.xml"?> </references>
<section anchor="Acknowledgement" numbered="false" toc="default">
<name>Acknowledgement</name>
<t>The authors would like to thank <contact fullname="Tarek Saad"/>,
<contact fullname="Dhanendra Jain"/>, <contact fullname="Ruediger
Geib"/>, <contact fullname="Rob Shakir"/>, <contact fullname="Cheng
Li"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Gyan
Mishra"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Jim
Guichard"/>, <contact fullname="Martin Vigoureux"/>, <contact
fullname="Benjamin Schwartz"/>, <contact fullname="David Schinazi"/>,
<contact fullname="Matthew Bocci"/>, <contact fullname="Cullen
Jennings"/>, and <contact fullname="Carlos J. Bernardos"/> for their
review, comments, and suggestions.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>The following people have contributed to this document:</t>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.847 <author fullname="Siva Sivabalan" initials="S" surname="Sivabalan">
6.xml"?> <organization>Cisco Systems</organization>
<address>
<email>msiva@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.849 <author fullname="Zafar Ali" initials="Z" surname="Ali">
1.xml"?> <organization>Cisco Systems</organization>
<address>
<email>zali@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.866 <author fullname="Jose Liste" initials="J" surname="Liste">
4.xml"?> <organization>Cisco Systems</organization>
<address>
<email>jliste@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.881 <author fullname="Francois Clad" initials="F" surname="Clad">
4.xml"?> <organization>Cisco Systems</organization>
<address>
<email>fclad@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.908 <author fullname="Kamran Raza" initials="K" surname="Raza">
6.xml"?> <organization>Cisco Systems</organization>
<address>
<email>skraza@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Mike Koldychev" initials="M" surname="Koldychev">
tf-pce-binding-label-sid"?> <organization>Cisco Systems</organization>
<address>
<email>mkoldych@cisco.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Shraddha Hegde" initials="S" surname="Hegde">
tf-pce-segment-routing-policy-cp"?> <organization>Juniper Networks</organization>
<address>
<email>shraddha@juniper.net</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Steven Lin" initials="S" surname="Lin">
tf-idr-te-lsp-distribution"?> <organization>Google, Inc.</organization>
<address>
<email>stevenlin@google.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Przemyslaw Krol" initials="P" surname="Krol">
tf-idr-segment-routing-te-policy"?> <organization>Google, Inc.</organization>
<address>
<email>pkrol@google.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Martin Horneffer" initials="M" surname="Horneffer">
tf-rtgwg-segment-routing-ti-lfa"?> <organization>Deutsche Telekom</organization>
<address>
<email>martin.horneffer@telekom.de</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Dirk Steinberg" initials="D" surname="Steinberg">
tf-lsr-flex-algo"?> <organization>Steinberg Consulting</organization>
<address>
<email>dws@steinbergnet.net</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <author fullname="Bruno Decraene" initials="B" surname="Decraene">
tf-spring-sr-policy-yang"?> <organization>Orange Business Services</organization>
<address>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.an <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
and-spring-poi-sr"?> <organization>Orange Business Services</organization>
<address>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.al <author fullname="Luay Jalil" initials="L" surname="Jalil">
i-spring-sr-traffic-accounting"?> <organization>Verizon</organization>
<address>
<email>luay.jalil@verizon.com</email>
</address>
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fi lsfils-spring-sr-policy-considerations"?> </section>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fi
lsfils-spring-sr-traffic-counters"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 396 change blocks. 
1394 lines changed or deleted 1604 lines changed or added

This html diff was produced by rfcdiff 1.48.