rfc9256v1.txt   rfc9256.txt 
Internet Engineering Task Force (IETF) C. Filsfils Internet Engineering Task Force (IETF) C. Filsfils
Request for Comments: 9256 K. Talaulikar, Ed. Request for Comments: 9256 K. Talaulikar, Ed.
Updates: 8402 Cisco Systems, Inc. Updates: 8402 Cisco Systems, Inc.
Category: Standards Track D. Voyer Category: Standards Track D. Voyer
ISSN: 2070-1721 Bell Canada ISSN: 2070-1721 Bell Canada
A. Bogdanov A. Bogdanov
British Telecom British Telecom
P. Mattes P. Mattes
Microsoft Microsoft
June 2022 July 2022
Segment Routing Policy Architecture Segment Routing Policy Architecture
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet flow along any 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., routing. SR Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. Packet flows instructions) that represent a source-routed policy. Packet flows
are steered into an SR Policy on a node where it is instantiated are steered into an SR Policy on a node where it is instantiated
skipping to change at line 90 skipping to change at line 90
5.2. Dynamic Candidate Path 5.2. Dynamic Candidate Path
5.3. Composite Candidate Path 5.3. Composite Candidate Path
6. Binding SID 6. Binding SID
6.1. BSID of a Candidate Path 6.1. BSID of a Candidate Path
6.2. BSID of an SR Policy 6.2. BSID of an SR Policy
6.3. Forwarding Plane 6.3. Forwarding Plane
6.4. Non-SR Usage of Binding SID 6.4. Non-SR Usage of Binding SID
7. SR Policy State 7. SR Policy State
8. Steering into an SR Policy 8. Steering into an SR Policy
8.1. Validity of an SR Policy 8.1. Validity of an SR Policy
8.2. Drop upon Invalid SR Policy 8.2. Drop-upon-Invalid SR Policy
8.3. Incoming Active SID is a BSID 8.3. Incoming Active SID is a BSID
8.4. Per-Destination Steering 8.4. Per-Destination Steering
8.5. Recursion on an On-Demand Dynamic BSID 8.5. Recursion on an On-Demand Dynamic BSID
8.6. Per-Flow Steering 8.6. Per-Flow Steering
8.7. Policy-Based Routing 8.7. Policy-Based Routing
8.8. Optional Steering Modes for BGP Destinations 8.8. Optional Steering Modes for BGP Destinations
9. Recovering from Network Failures 9. Recovering from Network Failures
9.1. Leveraging TI-LFA Local Protection of the Constituent IGP 9.1. Leveraging TI-LFA Local Protection of the Constituent IGP
Segments Segments
9.2. Using an SR Policy to Locally Protect a Link 9.2. Using an SR Policy to Locally Protect a Link
skipping to change at line 163 skipping to change at line 163
The Segment Routing architecture [RFC8402] specifies that any The Segment Routing architecture [RFC8402] specifies that any
instruction can be bound to a segment. Thus, an SR Policy can be instruction can be bound to a segment. Thus, an SR Policy can be
built using any type of Segment Identifier (SID) including those built using any type of Segment Identifier (SID) including those
associated with topological or service instructions. associated with topological or service instructions.
This section defines the key aspects and constituents of an SR This section defines the key aspects and constituents of an SR
Policy. Policy.
2.1. Identification of an SR Policy 2.1. Identification of an SR Policy
An SR Policy MUST be identified through the tuple <headend, color, An SR Policy MUST be identified through the tuple <Headend, Color,
endpoint>. In the context of a specific headend, an SR Policy MUST Endpoint>. In the context of a specific headend, an SR Policy MUST
be identified by the <color, endpoint> tuple. be identified by the <Color, Endpoint> tuple.
The headend is the node where the policy is instantiated/implemented. The headend is the node where the policy is instantiated/implemented.
The headend is specified as an IPv4 or IPv6 address and MUST resolve The headend is specified as an IPv4 or IPv6 address and MUST resolve
to a unique node in the SR domain [RFC8402]. to a unique node in the SR domain [RFC8402].
The endpoint indicates the destination of the policy. The endpoint The endpoint indicates the destination of the policy. The endpoint
is specified as an IPv4 or IPv6 address and SHOULD resolve to a is specified as an IPv4 or IPv6 address and SHOULD resolve to a
unique node in the domain. In a specific case (refer to unique node in the domain. In a specific case (refer to
Section 8.8.1), the endpoint can be the unspecified address (0.0.0.0 Section 8.8.1), the endpoint can be the unspecified address (0.0.0.0
for IPv4, :: for IPv6) and in this case, the destination of the for IPv4, :: for IPv6) and in this case, the destination of the
skipping to change at line 201 skipping to change at line 201
(refer to Section 2.2). An SR Policy MAY have multiple names (refer to Section 2.2). An SR Policy MAY have multiple names
associated with it in the scenario where the headend receives associated with it in the scenario where the headend receives
different SR Policy names along with different candidate paths for different SR Policy names along with different candidate paths for
the same SR Policy via the same or different sources. the same SR Policy via the same or different sources.
2.2. Candidate Path and Segment List 2.2. Candidate Path and Segment List
An SR Policy is associated with one or more candidate paths. A 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 the Path Computation Element via protocol extensions like the Path Computation Element
Communication Protocol (PCEP) [RFC8664] [SR-POLICY-CP] or BGP SR Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR
Policy [IDR-SR-TE-POLICY]. Policy [BGP-SR-POLICY].
A Segment-List represents a specific source-routed path to send 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. Policy.
A candidate path is either dynamic, explicit, or composite. A candidate path is either dynamic, explicit, or composite.
An explicit candidate path is expressed as a Segment-List or a set of An explicit candidate path is expressed as a segment list or a set of
Segment-Lists. segment lists.
A dynamic candidate path expresses an optimization objective and a 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. problem.
If a candidate path is associated with a set of Segment-Lists, each 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 Section 2.11 for details). The default weight is 1. (refer to Section 2.11 for details). The default weight is 1.
A composite candidate path acts as a container for grouping SR 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 objectives and constraints, for load-balanced steering of packet
flows over its constituent SR Policies. The following criteria apply flows over its constituent SR Policies. The following criteria apply
for inclusion of constituent SR Policies using a composite candidate for inclusion of constituent SR Policies using a composite candidate
path under a parent SR Policy: path under a parent SR Policy:
skipping to change at line 252 skipping to change at line 252
associated with weight for load-balancing purposes (refer to associated with weight for load-balancing purposes (refer to
Section 2.11 for details). The default weight is 1. Section 2.11 for details). The default weight is 1.
Section 2.13 illustrates an information model for hierarchical Section 2.13 illustrates an information model for hierarchical
relationships between the SR Policy constructs described in this relationships between the SR Policy constructs described in this
section. section.
2.3. Protocol-Origin of a Candidate Path 2.3. Protocol-Origin of a Candidate Path
A headend may be informed about a candidate path for an SR Policy A headend may be informed about a candidate path for an SR Policy
<color, endpoint> by various means including: via configuration, PCEP <Color, Endpoint> by various means including: via configuration, PCEP
[RFC8664] [SR-POLICY-CP], or BGP [IDR-SR-TE-POLICY]. [RFC8664] [PCEP-SR-POLICY-CP], or BGP [BGP-SR-POLICY].
Protocol-Origin of a candidate path is an 8-bit value associated with Protocol-Origin of a candidate path is an 8-bit value associated with
the mechanism or protocol used for signaling/provisioning the SR 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. other protocols/mechanisms.
The headend assigns different Protocol-Origin values to each source The headend assigns different Protocol-Origin values to each source
of SR Policy information. The Protocol-Origin value is used as a of SR Policy information. The Protocol-Origin value is used as a
tiebreaker between candidate paths of equal preference, as described tiebreaker between candidate paths of equal Preference, as described
in Section 2.9. The table below specifies the RECOMMENDED default in Section 2.9. The table below specifies the RECOMMENDED default
values of Protocol-Origin: values of Protocol-Origin:
+=================+===================+ +=================+===================+
| Protocol-Origin | Description | | Protocol-Origin | Description |
+=================+===================+ +=================+===================+
| 10 | PCEP | | 10 | PCEP |
+-----------------+-------------------+ +-----------------+-------------------+
| 20 | BGP SR Policy | | 20 | BGP SR Policy |
+-----------------+-------------------+ +-----------------+-------------------+
skipping to change at line 287 skipping to change at line 287
Table 1: Protocol-Origin Default Values Table 1: Protocol-Origin Default Values
Note that the above order is to satisfy the need for having a clear Note that the above order is to satisfy the need for having a clear
ordering, and implementations MAY allow modifications of these ordering, and implementations MAY allow modifications of these
default values assigned to protocols on the headend along similar default values assigned to protocols on the headend along similar
lines as a routing administrative distance. Its application in the lines as a routing administrative distance. Its application in the
candidate path selection is described in Section 2.9. candidate path selection is described in Section 2.9.
2.4. Originator of a Candidate Path 2.4. Originator of a Candidate Path
The originator identifies the node that provisioned or signaled the The Originator identifies the node that provisioned or signaled the
candidate path on the headend. The originator is expressed in the candidate path on the headend. The Originator is expressed in the
form of a 160-bit numerical value formed by the concatenation of the form of a 160-bit numerical value formed by the concatenation of the
fields of the tuple <Autonomous System Number (ASN), node-address> as fields of the tuple <Autonomous System Number (ASN), node-address> as
below: below:
Autonomous System Number (ASN): represented as a 4-byte number. If Autonomous System Number (ASN): represented as a 4-byte number. If
2-byte ASNs are in use, the low-order 16 bits MUST be used, and 2-byte ASNs are in use, the low-order 16 bits MUST be used, and
the high-order bits MUST be set to zero. the high-order bits MUST be set to 0.
Node Address: represented as a 128-bit value. IPv4 addresses MUST Node Address: represented as a 128-bit value. IPv4 addresses MUST
be encoded in the lowest 32 bits, and the high-order bits MUST be be encoded in the lowest 32 bits, and the high-order bits MUST be
set to zero. set to 0.
Its application in the candidate path selection is described in Its application in the candidate path selection is described in
Section 2.9. Section 2.9.
When provisioning is via configuration, the ASN and node address MAY When provisioning is via configuration, the ASN and node address MAY
be set to either the headend or the provisioning controller/node ASN be set to either the headend or the provisioning controller/node ASN
and address. The default value is 0 for both AS and node address. and address. The default value is 0 for both AS and node address.
When signaling is via PCEP, it is the IPv4 or IPv6 address of the 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. available or known.
When signaling is via BGP SR Policy, the ASN and node address are When signaling is via BGP SR Policy, the ASN and node address are
provided by BGP (refer to [IDR-SR-TE-POLICY]) on the headend. provided by BGP (refer to [BGP-SR-POLICY]) on the headend.
2.5. Discriminator of a Candidate Path 2.5. Discriminator of a Candidate Path
The discriminator is a 32-bit value associated with a candidate path The Discriminator is a 32-bit value associated with a candidate path
that uniquely identifies it within the context of an SR Policy from a that uniquely identifies it within the context of an SR Policy from a
specific Protocol-Origin as specified below: specific Protocol-Origin as specified below:
* When provisioning is via configuration, this is an * When provisioning is via configuration, this is a unique
implementation's unique identifier for a candidate path; it is identifier for a candidate path; it is specific to the
specific to the configuration model. The default value is 0. implementation's configuration model. The default value is 0.
* When signaling is via PCEP, the method to uniquely signal an * 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 [SR-POLICY-CP]. The default value is 0. described in [PCEP-SR-POLICY-CP]. The default value is 0.
* When signaling is via BGP SR Policy, the BGP process receiving the * When signaling is via BGP SR Policy, the BGP process receiving the
route provides the distinguisher (refer to Section 2.1 of route provides the distinguisher (refer to [BGP-SR-POLICY]) as the
[IDR-SR-TE-POLICY]) as the discriminator. Note that the BGP best Discriminator. Note that the BGP best path selection is applied
path selection is applied before the route is supplied as a before the route is supplied as a candidate path, so only a single
candidate path, so only a single candidate path for a given SR candidate path for a given SR Policy will be seen for a given
Policy will be seen for a given discriminator. Discriminator.
Its application in the candidate path selection is described in Its application in the candidate path selection is described in
Section 2.9. Section 2.9.
2.6. Identification of a Candidate Path 2.6. Identification of a Candidate Path
A candidate path is identified in the context of a single SR Policy. A candidate path is identified in the context of a single SR Policy.
A candidate path is not shared across SR Policies. A candidate path is not shared across SR Policies.
A candidate path is not identified by its Segment-List(s). A candidate path is not identified by its segment list(s).
| If CP1 is a candidate path of SR Policy Pol1 and CP2 is a | If CP1 is a candidate path of SR Policy Pol1 and CP2 is a
| candidate path of SR Policy Pol2, then these two candidate | candidate path of SR Policy Pol2, then these two candidate
| paths are independent, even if they happen to have the same | paths are independent, even if they happen to have the same
| Segment-List. The Segment-List does not identify a candidate | segment list. The segment list does not identify a candidate
| path. The Segment-List is an attribute of a candidate path. | path. The segment list is an attribute of a candidate path.
The identity of a candidate path MUST be uniquely established in the The identity of a candidate path MUST be uniquely established in the
context of an SR Policy <headend, color, endpoint> to handle add, context of an SR Policy <Headend, Color, Endpoint> to handle add,
delete, or modify operations on them in an unambiguous manner delete, or modify operations on them in an unambiguous manner
regardless of their source(s). regardless of their source(s).
The tuple <protocol-origin, originator, discriminator> uniquely The tuple <Protocol-Origin, Originator, Discriminator> uniquely
identifies a candidate path. identifies a candidate path.
Candidate paths MAY also be assigned or signaled with a symbolic name Candidate paths MAY also be assigned or signaled with a symbolic name
comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E)
to serve as a user-friendly attribute for debugging and to serve as a user-friendly attribute for debugging and
troubleshooting purposes. Such symbolic names MUST NOT be considered troubleshooting purposes. Such symbolic names MUST NOT be considered
as identifiers for a candidate path. The signaling of the candidate as identifiers for a candidate path. The signaling of the candidate
path name via BGP and PCEP is described in [IDR-SR-TE-POLICY] and path name via BGP and PCEP is described in [BGP-SR-POLICY] and
[SR-POLICY-CP], respectively. [PCEP-SR-POLICY-CP], respectively.
2.7. Preference of a Candidate Path 2.7. Preference of a Candidate Path
The preference of the candidate path is used to select the best 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. 100.
It is RECOMMENDED that each candidate path of a given SR Policy has a It is RECOMMENDED that each candidate path of a given SR Policy has a
different preference. different Preference.
The signaling of the candidate path preference via BGP and PCEP is The signaling of the candidate path Preference via BGP and PCEP is
described in [IDR-SR-TE-POLICY] and [SR-POLICY-CP], respectively. described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
2.8. Validity of a Candidate Path 2.8. Validity of a Candidate Path
A candidate path is usable when it is valid. The RECOMMENDED A candidate path is usable when it is valid. The RECOMMENDED
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
Section 5. Section 5.
2.9. Active Candidate Path 2.9. Active Candidate Path
A candidate path is selected when it is valid and it is determined to 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 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. as the "active path" of the SR Policy in this document.
Whenever a new path is learned or an active path is deleted, the 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. the selection process MUST be re-executed.
The candidate path selection process operates primarily on the 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. candidate paths of the SR Policy.
In the case of multiple valid candidate paths of the same preference, In the case of multiple valid candidate paths of the same Preference,
the tie-breaking rules are evaluated on the identification tuple in the tie-breaking rules are evaluated on the identification tuple in
the following order until only one valid best path is selected: the following order until only one valid best path is selected:
1. The higher value of Protocol-Origin is selected. 1. The higher value of Protocol-Origin is selected.
2. If specified by configuration, prefer the existing installed 2. If specified by configuration, prefer the existing installed
path. path.
3. The lower value of the originator is selected. 3. The lower value of the Originator is selected.
4. Finally, the higher value of the discriminator is selected. 4. Finally, the higher value of the Discriminator is selected.
The rules are framed with multiple protocols and sources in mind and 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 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:
* The preference, being the primary criterion, allows an operator to * The Preference, being the primary criterion, allows an operator to
influence selection across paths thus allowing provisioning of influence selection across paths thus allowing provisioning of
multiple path options, e.g., CP1 is preferred and if it becomes multiple path options, e.g., CP1 is preferred as its Preference
invalid then fallback to CP2 and so on. Since preference works value is the highest, and if it becomes invalid, then CP2 with the
across protocol sources, it also enables (where necessary) next highest Preference value is selected, and so on. Since
selective override of the default Protocol-Origin preference, Preference works across protocol sources, it also enables (where
e.g., to prefer a path signaled via BGP SR Policy over what is necessary) selective override of the default Protocol-Origin
configured. preference, e.g., to prefer a path signaled via BGP SR Policy over
what is configured.
* The Protocol-Origin allows an operator to set up a default * The Protocol-Origin allows an operator to set up a default
selection mechanism across protocol sources, e.g., to prefer selection mechanism across protocol sources, e.g., to prefer
configured over paths signaled via BGP SR Policy or PCEP. configured paths over paths signaled via BGP SR Policy or PCEP.
* The originator allows an operator to have multiple redundant * 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. candidate paths for the same SR policies to the headend.
* The discriminator performs the final tie-breaking step to ensure a * The Discriminator performs the final tie-breaking step to ensure a
deterministic outcome of selection regardless of the order in 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. channels or sessions.
Section 4 of [SR-POLICY-CONSID] provides a set of examples to [SR-POLICY-CONSID] provides a set of examples to illustrate the
illustrate the active candidate path selection rules. active candidate path selection rules.
2.10. Validity of an SR Policy 2.10. Validity of an SR Policy
An SR Policy is valid when it has at least one valid candidate path. An SR Policy is valid when it has at least one valid candidate path.
2.11. Instantiation of an SR Policy in the Forwarding Plane 2.11. Instantiation of an SR Policy in the Forwarding Plane
Generally, only valid SR policies are instantiated in the forwarding Generally, only valid SR policies are instantiated in the forwarding
plane. plane.
Only the active candidate path MUST be used for forwarding traffic Only the active candidate path MUST be used for forwarding 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 Section 9.3. described in Section 9.3.
If a set of Segment-Lists is associated with the active path of the 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) policy, then the steering is per flow and weighted-ECMP (W-ECMP)
based according to the relative weight of each Segment-List. based according to the relative weight of each segment list.
The fraction of the flows associated with a given Segment-List is The fraction of the flows associated with a given segment list is
w/Sw, where w is the weight of the Segment-List and Sw is the sum of 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 the weights of the segment lists of the selected path of the SR
Policy. Policy.
When a composite candidate path is active, the fraction of flows 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 weight of each constituent SR Policy. Further load-balancing of
flows steered into a constituent SR Policy is performed based on the flows steered into a constituent SR Policy is performed based on the
weights of the Segment-List of the active candidate path of that weights of the segment list of the active candidate path of that
constituent SR Policy. constituent SR Policy.
The accuracy of the weighted load-balancing depends on the platform The accuracy of the weighted load-balancing depends on the platform
implementation. implementation.
2.12. Priority of an SR Policy 2.12. Priority of an SR Policy
Upon topological change, many policies could be re-computed or Upon topological change, many policies could be re-computed or
revalidated. An implementation MAY provide a per-policy priority revalidated. An implementation MAY provide a per-policy priority
configuration. The operator may set this field to indicate the order configuration. The operator may set this field to indicate the order
skipping to change at line 501 skipping to change at line 502
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 distinct signaled non-default priority values and the SR Policy
itself does not have a priority value configured, the SR Policy as a itself does not have a priority value configured, the SR Policy as a
whole takes the lowest value (i.e., the highest priority) amongst whole takes the lowest value (i.e., the highest priority) amongst
these signaled priority values. these signaled priority values.
2.13. Summary 2.13. Summary
In summary, the information model is the following: In summary, the information model is the following:
SR Policy POL1 <headend = H1, color = 1, endpoint = E1> SR Policy POL1 <Headend = H1, Color = 1, Endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator = Candidate Path CP1 <Protocol-Origin = 20, Originator =
64511:192.0.2.1, discriminator = 1> 64511:192.0.2.1, Discriminator = 1>
Preference 200 Preference 200
Priority 10 Priority 10
Segment List 1 <SID11...SID1i>, Weight W1 Segment List 1 <SID11...SID1i>, Weight W1
Segment List 2 <SID21...SID2j>, Weight W2 Segment List 2 <SID21...SID2j>, Weight W2
Candidate-path CP2 <protocol-origin = 20, originator = Candidate Path CP2 <Protocol-Origin = 20, Originator =
64511:192.0.2.2, discriminator = 2> 64511:192.0.2.2, Discriminator = 2>
Preference 100 Preference 100
Priority 10 Priority 10
Segment List 3 <SID31...SID3i>, Weight W3 Segment List 3 <SID31...SID3i>, Weight W3
Segment List 4 <SID41...SID4j>, Weight W4 Segment List 4 <SID41...SID4j>, Weight W4
The SR Policy POL1 is identified by the tuple <headend, color, The SR Policy POL1 is identified by the tuple <Headend, Color,
endpoint>. It has two candidate paths: CP1 and CP2. Each is Endpoint>. It has two candidate paths: CP1 and CP2. Each is
identified by a tuple <protocol-origin, originator, discriminator> identified by a tuple <Protocol-Origin, Originator, Discriminator>
within the scope of POL1. CP1 is the active candidate path (it is within the scope of POL1. CP1 is the active candidate path (it is
valid and has the highest preference). The two Segment-Lists of CP1 valid and has the highest Preference). The two segment lists of CP1
are installed as the forwarding instantiation of SR Policy POL1. are installed as the forwarding instantiation of SR Policy POL1.
Traffic steered on POL1 is flow-based hashed on Segment-List Traffic steered on POL1 is flow-based hashed on segment list
<SID11...SID1i> with a ratio W1/(W1+W2). <SID11...SID1i> with a ratio W1/(W1+W2).
The information model of SR Policy POL100 having a composite The information model of SR Policy POL100 having a composite
candidate path is the following: candidate path is the following:
SR Policy POL100 <headend = H1, color = 100, endpoint = E1> SR Policy POL100 <Headend = H1, Color = 100, Endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator = Candidate Path CP1 <Protocol-Origin = 20, Originator =
64511:192.0.2.1, discriminator = 1> 64511:192.0.2.1, Discriminator = 1>
Preference 200 Preference 200
SR Policy <color = 1>, Weight W1 SR Policy <Color = 1>, Weight W1
SR Policy <color = 2>, Weight W2 SR Policy <Color = 2>, Weight W2
The constituent SR Policies POL1 and POL2 have an information model The constituent SR Policies POL1 and POL2 have an information model
as described at the start of this section. They are referenced only as described at the start of this section. They are referenced only
by color in the composite candidate path since their headend and by color in the composite candidate path since their headend and
endpoint are identical to the POL100. The valid Segment-Lists of the endpoint are identical to the POL100. The valid segment lists of the
active candidate path of POL1 and POL2 are installed in the active candidate path of POL1 and POL2 are installed in the
forwarding. Traffic steered on POL100 is flow-based hashed on POL1 forwarding. Traffic steered on POL100 is hashed on a per-flow basis
with a proportion W1/(W1+W2). Within the POL1, the flow-based on POL1 with a proportion W1/(W1+W2). Within the POL1, the flow-
hashing over its Segment-Lists are performed as described earlier in based hashing over its segment lists are performed as described
this section. earlier in this section.
3. Segment Routing Database 3. Segment Routing Database
An SR Policy computation node (e.g., headend or controller) maintains An SR Policy computation node (e.g., headend or controller) maintains
the Segment Routing Database (SR-DB). The SR-DB is a conceptual the Segment Routing Database (SR-DB). The SR-DB is a conceptual
database to illustrate the various pieces of information and their database to illustrate the various pieces of information and their
sources that may help in SR Policy computation and validation. There sources that may help in SR Policy computation and validation. There
is no specific requirement for an implementation to create a new is no specific requirement for an implementation to create a new
database as such. database as such.
skipping to change at line 582 skipping to change at line 583
NETCONF. NETCONF.
A non-attached (remote) domain topology may be learned via protocol/ A non-attached (remote) domain topology may be learned via protocol/
mechanisms such as BGP-LS or NETCONF. mechanisms such as BGP-LS or NETCONF.
In some use cases, the SR-DB may only contain the attached domain 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 topology while in others, the SR-DB may contain the topology of
multiple domains and in this case, it is multi-domain capable. multiple domains and in this case, it is multi-domain capable.
The SR-DB may also contain the SR Policies instantiated in the The SR-DB may also contain the SR Policies instantiated in the
network. This can be collected via BGP-LS [TE-POLICIES-BGP-LS] or network. This can be collected via BGP-LS [BGP-LS-TE-POLICY] or PCEP
PCEP [RFC8231], [SR-POLICY-CP], and [BINDING-LABEL-SID]. This [RFC8231] (along with [PCEP-SR-POLICY-CP] and [PCEP-BSID-LABEL]).
information allows to build an end-to-end policy on the basis of This information allows to build an end-to-end policy on the basis of
intermediate SR policies (see Section 6 for further details). intermediate SR policies (see Section 6 for further details).
The SR-DB may also contain the Maximum SID Depth (MSD) capability of The SR-DB may also contain the Maximum SID Depth (MSD) capability of
nodes in the topology. This can be collected via IS-IS [RFC8491], nodes in the topology. This can be collected via IS-IS [RFC8491],
OSPF [RFC8476], BGP-LS [RFC8814], or PCEP [RFC8664]. OSPF [RFC8476], BGP-LS [RFC8814], or PCEP [RFC8664].
The use of the SR-DB for path computation and for the validation of The use of the SR-DB for path computation and for the validation of
optimization objective and constraints of paths is outside the scope optimization objective and constraints of paths is outside the scope
of this document. Some implementation aspects related to path of this document. Some implementation aspects related to path
computation are covered in [SR-POLICY-CONSID]. computation are covered in [SR-POLICY-CONSID].
4. Segment Types 4. Segment Types
A Segment-List is an ordered set of segments represented as <S1, S2, A segment list is an ordered set of segments represented as <S1, S2,
... Sn> where S1 is the first segment. ... Sn> where S1 is the first segment.
Based on the desired data plane, either the MPLS label stack or the Based on the desired data plane, either the MPLS label stack or the
SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. SRv6 Segment Routing Header [RFC8754] is built from the segment list.
However, the Segment-List itself can be specified using different However, the segment list itself can be specified using different
segment-descriptor types and the following are currently defined: segment-descriptor types and the following are currently defined:
Type A: SR-MPLS Label: Type A: SR-MPLS Label:
An MPLS label corresponding to any of the segment types defined An MPLS label corresponding to any of the segment types defined
for SR-MPLS (as defined in [RFC8402] or other SR-MPLS for SR-MPLS (as defined in [RFC8402] or other SR-MPLS
specifications) can be used. Additionally, special purpose specifications) can be used. Additionally, special purpose
labels like explicit-null or in general any MPLS label MAY also labels like explicit-null or in general any MPLS label MAY also
be used. For example, this type can be used to specify a label be used. For example, this type can be used to specify a label
representation that maps to an optical transport path on a representation that maps to an optical transport path on a
packet transport node. packet transport node.
Type B: SRv6 SID: Type B: SRv6 SID:
An IPv6 address corresponding to any of the SID behaviors for An IPv6 address corresponding to any of the SID behaviors for
SRv6 (as defined in [RFC8986] or other SRv6 specifications) can SRv6 (as defined in [RFC8986] or other SRv6 specifications) can
be used. Optionally, the SRv6 SID behavior (as defined in be used. Optionally, the SRv6 SID behavior (as defined in
[RFC8986] or other SRv6 specifications) and structure (as [RFC8986] or other SRv6 specifications) and structure (as
defined in [RFC8986]) MAY also be provided for the headend to defined in [RFC8986]) MAY also be provided for the headend to
perform validation of the SID when using it for building the perform validation of the SID when using it for building the
Segment List. segment list.
Type C: IPv4 Prefix with optional SR Algorithm: Type C: IPv4 Prefix with optional SR Algorithm:
In this case, the headend is required to resolve the specified In this case, the headend is required to resolve the specified
IPv4 Prefix Address to the SR-MPLS label corresponding to its IPv4 Prefix Address to the SR-MPLS label corresponding to its
Prefix SID segment (as defined in [RFC8402]). The SR algorithm Prefix SID segment (as defined in [RFC8402]). The SR algorithm
(refer to Section 3.1.1 of [RFC8402]) to be used MAY also be (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be
provided. provided.
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
In this case, the headend is required to resolve the specified In this case, the headend is required to resolve the specified
IPv6 Global Prefix Address to the SR-MPLS label corresponding IPv6 Global Prefix Address to the SR-MPLS label corresponding
to its Prefix SID segment (as defined in [RFC8402]). The SR to its Prefix SID segment (as defined in [RFC8402]). The SR
skipping to change at line 728 skipping to change at line 729
Address pair link descriptors follow semantics as specified in Address pair link descriptors follow semantics as specified in
[RFC7752]. The SR Algorithm (refer to Section 3.1.1 of [RFC7752]. The SR Algorithm (refer to Section 3.1.1 of
[RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or [RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or
other SRv6 specifications), and structure (as defined in other SRv6 specifications), and structure (as defined in
[RFC8986]) MAY also be provided. [RFC8986]) MAY also be provided.
When the algorithm is not specified for the SID types above which When the algorithm is not specified for the SID types above which
optionally allow for it, the headend SHOULD use the Strict Shortest optionally allow for it, the headend SHOULD use the Strict Shortest
Path algorithm if available and otherwise, it SHOULD use the default Path algorithm if available and otherwise, it SHOULD use the default
Shortest Path algorithm. The specification of the algorithm enables Shortest Path algorithm. The specification of the algorithm enables
the use of the IGP Flex Algorithm [IGP-FLEX-ALGO] specific SIDs in SR the use of SIDs specific to the IGP Flex Algorithm [IGP-FLEX-ALGO] in
Policy. SR Policy.
For SID types C through K, a SID value MAY also be optionally For SID types C through K, a SID value MAY also be optionally
provided to the headend for verification purposes. Section 5.1 provided to the headend for verification purposes. Section 5.1
describes the resolution and verification of the SIDs and Segment describes the resolution and verification of the SIDs and segment
Lists on the headend. lists on the headend.
When building the MPLS label stack or the IPv6 Segment list from the When building the MPLS label stack or the SRv6 SID list from the
Segment List, the node instantiating the policy MUST interpret the segment list, the node instantiating the policy MUST interpret the
set of Segments as follows: set of Segments as follows:
* The first Segment represents the topmost label or the first IPv6 * The first Segment represents the topmost MPLS label or the first
segment. It identifies the active segment the traffic will be SRv6 SID. It identifies the active segment the traffic will be
directed toward along the explicit SR path. directed toward along the explicit SR path.
* The last Segment represents the bottommost label or the last IPv6 * The last segment represents the bottommost MPLS label or the last
segment the traffic will be directed toward along the explicit SR SRv6 SID the traffic will be directed toward along the explicit SR
path. path.
4.1. Explicit Null 4.1. Explicit Null
A Type A SID MAY be any MPLS label, including special purpose labels. A Type A SID MAY be any MPLS label, including special purpose labels.
For example, assuming that the desired traffic-engineered path from a For example, assuming that the desired traffic-engineered path from a
headend 1 to an endpoint 4 can be expressed by the Segment-List headend 1 to an endpoint 4 can be expressed by the segment list
<16002, 16003, 16004> where 16002, 16003, and 16004, respectively, <16002, 16003, 16004> 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 traffic can be traffic-engineered from nodes 1 to 4 via the
previously described path using an SR Policy with Segment-List previously described path using an SR Policy with segment list
<16002, 16003, 16004, 2> where the MPLS label value of 2 represents <16002, 16003, 16004, 2> where the MPLS label value of 2 represents
the "IPv6 Explicit NULL Label". the "IPv6 Explicit NULL Label".
The penultimate node before node 4 will pop 16004 and will forward The penultimate node before node 4 will pop 16004 and will forward
the frame on its directly connected interface to node 4. the frame on its directly connected interface to node 4.
The endpoint receives the traffic with the top label "2", which The endpoint receives the traffic with the top label "2", which
indicates that the payload is an IPv6 packet. indicates that the payload is an IPv6 packet.
When steering unlabeled IPv6 BGP destination traffic using an SR 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 Section 2.4.5 of Null Label Policy is processed as specified in [BGP-SR-POLICY]. When
[IDR-SR-TE-POLICY]. When an "IPv6 Explicit NULL label" is not an "IPv6 Explicit NULL label" is not present as the bottom label, the
present as the bottom label, the headend SHOULD automatically impose headend SHOULD automatically impose one. Refer to Section 8 for more
one. Refer to Section 8 for more details. details.
5. Validity of a Candidate Path 5. Validity of a Candidate Path
5.1. Explicit Candidate Path 5.1. Explicit Candidate Path
An explicit candidate path is associated with a Segment-List or a set An explicit candidate path is associated with a segment list or a set
of Segment-Lists. of segment lists.
An explicit candidate path is provisioned by the operator directly or An explicit candidate path is provisioned by the operator directly or
via a controller. via a controller.
The computation/logic that leads to the choice of the Segment-List is 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 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. validity.
An explicit candidate path MAY consist of a single explicit Segment- An explicit candidate path MAY consist of a single explicit segment
List containing only an implicit-null label to indicate pop-and- list containing only an implicit-null label to indicate pop-and-
forward behavior. The Binding SID (BSID) is popped and the traffic forward behavior. The Binding SID (BSID) is popped and the traffic
is forwarded based on the inner label or an IP lookup in the case of 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 fallback unlabeled IP packets. Such an explicit path can serve as a fallback
or path of last resort for traffic being steered into an SR Policy or path of last resort for traffic being steered into an SR Policy
using its BSID (refer to Section 8.3). using its BSID (refer to Section 8.3).
A Segment-List of an explicit candidate path MUST be declared invalid A segment list of an explicit candidate path MUST be declared invalid
when any of the following is true: when any of the following is true:
* It is empty. * It is empty.
* Its weight is 0. * Its weight is 0.
* It comprises a mix of SR-MPLS and SRv6 segment types. * It comprises a mix of SR-MPLS and SRv6 segment types.
* The headend is unable to perform path resolution for the first SID * The headend is unable to perform path resolution for the first SID
into one or more outgoing interface(s) and next-hop(s). into one or more outgoing interface(s) and next-hop(s).
* The headend is unable to perform SID resolution for any non-first * 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 SID. SID of type C through K into an MPLS label or an SRv6 SID.
* The headend verification fails for any SID for which verification * The headend verification fails for any SID for which verification
skipping to change at line 833 skipping to change at line 834
through K in its SR-DB. through K in its SR-DB.
* The headend is unable to perform SID resolution for any non-first * 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 SID. SID of type C through K into an MPLS label or an SRv6 SID.
In multi-domain deployments, it is expected that the headend may be In multi-domain deployments, it is expected that the headend may be
unable to verify the reachability of the SIDs in remote domains. 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 Types A or B MUST be used for the SIDs for which the reachability
cannot be verified. Note that the first SID MUST always be reachable cannot be verified. Note that the first SID MUST always be reachable
regardless of its type. regardless of its type.
Additionally, a Segment-List MAY be declared invalid when both of the Additionally, a segment list MAY be declared invalid when both of the
conditions below are met : conditions below are met :
* Its last segment is not a Prefix SID (including BGP Peer Node-SID) * Its last segment is not a Prefix SID (including BGP Peer Node-SID)
advertised by the node specified as the endpoint of the advertised by the node specified as the endpoint of the
corresponding SR Policy. corresponding SR Policy.
* Its last segment is not an Adjacency SID (including BGP Peer * 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. corresponding SR Policy.
An explicit candidate path is invalid as soon as it has no valid An explicit candidate path is invalid as soon as it has no valid
Segment-List. segment list.
Additionally, an explicit candidate path MAY be declared invalid when Additionally, an explicit candidate path MAY be declared invalid when
its constituent segment lists (valid or invalid) are using segment its constituent segment lists (valid or invalid) are using segment
types of different SR data planes. types of different SR data planes.
5.2. Dynamic Candidate Path 5.2. Dynamic Candidate Path
A dynamic candidate path is specified as an optimization objective A dynamic candidate path is specified as an optimization objective
and constraints. and a set of constraints.
The headend of the policy leverages its SR database to compute a 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 specified. problem for either the SR-MPLS or the SRv6 data plane as specified.
The headend re-computes the solution Segment-List any time the inputs The headend re-computes the solution segment list any time the inputs
to the problem change (e.g., topology changes). to the problem change (e.g., topology changes).
When the local computation is not possible (e.g., a policy's tail end 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, the is outside the topology known to the headend) or not desired, the
headend may rely on an external entity. For example, a path 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 [RFC8664]. specified in [RFC8664].
If no solution is found to the optimization objective and 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 MUST be declared
invalid. invalid.
Section 3 of [SR-POLICY-CONSID] discusses some of the optimization [SR-POLICY-CONSID] discusses some of the optimization objectives and
objectives and constraints that may be considered by a dynamic constraints that may be considered by a dynamic candidate path. It
candidate path. It illustrates some of the desirable properties of illustrates some of the desirable properties of the computation of
the computation of the solution Segment-List. the solution segment list.
5.3. Composite Candidate Path 5.3. Composite Candidate Path
A composite candidate path is specified as a group of its constituent A composite candidate path is specified as a group of its constituent
SR Policies. SR Policies.
A composite candidate path is valid when it has at least one valid A composite candidate path is valid when it has at least one valid
constituent SR Policy. constituent SR Policy.
6. Binding SID 6. Binding SID
The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. The Binding SID (BSID) is fundamental to Segment Routing [RFC8402].
It provides scaling, network opacity, and service independence. It provides scaling, network opacity, and service independence.
Section 6 of [SR-POLICY-CONSID] illustrates some of these benefits. [SR-POLICY-CONSID] illustrates some of these benefits. This section
This section describes the association of BSID with an SR Policy. describes the association of BSID with an SR Policy.
6.1. BSID of a Candidate Path 6.1. BSID of a Candidate Path
Each candidate path MAY be defined with a BSID. Each candidate path MAY be defined with a BSID.
Candidate paths of the same SR Policy SHOULD have the same BSID. Candidate paths of the same SR Policy SHOULD have the same BSID.
Candidate paths of different SR Policies MUST NOT have the same BSID. Candidate paths of different SR Policies MUST NOT have the same BSID.
6.2. BSID of an SR Policy 6.2. BSID of an SR Policy
The BSID of an SR Policy is the BSID of its active candidate path. The BSID of an SR Policy is the BSID of its active candidate path.
When the active candidate path has a specified BSID, the SR Policy When the active candidate path has a specified BSID, the SR Policy
uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
available (i.e., not associated with any other usage: e.g., label available. A BSID is available when its value is not associated with
used by some other MPLS forwarding entry, SRv6 SID used in some other any other usage, e.g., a label used by some other MPLS forwarding
context, to another SID, to another SR Policy, outside the range of 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). SRv6 Locators).
In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM
[RFC8986]) MAY be associated with the SR Policy in addition to the [RFC8986]) MAY be associated with the SR Policy in addition to the
MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g., with MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g., with
different behaviors like End.B6.Encaps and End.B6.Encaps.Red different behaviors like End.B6.Encaps and End.B6.Encaps.Red
[RFC8986]) MAY be associated with the SR Policy. [RFC8986]) MAY be associated with the SR Policy.
Optionally, instead of only checking that the BSID of the active path Optionally, instead of only checking that the BSID of the active path
is available, a headend MAY check that it is available within the is available, a headend MAY check that it is available within the
skipping to change at line 985 skipping to change at line 987
BSID of the active path is not available (optionally not in the 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 SRLB), then the SR Policy does not install any entry indexed by a
BSID in the forwarding plane. BSID in the forwarding plane.
6.4. Non-SR Usage of Binding SID 6.4. Non-SR Usage of Binding SID
An implementation MAY choose to associate a Binding SID with any type An implementation MAY choose to associate a Binding SID with any type
of interface (e.g., a layer 3 termination of an Optical Circuit) or a of interface (e.g., a layer 3 termination of an Optical Circuit) or a
tunnel (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
tunnel, etc). This enables the use of other non-SR-enabled tunnel, etc). This enables the use of other non-SR-enabled
interfaces and tunnels as segments in an SR Policy Segment-List interfaces and tunnels as segments in an SR Policy segment list
without the need of forming routing protocol adjacencies over them. without the need of forming routing protocol adjacencies over them.
The details of this kind of usage are beyond the scope of this The details of this kind of usage are beyond the scope of this
document. A specific packet-optical integration use case is document. A specific packet-optical integration use case is
described in [POI-SR]. described in [POI-SR].
7. SR Policy State 7. SR Policy State
The SR Policy state is maintained on the headend to represent the 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 accurate representation of whether the SR Policy is being
instantiated in the forwarding plane and which of its candidate paths instantiated in the forwarding plane and which of its candidate paths
and segment-list(s) are active. The SR Policy state MUST also and segment list(s) are active. The SR Policy state MUST also
reflect the reason when a policy and/or its candidate path is not reflect the reason when a policy and/or its candidate path is not
active due to validation errors or not being preferred. The active due to validation errors or not being preferred. The
operational state information reported for SR Policies are specified operational state information reported for SR Policies are specified
in [SR-POLICY-YANG]. in [SR-POLICY-YANG].
The SR Policy state can be reported by the headend node via BGP-LS The SR Policy state can be reported by the headend node via BGP-LS
[TE-POLICIES-BGP-LS] or PCEP [RFC8231] and [BINDING-LABEL-SID]. [BGP-LS-TE-POLICY] or PCEP [RFC8231] [PCEP-BSID-LABEL].
SR Policy state on the headend also includes traffic accounting SR Policy state on the headend also includes traffic accounting
information for the flows being steered via the policies. The information for the flows being steered via the policies. The
details of the SR Policy accounting are beyond the scope of this details of the SR Policy accounting are beyond the scope of this
document. The aspects related to the SR traffic counters and their document. The aspects related to the SR traffic counters and their
usage in the broader context of traffic accounting in an SR network usage in the broader context of traffic accounting in an SR network
are covered in [SR-TRAFFIC-COUNTERS] and [SR-TRAFFIC-ACCOUNTING], are covered in [SR-TRAFFIC-COUNTERS] and [SR-TRAFFIC-ACCOUNTING],
respectively. respectively.
Implementations MAY support an administrative state to control Implementations MAY support an administrative state to control
locally provisioned policies via mechanisms like CLI or NETCONF. locally provisioned policies via mechanisms like command-line
interface (CLI) or NETCONF.
8. Steering into an SR Policy 8. Steering into an SR Policy
A headend can steer a packet flow into a valid SR Policy in various A headend can steer a packet flow into a valid SR Policy in various
ways: ways:
* Incoming packets have an active SID matching a local BSID at the * Incoming packets have an active SID matching a local BSID at the
headend. headend.
* Per-Destination Steering: incoming packets match a BGP/Service * Per-Destination Steering: incoming packets match a BGP/Service
route, which recurses on an SR Policy. route, which recurses on an SR Policy.
skipping to change at line 1046 skipping to change at line 1049
By default, upon transitioning to the invalid state, By default, upon transitioning to the invalid state,
* an SR Policy and its BSID are removed from the forwarding plane. * an SR Policy and its BSID are removed from the forwarding plane.
* any steering of a service (Pseudowire (PW)), destination (BGP- * any steering of a service (Pseudowire (PW)), destination (BGP-
VPN), flow or packet on the related SR Policy is disabled and the 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 destination classic forwarding table (e.g., longest match to the destination
or the recursing next-hop). or the recursing next-hop).
8.2. Drop upon Invalid SR Policy 8.2. Drop-upon-Invalid SR Policy
An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This
would entail the following: would entail the following:
* an invalid SR Policy and its BSID is kept in the forwarding plane * an invalid SR Policy and its BSID is kept in the forwarding plane
with an action to drop. with an action to drop.
* any steering of a service (PW), destination (BGP-VPN), flow, or * 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. drop all of this traffic.
The Drop-Upon-Invalid behavior has been deployed in use cases where 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 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. shortest path to the PW endpoint.
8.3. Incoming Active SID is a BSID 8.3. Incoming Active SID is a BSID
Let us assume that headend H has a valid SR Policy P of Segment-List Let us assume that headend H has a valid SR Policy P of segment list
<S1, S2, S3> and BSID B. <S1, S2, S3> and BSID B.
In the case of SR-MPLS, when H receives a packet K with label stack In the case of SR-MPLS, when H receives a packet K with label stack
<B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the <B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the
resulting packet according to SID S1. resulting packet according to SID S1.
| "Forwards the resulting packet according to SID S1" means: If | "Forwards the resulting packet according to SID S1" means: If
| S1 is an Adj-SID or a PHP-enabled prefix SID advertised by a | S1 is an Adj-SID or a PHP-enabled prefix SID advertised by a
| neighbor, H sends the resulting packet with label stack <S2, | neighbor, H sends the resulting packet with label stack <S2,
| S3, L2, L3> on the outgoing interface associated with S1; Else, | S3, L2, L3> on the outgoing interface associated with S1; Else,
skipping to change at line 1110 skipping to change at line 1113
8.4. Per-Destination Steering 8.4. Per-Destination Steering
This section describes how a headend applies steering of flows 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 [RFC9012]. community [RFC9012].
In the case of SR-MPLS, let us assume that headend H: In the case of SR-MPLS, let us assume that headend H:
* learns a BGP route R/r via next-hop N, Color Extended community C, * learns a BGP route R/r via next-hop N, Color Extended community C,
and VPN label V. and VPN label V.
* has a valid SR Policy P to (color = C, endpoint = N) of Segment- * has a valid SR Policy P to (color = C, endpoint = N) of segment
List <S1, S2, S3> and BSID B. list <S1, S2, S3> and BSID B.
* has a BGP policy that matches on the Color Extended community C * has a BGP policy that matches on the Color Extended community C
and allows its usage as SLA steering information. and allows its usage as SLA steering information.
If all these conditions are met, H installs R/r in RIB/FIB with next- 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. hop = SR Policy P of BSID B instead of via N.
Indeed, H's local BGP policy and the received BGP route indicate that 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 endpoint N the headend should associate R/r with an SR Policy path to endpoint N
with the SLA associated with color C. The headend, therefore, with the SLA associated with color C. The headend, therefore,
installs the BGP route on that policy. installs the BGP route on that policy.
This can be implemented by using the BSID as a generalized next-hop This can be implemented by using the BSID as a generalized next-hop
and installing the BGP route on that generalized next-hop. and installing the BGP route on that generalized next-hop.
When H receives a packet K with a destination matching R/r, H pushes When H receives a packet K with a destination matching R/r, H pushes
the label stack <S1, S2, S3, V> and sends the resulting packet along the label stack <S1, S2, S3, V> and sends the resulting packet along
the path to S1. the path to S1.
Note that any SID associated with the BGP route is inserted after the Note that any SID associated with the BGP route is inserted after the
Segment-List of the SR Policy (i.e., <S1, S2, S3, V>). segment list of the SR Policy (i.e., <S1, S2, S3, V>).
In the case of SRv6, the processing is similar and follows the SR In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in Section 5 of [RFC8986]. Policy headend behaviors as specified in Section 5 of [RFC8986].
The same behavior applies to any type of service route: any AFI/SAFI The same behavior applies to any type of service route: any AFI/SAFI
of BGP [RFC4760] or the Locator/ID Separation Protocol (LISP) of BGP [RFC4760] or the Locator/ID Separation Protocol (LISP)
[RFC6830] for both IPv4/IPv6. [RFC6830] for both IPv4/IPv6.
In a BGP multi-path scenario, the BGP route MAY be resolved over a In a BGP multi-path scenario, the BGP route MAY be resolved 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
skipping to change at line 1158 skipping to change at line 1161
When a BGP route has multiple Color Extended communities each with a When a BGP route has multiple Color Extended communities each with a
valid SR Policy, the BGP process installs the route on the SR Policy valid SR Policy, the BGP process installs the route on the SR Policy
giving preference to the Color Extended community with the highest giving preference to the Color Extended community with the highest
numerical value. numerical value.
Let us assume that headend H: Let us assume that headend H:
* learns a BGP route R/r via next-hop N, Color Extended communities * learns a BGP route R/r via next-hop N, Color Extended communities
C1 and C2. C1 and C2.
* has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- * has a valid SR Policy P1 to (color = C1, endpoint = N) of segment
List <S1, S2, S3> and BSID B1. list <S1, S2, S3> and BSID B1.
* has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- * has a valid SR Policy P2 to (color = C2, endpoint = N) of segment
List <S4, S5, S6> and BSID B2. list <S4, S5, S6> and BSID B2.
* has a BGP policy that matches the Color Extended communities C1 * has a BGP policy that matches the Color Extended communities C1
and C2 and allows their usage as SLA steering information and C2 and allows their usage as SLA steering information
If all these conditions are met, H installs R/r in RIB/FIB with next- 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 > C1. hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1.
When the SR Policy with a specific color is not instantiated or in When the SR Policy with a specific color is not instantiated or in
the down/inactive state, the SR Policy with the next highest the down/inactive state, the SR Policy with the next highest
numerical value of color is considered. numerical value of color is considered.
skipping to change at line 1203 skipping to change at line 1206
SR Policy that is used for steering is then determined as described SR Policy that is used for steering is then determined as described
in Section 8.4.1. in Section 8.4.1.
8.6. Per-Flow Steering 8.6. Per-Flow Steering
This section provides an example of how a headend might apply per- This section provides an example of how a headend might apply per-
flow steering in practice. flow steering in practice.
Let us assume that headend H: Let us assume that headend H:
* has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment- * has a valid SR Policy P1 to (color = C1, endpoint = N) of segment
List <S1, S2, S3> and BSID B1. list <S1, S2, S3> and BSID B1.
* has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment- * has a valid SR Policy P2 to (color = C2, endpoint = N) of segment
List <S4, S5, S6> and BSID B2. list <S4, S5, S6> and BSID B2.
* is configured to instantiate an array of paths to N where the * 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 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 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, a Forwarding Class (FC). The index can have values 0 to 7,
especially when derived from the MPLS TC bits [RFC5462]. especially when derived from the MPLS TC bits [RFC5462].
* is configured to match flows in its ingress interfaces (upon any * is configured to match flows in its ingress interfaces (upon any
field such as Ethernet destination/source/VLAN/TOS or IP field such as Ethernet destination/source/VLAN/TOS or IP
destination/source/Differentiated Services Code Point (DSCP), or destination/source/Differentiated Services Code Point (DSCP), or
transport ports etc.), and color them with an internal per-packet transport ports etc.), and color them with an internal per-packet
forwarding-class variable (0, 1, or 2 in this example). forwarding-class variable (0, 1, or 2 in this example).
skipping to change at line 1243 skipping to change at line 1246
* H forwards K along the shortest path to N (i.e., pushes the * H forwards K along the shortest path to N (i.e., pushes the
Prefix-SID of N). Prefix-SID of N).
* H pushes <S1, S2, S3> on packet K1 and forwards the resulting * H pushes <S1, S2, S3> on packet K1 and forwards the resulting
frame along the shortest path to S1. frame along the shortest path to S1.
* H pushes <S4, S5, S6> on packet K2 and forwards the resulting * H pushes <S4, S5, S6> on packet K2 and forwards the resulting
frame along the shortest path to S4. frame along the shortest path to S4.
For SRv6, the processing is similar and the segment lists of the 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 of Section 5 of using the SR Policy headend behaviors as specified in Section 5 of
[RFC8986]. [RFC8986].
If the local configuration does not specify any explicit forwarding 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). the same information as entry 0 (i.e., the IGP shortest path).
If the SR Policy mapped to an entry of the array becomes invalid, 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 entry 0, 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
skipping to change at line 1295 skipping to change at line 1298
This is the most likely form of BGP destination steering and the one This is the most likely form of BGP destination steering and the one
recommended for most use cases. recommended for most use cases.
This section defines an alternative steering mechanism based only on This section defines an alternative steering mechanism based only on
the Color Extended community. the Color Extended community.
Three types of steering modes are defined. Three types of steering modes are defined.
For the default, Type 0, the BGP destination is steered as follows: For the default, Type 0, the BGP destination is steered as follows:
IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
endpoint address and C is a color; endpoint address and C is a color;
Steer into SR Policy (N, C); Steer into SR Policy (N, C);
ELSE; ELSE;
Steer on the IGP path to the next-hop N. Steer on the IGP path to the next-hop N.
This is the classic case described in this document previously and This is the classic case described in this document previously and
what is recommended in most scenarios. what is recommended in most scenarios.
For Type 1, the BGP destination is steered as follows: For Type 1, the BGP destination is steered as follows:
IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6 IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
endpoint address and C is a color; endpoint address and C is a color;
Steer into SR Policy (N, C); Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C) of the ELSE IF there is a valid SR Policy (null endpoint, C) of the
same address-family of N; same address-family of N;
Steer into SR Policy (null endpoint, C); Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy ELSE IF there is any valid SR Policy
(any address-family null endpoint, C); (any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C); Steer into SR Policy (any null endpoint, C);
ELSE; ELSE;
Steer on the IGP path to the next-hop N. Steer on the IGP path to the next-hop N.
For Type 2, the BGP destination is steered as follows: For Type 2, the BGP destination is steered as follows:
IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6 IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6
endpoint address and C is a color; endpoint address and C is a color;
Steer into SR Policy (N, C); Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C) ELSE IF there is a valid SR Policy (null endpoint, C)
of the same address-family of N; of the same address-family of N;
Steer into SR Policy (null endpoint, C); Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy ELSE IF there is any valid SR Policy
(any address-family null endpoint, C); (any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C); Steer into SR Policy (any null endpoint, C);
ELSE IF there is any valid SR Policy (any endpoint, C) ELSE IF there is any valid SR Policy (any endpoint, C)
of the same address-family of N; of the same address-family of N;
Steer into SR Policy (any endpoint, C); Steer into SR Policy (any endpoint, C);
ELSE IF there is any valid SR Policy ELSE IF there is any valid SR Policy
(any address-family endpoint, C); (any address-family endpoint, C);
Steer into SR Policy (any address-family endpoint, C); Steer into SR Policy (any address-family endpoint, C);
ELSE; ELSE;
Steer on the IGP path to the next-hop N. Steer on the IGP path to the next-hop N.
The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set
to the 0 value). to the 0 value).
Please refer to [IDR-SR-TE-POLICY] for the updates to the BGP Color Please refer to [BGP-SR-POLICY] for the updates to the BGP Color
Extended community for the implementation of these mechanisms. Extended community for the implementation of these mechanisms.
8.8.2. Multiple Colors and CO flags 8.8.2. Multiple Colors and CO flags
The steering preference is first based on the highest Color Extended The steering preference is first based on the highest Color Extended
community value and then Color-Only steering type for the color. community value and then Color-Only steering type for the color.
Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2, the steering Assuming a Prefix via (NH, C1(CO=01), C2(CO=01)); C1>C2. The
preference order is: steering preference order is:
* SR Policy (NH, C1). * SR Policy (NH, C1).
* SR Policy (null, C1). * SR Policy (null, C1).
* SR Policy (NH, C2). * SR Policy (NH, C2).
* SR Policy (null, C2). * SR Policy (null, C2).
* IGP to NH. * IGP to NH.
8.8.3. Drop upon Invalid 8.8.3. Drop-upon-Invalid
This document defined earlier that when all the following conditions This document defined earlier that when all the following conditions
are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of
BSID B instead of via N. BSID B instead of via N.
* H learns a BGP route R/r via next-hop N, Color Extended community * H learns a BGP route R/r via next-hop N, Color Extended community
C. C.
* H has a valid SR Policy P to (color = C, endpoint = N) of Segment- * H has a valid SR Policy P to (color = C, endpoint = N) of segment
List <S1, S2, S3> and BSID B. list <S1, S2, S3> and BSID B.
* H has a BGP policy that matches the Color Extended community C and * H has a BGP policy that matches the Color Extended community C and
allows its usage as SLA steering information. allows its usage as SLA steering information.
This behavior is extended by noting that the BGP Policy may require This behavior is extended by noting that the BGP Policy may require
the BGP steering to always stay on the SR Policy whatever its the BGP steering to always stay on the SR Policy whatever its
validity. validity.
This is the "drop upon invalid" option described in Section 8.2 This is the "drop-upon-invalid" option described in Section 8.2
applied to BGP-based steering. applied to BGP-based steering.
9. Recovering from Network Failures 9. Recovering from Network Failures
9.1. Leveraging TI-LFA Local Protection of the Constituent IGP Segments 9.1. Leveraging TI-LFA Local Protection of the Constituent IGP Segments
In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) In any topology, Topology-Independent Loop-Free Alternate (TI-LFA)
[SR-TI-LFA] provides a 50 msec local protection technique for IGP [SR-TI-LFA] provides a 50 msec local protection technique for IGP
SIDs. The backup path is computed on a per-IGP-SID basis along the SIDs. The backup path is computed on a per-IGP-SID basis along the
post-convergence path. post-convergence path.
skipping to change at line 1405 skipping to change at line 1408
protection. protection.
9.2. Using an SR Policy to Locally Protect a Link 9.2. Using an SR Policy to Locally Protect a Link
1----2-----6----7 1----2-----6----7
| | | | | | | |
4----3-----9----8 4----3-----9----8
Figure 1: Local Protection Using SR Policy Figure 1: Local Protection Using SR Policy
An SR Policy can be instantiated at node 2 to protect link 2to6. A An SR Policy can be instantiated at node 2 to protect link 2-to-6. A
typical explicit Segment-List would be <3, 9, 6>. typical explicit segment list would be <3, 9, 6>.
A typical use case occurs for links outside an IGP domain: e.g., 1, 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 <3, 9, 6> on node 2 can be locally configured to be with segment list <3, 9, 6> on node 2 can be locally configured to be
a fast-reroute backup path for the link 2to6. a fast-reroute backup path for the link 2-to-6.
9.3. Using a Candidate Path for Path Protection 9.3. Using a Candidate Path for Path Protection
An SR Policy allows for multiple candidate paths, of which at any 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 MAY 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: following options are possible:
skipping to change at line 1504 skipping to change at line 1507
apply. apply.
A YANG model for the configuration and operation of SR Policy has A YANG model for the configuration and operation of SR Policy has
been defined in [SR-POLICY-YANG]. been defined in [SR-POLICY-YANG].
12. IANA Considerations 12. IANA Considerations
IANA has created a new subregistry called "Segment Types" under the IANA has created a new subregistry called "Segment Types" under the
"Segment Routing" registry that was created by [RFC8986]. This "Segment Routing" registry that was created by [RFC8986]. This
subregistry maintains the alphabetic identifiers for the segment subregistry maintains the alphabetic identifiers for the segment
types (as specified in Section 4) that may be used within a Segment types (as specified in Section 4) that may be used within a segment
List of an SR Policy. The alphabetical identifiers run from A to Z list of an SR Policy. The alphabetical identifiers run from A to Z
and may be extended on exhaustion with the identifiers AA to AZ, BA and may be extended on exhaustion with the identifiers AA to AZ, BA
to BZ, and so on, through ZZ. This subregistry follows the to BZ, and so on, through ZZ. This subregistry follows the
Specification Required allocation policy as specified in [RFC8126]. Specification Required allocation policy as specified in [RFC8126].
The initial registrations for this subregistry are as follows: The initial registrations for this subregistry are as follows:
+=======+=============================================+===========+ +=======+=============================================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+=============================================+===========+ +=======+=============================================+===========+
| A | SR-MPLS Label | RFC 9256 | | A | SR-MPLS Label | RFC 9256 |
skipping to change at line 1572 skipping to change at line 1575
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
S. Ray, "North-Bound Distribution of Link-State and Ray, "North-Bound Distribution of Link-State and Traffic
Traffic Engineering (TE) Information Using BGP", RFC 7752, Engineering (TE) Information Using BGP",
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, RFC 7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Litkowski, S., and R. Shakir, "Segment Routing
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Architecture", DOI 10.17487/RFC8402, RFC 8402, July 2018,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
skipping to change at line 1616 skipping to change at line 1619
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
13.2. Informative References 13.2. Informative References
[BINDING-LABEL-SID] [BGP-LS-TE-POLICY]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., Previdi, S., Talaulikar, K., Ed., Dong, J., Ed., Chen, M.,
and C. Li, Ed., "Carrying Binding Label/Segment Identifier Gredler, H., and J. Tantsura, "Distribution of Traffic
(SID) in PCE-based Networks.", Work in Progress, Internet- Engineering (TE) Policies and State using BGP-LS", Work in
Draft, draft-ietf-pce-binding-label-sid-15, March 2022, Progress, Internet-Draft, draft-ietf-idr-te-lsp-
<https://datatracker.ietf.org/doc/html/draft-ietf-pce- distribution-17, April 2022,
binding-label-sid-15>. <https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-
lsp-distribution-17>.
[IDR-SR-TE-POLICY] [BGP-SR-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., Jain, D., and S. Lin, "Advertising Segment Routing P., Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", Work in Progress, Internet-Draft, draft- Policies in BGP", Work in Progress, Internet-Draft, draft-
ietf-idr-segment-routing-te-policy-17, April 2022, ietf-idr-segment-routing-te-policy-18, June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-17>. segment-routing-te-policy-18>.
[IGP-FLEX-ALGO] [IGP-FLEX-ALGO]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", Work in Progress, and A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022, Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr- <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-20>. flex-algo-20>.
[PCEP-BSID-LABEL]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/Segment Identifier
(SID) in PCE-based Networks.", Work in Progress, Internet-
Draft, draft-ietf-pce-binding-label-sid-15, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
binding-label-sid-15>.
[PCEP-SR-POLICY-CP]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-07, 21 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-07>.
[POI-SR] Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., [POI-SR] Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J.,
Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical
Integration in Segment Routing", Work in Progress, Integration in Segment Routing", Work in Progress,
Internet-Draft, draft-anand-spring-poi-sr-08, 29 July Internet-Draft, draft-anand-spring-poi-sr-08, 29 July
2019, <https://datatracker.ietf.org/doc/html/draft-anand- 2019, <https://datatracker.ietf.org/doc/html/draft-anand-
spring-poi-sr-08>. spring-poi-sr-08>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R W., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", DOI 10.17487/RFC1195, RFC 1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", DOI 10.17487/RFC2328, STD 54,
DOI 10.17487/RFC2328, April 1998, RFC 2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
skipping to change at line 1683 skipping to change at line 1703
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>. <https://www.rfc-editor.org/info/rfc5307>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008, RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>. <https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", DOI 10.17487/RFC5340, RFC 5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
skipping to change at line 1748 skipping to change at line 1768
2021, <https://www.rfc-editor.org/info/rfc9086>. 2021, <https://www.rfc-editor.org/info/rfc9086>.
[SR-POLICY-CONSID] [SR-POLICY-CONSID]
Filsfils, C., Talaulikar, K., Ed., Krol, P., Horneffer, Filsfils, C., Talaulikar, K., Ed., Krol, P., Horneffer,
M., and P. Mattes, "SR Policy Implementation and M., and P. Mattes, "SR Policy Implementation and
Deployment Considerations", Work in Progress, Internet- Deployment Considerations", Work in Progress, Internet-
Draft, draft-filsfils-spring-sr-policy-considerations-09, Draft, draft-filsfils-spring-sr-policy-considerations-09,
24 April 2022, <https://datatracker.ietf.org/doc/html/ 24 April 2022, <https://datatracker.ietf.org/doc/html/
draft-filsfils-spring-sr-policy-considerations-09>. draft-filsfils-spring-sr-policy-considerations-09>.
[SR-POLICY-CP]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-07, 21 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-07>.
[SR-POLICY-YANG] [SR-POLICY-YANG]
Raza, K., Ed., Sawaya, S., Shunwan, Z., Voyer, D., Raza, K., Ed., Sawaya, S., Shunwan, Z., Voyer, D.,
Durrani, M., Matsushima, S., and V. Beeram, "YANG Data Durrani, M., Matsushima, S., and V. Beeram, "YANG Data
Model for Segment Routing Policy", Work in Progress, Model for Segment Routing Policy", Work in Progress,
Internet-Draft, draft-ietf-spring-sr-policy-yang-01, April Internet-Draft, draft-ietf-spring-sr-policy-yang-01, April
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
spring-sr-policy-yang-01>. spring-sr-policy-yang-01>.
[SR-TI-LFA] [SR-TI-LFA]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
skipping to change at line 1783 skipping to change at line 1795
[SR-TRAFFIC-ACCOUNTING] [SR-TRAFFIC-ACCOUNTING]
Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S., Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S.,
Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D.,
Morton, R., and G. Dawra, "Traffic Accounting in Segment Morton, R., and G. Dawra, "Traffic Accounting in Segment
Routing Networks", Work in Progress, Internet-Draft, Routing Networks", Work in Progress, Internet-Draft,
draft-ali-spring-sr-traffic-accounting-07, May 2022, draft-ali-spring-sr-traffic-accounting-07, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ali-spring- <https://datatracker.ietf.org/doc/html/draft-ali-spring-
sr-traffic-accounting-07>. sr-traffic-accounting-07>.
[SR-TRAFFIC-COUNTERS] [SR-TRAFFIC-COUNTERS]
Filsfils, C., Ali, A., Ed., Horneffer, M., Voyer, D., Filsfils, C., Ali, Z., Ed., Horneffer, M., Voyer, D.,
Durrani, M., and R. Raszuk, "Segment Routing Traffic Durrani, M., and R. Raszuk, "Segment Routing Traffic
Accounting Counters", Work in Progress, Internet-Draft, Accounting Counters", Work in Progress, Internet-Draft,
draft-filsfils-spring-sr-traffic-counters-02, October draft-filsfils-spring-sr-traffic-counters-02, October
2021, <https://datatracker.ietf.org/doc/html/draft- 2021, <https://datatracker.ietf.org/doc/html/draft-
filsfils-spring-sr-traffic-counters-02>. filsfils-spring-sr-traffic-counters-02>.
[TE-POLICIES-BGP-LS]
Previdi, S., Ed., Talaulikar, K., Ed., Dong, J., Ed.,
Chen, M., Gredler, H., and J. Tantsura, "Distribution of
Traffic Engineering (TE) Policies and State using BGP-LS",
Work in Progress, Internet-Draft, draft-ietf-idr-te-lsp-
distribution-17, April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-
lsp-distribution-17>.
Acknowledgement Acknowledgement
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha, Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha,
Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi, Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi,
Matthew Bocci, Cullen Jennings, and Carlos J. Bernardos for their Matthew Bocci, Cullen Jennings, and Carlos J. Bernardos for their
review, comments, and suggestions. review, comments, and suggestions.
Contributors Contributors
 End of changes. 112 change blocks. 
239 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/