Internet DRAFT - draft-ietf-spring-segment-routing-policy
draft-ietf-spring-segment-routing-policy
SPRING Working Group C. Filsfils
Internet-Draft K. Talaulikar, Ed.
Updates: 8402 (if approved) Cisco Systems, Inc.
Intended status: Standards Track D. Voyer
Expires: September 23, 2022 Bell Canada
A. Bogdanov
British Telecom
P. Mattes
Microsoft
March 22, 2022
Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-22
Abstract
Segment Routing (SR) allows a node to steer a packet flow along any
path. Intermediate per-path states are eliminated thanks to source
routing. SR Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. Packet flows
are steered into a SR Policy on a node where it is instantiated
called a headend node. The packets steered into an SR Policy carry
an ordered list of segments associated with that SR Policy.
This document updates RFC8402 as it details the concepts of SR Policy
and steering into an SR Policy.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 23, 2022.
Filsfils, et al. Expires September 23, 2022 [Page 1]
Internet-Draft SR Policy Architecture March 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Identification of an SR Policy . . . . . . . . . . . . . 4
2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5
2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6
2.4. Originator of a Candidate Path . . . . . . . . . . . . . 7
2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7
2.6. Identification of a Candidate Path . . . . . . . . . . . 8
2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8
2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 9
2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 9
2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 10
2.11. Instantiation of an SR Policy in the Forwarding Plane . . 10
2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 11
2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Segment Routing Database . . . . . . . . . . . . . . . . . . 12
4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 17
5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 17
5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 17
5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 19
5.3. Composite Candidate Path . . . . . . . . . . . . . . . . 19
6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 20
6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 20
6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 21
6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 22
7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 22
8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 22
8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 23
Filsfils, et al. Expires September 23, 2022 [Page 2]
Internet-Draft SR Policy Architecture March 2022
8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 23
8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 23
8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 24
8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 26
8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 26
8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 28
8.8. Optional Steering Modes for BGP Destinations . . . . . . 28
9. Recovering from Network Failures . . . . . . . . . . . . . . 30
9.1. Leveraging TI-LFA local protection of the constituent IGP
segments . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Using an SR Policy to locally protect a link . . . . . . 30
9.3. Using a Candidate Path for Path Protection . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Manageability Considerations . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.1. Guidance for Designated Experts . . . . . . . . . . . . 33
13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow
along any path. The headend is a node where the instructions for
source routing (i.e., segments) are written into the packet and hence
becomes the starting node for a specific segment routing path.
Intermediate per-path states are eliminated thanks to source routing.
A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of
segments (i.e., instructions) that represent a source-routed policy.
The headend node is said to steer a flow into a SR Policy. The
packets steered into an SR Policy have an ordered list of segments
associated with that SR Policy written into them. [RFC8660]
describes the representation and processing of this ordered list of
segments as an MPLS label stack for SR-MPLS, while [RFC8754] and
[RFC8986] describe the same for Segment Routing over IPv6 (SRv6) with
the use of the Segment Routing Header (SRH).
[RFC8402] introduces the SR Policy construct and provides an overview
of how it is leveraged for Segment Routing use-cases. This document
updates [RFC8402] to specify detailed concepts of SR Policy and
steering packets into an SR Policy. It applies equally to the SR-
MPLS and SRv6 instantiations of segment routing.
Filsfils, et al. Expires September 23, 2022 [Page 3]
Internet-Draft SR Policy Architecture March 2022
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SR Policy
The general concept of SR Policy provides a framework that enables
the instantiation of an ordered list of segments on a node for
implementing a source routing policy for the steering of traffic for
a specific purpose (e.g. for a specific SLA) from that node.
The Segment Routing architecture [RFC8402] specifies that any
instruction can be bound to a segment. Thus, an SR Policy can be
built using any type of Segment Identifier (SID) including those
associated with topological or service instructions.
This section defines the key aspects and constituents of an SR
Policy.
2.1. Identification of an SR Policy
An SR Policy MUST be identified through the tuple <headend, color,
endpoint>. In the context of a specific headend, an SR policy MUST
be identified by the <color, endpoint> tuple.
The headend is the node where the policy is instantiated/implemented.
The headend is specified as an IPv4 or IPv6 address and MUST resolve
to a unique node in the SR domain [RFC8402].
The endpoint indicates the destination of the policy. The endpoint
is specified as an IPv4 or IPv6 address and SHOULD resolve to a
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
for IPv4, :: for IPv6) and in this case, the destination of the
policy is indicated by the last segment in the segment list(s).
The color is an unsigned non-zero 32-bit integer value that
associates the SR Policy with an intent or objective (e.g. low-
latency).
The endpoint and the color are used to automate the steering of
service or transport routes on SR Policies (refer to Section 8).
Filsfils, et al. Expires September 23, 2022 [Page 4]
Internet-Draft SR Policy Architecture March 2022
An implementation MAY allow the assignment of a symbolic name
comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E)
to an SR Policy to serve as a user-friendly attribute for debugging
and troubleshooting purposes. Such symbolic names may identify an SR
Policy when the naming scheme ensures uniqueness. The SR Policy name
MAY also be signaled along with a candidate path of the SR Policy
(refer to Section 2.2). An SR Policy MAY have multiple names
associated with it in the scenario where the headend receives
different SR Policy names along with different candidate paths for
the same SR Policy via the same or different sources.
2.2. Candidate Path and Segment List
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
via protocol extensions like Path Computation Element (PCE)
Communication Protocol (PCEP) [RFC8664]
[I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy
[I-D.ietf-idr-segment-routing-te-policy].
A Segment-List represents a specific source-routed path to send
traffic from the headend to the endpoint of the corresponding SR
policy.
A candidate path is either dynamic, explicit, or composite.
An explicit candidate path is expressed as a Segment-List or a set of
Segment-Lists.
A dynamic candidate path expresses an optimization objective and a
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
Segment-List (or set of Segment-Lists) that solves the optimization
problem.
If a candidate path is associated with a set of Segment-Lists, each
Segment-List is associated with weight for weighted load balancing
(refer to Section 2.11 for details). The default weight is 1.
A composite candidate path acts as a container for grouping SR
Policies. The composite candidate path construct enables the
combination of SR Policies, each with explicit candidate paths and/or
dynamic candidate paths with potentially different optimization
objectives and constraints, for load-balanced steering of packet
flows over its constituent SR Policies. The following criteria apply
for inclusion of constituent SR Policies using a composite candidate
path under a parent SR Policy:
Filsfils, et al. Expires September 23, 2022 [Page 5]
Internet-Draft SR Policy Architecture March 2022
o the endpoints of the constituent SR Policies and the parent SR
Policy MUST be identical
o The colors of each of the constituent SR Policies and the parent
SR Policy MUST be different
o the constituent SR Policies MUST NOT use composite candidate paths
Each constituent SR Policy of a composite candidate path is
associated with weight for load-balancing purposes (refer to
Section 2.11 for details). The default weight is 1.
The Section 2.13 illustrates an information model for hierarchical
relationships between the SR Policy constructs described in this
section.
2.3. Protocol-Origin of a Candidate Path
A headend may be informed about a candidate path for an SR Policy
<color, endpoint> by various means including: via configuration, PCEP
[RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP
[I-D.ietf-idr-segment-routing-te-policy].
Protocol-Origin of a candidate path is an 8-bit value associated with
the mechanism or protocol used for signaling/provisioning the SR
Policy. It helps identify the protocol/mechanism that provides or
signals the candidate path and indicates its preference relative to
other protocols/mechanisms.
The head-end assigns different Protocol-Origin values to each source
of SR Policy information. The Protocol-Origin value is used as a
tie-breaker between candidate paths of equal preference, as described
in Section 2.9. The table below specifies the RECOMMENDED default
values of Protocol-Origin:
+-----------------+-------------------+
| Protocol-Origin | Description |
+-----------------+-------------------+
| 10 | PCEP |
| 20 | BGP SR Policy |
| 30 | Via Configuration |
+-----------------+-------------------+
Table 1: Protocol-Origin default values
Note that the above order is to satisfy the need for having a clear
ordering and implementations MAY allow modifications of these default
values assigned to protocols on the headend along similar lines as a
Filsfils, et al. Expires September 23, 2022 [Page 6]
Internet-Draft SR Policy Architecture March 2022
routing administrative distance. Its application in the candidate
path selection is described in Section 2.9.
2.4. Originator of a Candidate Path
Originator identifies the node which provisioned or signaled 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
fields of the tuple <Autonomous System Number (ASN), node-address> as
below:
o 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
the high-order bits MUST be set to zero.
o 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 set to zero.
Its application in the candidate path selection is described in
Section 2.9.
When provisioning is via configuration, the ASN and node address MAY
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.
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
available or known.
When signaling is via BGP SR Policy, the ASN and Node Address are
provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy])
on the headend.
2.5. Discriminator of 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
specific Protocol-Origin as specified below:
o When provisioning is via configuration, this is an
implementation's configuration-model-specific unique identifier
for a candidate path. The default value is 0.
o When signaling is via PCEP, the method to uniquely signal an
individual candidate path along with its discriminator is
described in [I-D.ietf-pce-segment-routing-policy-cp]. The
default value is 0.
Filsfils, et al. Expires September 23, 2022 [Page 7]
Internet-Draft SR Policy Architecture March 2022
o When signaling is via BGP SR Policy, the BGP process receiving the
route provides the distinguisher (refer to Section 2.1 of
[I-D.ietf-idr-segment-routing-te-policy]) as the discriminator.
Note that the BGP best path selection is applied before the route
is supplied as a candidate path, so only a single candidate path
for a given SR Policy will be seen for a given discriminator.
Its application in the candidate path selection is described in
Section 2.9.
2.6. Identification of a Candidate Path
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 identified by its Segment-List(s).
If CP1 is a candidate path of SR Policy Pol1 and CP2 is a
candidate path of SR Policy Pol2, then these two candidate paths
are independent, even if they happen to have the same Segment-
List. The Segment-List does not identify a candidate path. The
Segment-List is an attribute of a candidate path.
The identity of a candidate path MUST be uniquely established in the
context of an SR Policy <headend, color, endpoint> to handle add,
delete or modify operations on them in an unambiguous manner
regardless of their source(s).
The tuple <Protocol-Origin, originator, discriminator> uniquely
identifies a candidate path.
Candidate paths MAY also be assigned or signaled with a symbolic name
comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E)
to serve as a user-friendly attribute for debugging and
troubleshooting purposes. Such symbolic names MUST NOT be considered
as identifiers for a candidate path. The signaling of the candidate
path name via BGP and PCEP is described in
[I-D.ietf-pce-segment-routing-policy-cp] and
[I-D.ietf-idr-segment-routing-te-policy] respectively.
2.7. Preference of a Candidate Path
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
value indicates higher preference and the default preference value is
100.
Filsfils, et al. Expires September 23, 2022 [Page 8]
Internet-Draft SR Policy Architecture March 2022
It is RECOMMENDED that each candidate path of a given SR policy has a
different preference.
The signaling of the candidate path preference via BGP and PCEP is
described in [I-D.ietf-pce-segment-routing-policy-cp] and
[I-D.ietf-idr-segment-routing-te-policy] respectively.
2.8. Validity of a Candidate Path
A candidate path is usable when it is valid. The RECOMMEDED
candidate path validity criterion is the validity of at least one of
its constituent Segment-Lists. The validation rules are specified in
Section 5.
2.9. Active Candidate Path
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
as the "active path" of the SR policy in this document.
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,
the selection process MUST be re-executed.
The candidate path selection process operates primarily on the
candidate path Preference. A candidate path is selected when it is
valid and it has the highest preference value among all the valid
candidate paths of the SR Policy.
In the case of multiple valid candidate paths of the same preference,
the tie-breaking rules are evaluated on the identification tuple in
the following order until only one valid best path is selected:
1. Higher value of Protocol-Origin is selected.
2. If specified by configuration, prefer the existing installed
path.
3. Lower value of originator is selected.
4. Finally, the higher value of discriminator is selected.
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
path selection). The motivation behind these rules are as follows:
o The preference, being the primary criterion, allows an operator to
influence selection across paths thus allowing provisioning of
Filsfils, et al. Expires September 23, 2022 [Page 9]
Internet-Draft SR Policy Architecture March 2022
multiple path options, e.g., CP1 is preferred and if it becomes
invalid then fallback to CP2 and so on. Since preference works
across protocol sources, it also enables (where necessary)
selective override of the default Protocol-Origin preference,
e.g., to prefer a path signaled via BGP SR Policy over what is
configured.
o The Protocol-Origin allows an operator to set up a default
selection mechanism across protocol sources, e.g., to prefer
configured over paths signaled via BGP SR Policy or PCEP.
o The originator allows an operator to have multiple redundant
controllers and still maintain a deterministic behavior over which
of them are preferred even if they are providing the same
candidate paths for the same SR policies to the headend.
o The discriminator performs the final tiebreaking step to ensure a
deterministic outcome of selection regardless of the order in
which candidate paths are signaled across multiple transport
channels or sessions.
Section 4 of [I-D.filsfils-spring-sr-policy-considerations] provides
a set of examples to illustrate the active candidate path selection
rules.
2.10. Validity of an SR Policy
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
Generally, only valid SR policies are instantiated in the forwarding
plane.
Only the active candidate path MUST be used for forwarding traffic
that is being steered onto that policy except for certain scenarios
such as fast-reroute where a backup candidate path may be used as
described in Section 9.3.
If a set of Segment-Lists is associated with the active path of the
policy, then the steering is per-flow and weighted-ECMP (W-ECMP)
based according to the relative weight of each Segment-List.
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
the weights of the Segment-Lists of the selected path of the SR
Policy.
Filsfils, et al. Expires September 23, 2022 [Page 10]
Internet-Draft SR Policy Architecture March 2022
When a composite candidate path is active, the fraction of flows
steered into each constituent SR Policy is equal to the relative
weight of each constituent SR Policy. Further load balancing of
flows steered into a constituent SR Policy is performed based on the
weights of the Segment-List of the active candidate path of that
constituent SR Policy.
The accuracy of the weighted load-balancing depends on the platform
implementation.
2.12. Priority of an SR Policy
Upon topological change, many policies could be recomputed or
revalidated. An implementation MAY provide a per-policy priority
configuration. The operator may set this field to indicate the order
in which the policies should be re-computed. Such a priority is
represented by an integer in the range (0, 255) where the lowest
value is the highest priority. The default value of priority is 128.
An SR Policy may comprise multiple Candidate Paths received from the
same or different sources. A candidate path MAY be signaled with a
priority value. When an SR Policy has multiple candidate paths with
distinct signaled non-default priority values and the SR Policy
itself does not have a priority value configured, the SR Policy as a
whole takes the lowest value (i.e., the highest priority) amongst
these signaled priority values.
2.13. Summary
In summary, the information model is the following:
SR policy POL1 <headend = H1, color = 1, endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator =
64511:192.0.2.1, discriminator = 1>
Preference 200
Priority 10
Segment List 1 <SID11...SID1i>, Weight W1
Segment List 2 <SID21...SID2j>, Weight W2
Candidate-path CP2 <protocol-origin = 20, originator =
64511:192.0.2.2, discriminator = 2>
Preference 100
Priority 10
Segment List 3 <SID31...SID3i>, Weight W3
Segment List 4 <SID41...SID4j>, Weight W4
The SR Policy POL1 is identified by the tuple <headend, color,
endpoint>. It has two candidate paths CP1 and CP2. Each is
identified by a tuple <protocol-origin, originator, discriminator>
Filsfils, et al. Expires September 23, 2022 [Page 11]
Internet-Draft SR Policy Architecture March 2022
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
are installed as the forwarding instantiation of SR policy POL1.
Traffic steered on POL1 is flow-based hashed on Segment-List
<SID11...SID1i> with a ratio W1/(W1+W2).
The information model of SR Policy POL100 having a composite
candidate path is the following:
SR policy POL100 <headend = H1, color = 100, endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator =
64511:192.0.2.1, discriminator = 1>
Preference 200
SR policy <color = 1>, Weight W1
SR policy <color = 2>, Weight W2
The constituent SR Policies POL1 and POL2 have an information model
as described at the start of this section. They are referenced only
by color in the composite candidate path since their headend and
endpoint are identical to the POL100. The valid Segment-Lists of the
active candidate path of POL1 and POL2 are installed in the
forwarding. Traffic steered on POL100 is flow-based hashed on POL1
with a proportion W1/(W1+W2). Within the POL1, the flow-based
hashing over its Segment-Lists are performed as described earlier in
this section.
3. Segment Routing Database
An SR Policy computation node (e.g. headend or controller) maintains
the Segment Routing Database (SR-DB). The SR-DB is a conceptual
database to illustrate the various pieces of information and their
sources that may help in SR Policy computation and validation. There
is no specific requirement for an implementation to create a new
database as such.
An SR headend leverages the SR-DB to validate explicit candidate
paths and compute dynamic candidate paths.
The information in the SR-DB may include:
o IGP information (topology, IGP metrics based on IS-IS [RFC1195]
and OSPF [RFC2328] [RFC5340])
o Segment Routing information (such as Segment Routing Global Block,
Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering
SID, SRv6 SIDs) [RFC8402] [RFC8986]
o TE Link Attributes (such as TE metric, Shared Risk Link Groups,
attribute-flag, extended admin group) [RFC5305] [RFC3630]
[RFC5329].
Filsfils, et al. Expires September 23, 2022 [Page 12]
Internet-Draft SR Policy Architecture March 2022
o Extended TE Link attributes (such as latency, loss) [RFC8570]
[RFC7471]
o Inter-AS Topology information [RFC9086].
The attached domain topology may be learned via protocol/mechanisms
such as IGP, BGP-LS or NETCONF.
A non-attached (remote) domain topology may be learned via protocol/
mechanisms such as BGP-LS or NETCONF.
In some use-cases, the SR-DB may only contain the attached domain
topology while in others, the SR-DB may contain the topology of
multiple domains and in this case, it is multi-domain capable.
The SR-DB may also contain the SR Policies instantiated in the
network. This can be collected via BGP-LS
[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231],
[I-D.ietf-pce-segment-routing-policy-cp], and
[I-D.ietf-pce-binding-label-sid]. This information allows to build
an end-to-end policy on the basis of intermediate SR policies (see
Section 6 for further details).
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],
OSPF [RFC8476], BGP-LS [RFC8814] or PCEP [RFC8664].
The use of the SR-DB for path computation and for the validation of
optimization objective and constraints of paths is outside the scope
of this document. Some implementation aspects related to path
computation are covered in
[I-D.filsfils-spring-sr-policy-considerations].
4. Segment Types
A Segment-List is an ordered set of segments represented as <S1, S2,
... Sn> where S1 is the first segment.
Based on the desired dataplane, either the MPLS label stack or the
SRv6 Segment Routing Header [RFC8754] is built from the Segment-List.
However, the Segment-List itself can be specified using different
segment-descriptor types and the following are currently defined:
Type A: SR-MPLS Label:
An MPLS label corresponding to any of the segment types defined
for SR-MPLS (as defined in [RFC8402] or other SR-MPLS
specifications) can be used. Additionally, special purpose
labels like explicit-null or in general any MPLS label MAY also
be used. E.g. this type can be used to specify a label
Filsfils, et al. Expires September 23, 2022 [Page 13]
Internet-Draft SR Policy Architecture March 2022
representation that maps to an optical transport path on a
packet transport node.
Type B: SRv6 SID:
An IPv6 address corresponding to any of the SID behaviors for
SRv6 (as defined in [RFC8986] or other SRv6 specifications) can
be used. Optionally, the SRv6 SID behavior (as defined in
[RFC8986] or other SRv6 specifications) and structure (as
defined in [RFC8986]) MAY also be provided for the headend to
perform validation of the SID when using it for building the
Segment List.
Type C: IPv4 Prefix with optional SR Algorithm:
In this case, the headend is required to resolve the specified
IPv4 Prefix Address to the SR-MPLS label corresponding to its
Prefix SID segment (as defined in [RFC8402]). The SR algorithm
(refer to Section 3.1.1 of [RFC8402]) to be used MAY also be
provided.
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
In this case, the headend is required to resolve the specified
IPv6 Global Prefix Address to the SR-MPLS label corresponding
to its Prefix SID segment (as defined in [RFC8402]). The SR
Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY
also be provided.
Type E: IPv4 Prefix with Local Interface ID:
This type allows identification of Adjacency SID or BGP Peer
Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
point-to-point links including IP unnumbered links. The
headend is required to resolve the specified IPv4 Prefix
Address to the Node originating it and then use the Local
Interface ID to identify the point-to-point link whose
adjacency is being referred to. The Local Interface ID link
descriptor follows semantics as specified in [RFC5307]. This
type can also be used to indicate indirection into a layer 2
interface (i.e., without IP address) like a representation of
an optical transport path or a layer 2 Ethernet port or circuit
at the specified node.
Type F: IPv4 Addresses for link endpoints as Local, Remote pair:
This type allows identification of Adjacency SID or BGP Peer
Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
links. The headend is required to resolve the specified IPv4
Local Address to the Node originating it and then use the IPv4
Remote Address to identify the link adjacency being referred
to. The Local and Remote Address pair link descriptors follow
semantics as specified in [RFC7752].
Filsfils, et al. Expires September 23, 2022 [Page 14]
Internet-Draft SR Policy Architecture March 2022
Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS:
This type allows identification of Adjacency SID or BGP Peer
Adjacency SID (as defined in [RFC8402]) label for links
including those with only Link-Local IPv6 addresses. The
headend is required to resolve the specified IPv6 Prefix
Address to the Node originating it and then use the Local
Interface ID to identify the point-to-point link whose
adjacency is being referred to. For other than point-to-point
links, additionally the specific adjacency over the link needs
to be resolved using the Remote Prefix and Interface ID. The
Local and Remote pair of Prefix and Interface ID link
descriptor follows semantics as specified in [RFC7752]. This
type can also be used to indicate indirection into a layer 2
interface (i.e., without IP address) like a representation of
an optical transport path or a layer 2 Ethernet port or circuit
at the specified node.
Type H: IPv6 Addresses for link endpoints as Local, Remote pair for
SR-MPLS:
This type allows identification of Adjacency SID or BGP Peer
Adjacency SID (as defined in [RFC8402]) label for links with
Global IPv6 addresses. The headend is required to resolve the
specified Local IPv6 Address to the Node originating it and
then use the Remote IPv6 Address to identify the link adjacency
being referred to. The Local and Remote Address pair link
descriptors follow semantics as specified in [RFC7752].
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6:
The headend is required to resolve the specified IPv6 Global
Prefix Address to an SRv6 SID corresponding to a Prefix SID
segment (as defined in [RFC8402]), such as a SID associated
with the End behavior (as defined in [RFC8986]) of the node
which is originating the prefix. The SR Algorithm (refer to
Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as defined
in [RFC8986] or other SRv6 specifications) and structure (as
defined in [RFC8986]) MAY also be provided.
Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6:
This type allows identification of an SRv6 SID corresponding to
an Adjacency SID or BGP Peer Adjacency SID (as defined in
[RFC8402]), such as a SID associated with the End.X behavior
(as defined in [RFC8986]) associated with link or adjacency
with only Link-Local IPv6 addresses. The headend is required
to resolve the specified IPv6 Prefix Address to the Node
originating it and then use the Local Interface ID to identify
the point-to-point link whose adjacency is being referred to.
Filsfils, et al. Expires September 23, 2022 [Page 15]
Internet-Draft SR Policy Architecture March 2022
For other than point-to-point links, additionally the specific
adjacency needs to be resolved using the Remote Prefix and
Interface ID. The Local and Remote pair of Prefix and
Interface ID link descriptor follows semantics as specified in
[RFC7752]. The SR Algorithm (refer to Section 3.1.1 of
[RFC8402]), the SRv6 SID behavior (as defined in [RFC8986] or
other SRv6 specifications) and structure (as defined in
[RFC8986]) MAY also be provided.
Type K: IPv6 Addresses for link endpoints as Local, Remote pair for
SRv6:
This type allows identification of an SRv6 SID corresponding to
an Adjacency SID or BGP Peer Adjacency SID (as defined in
[RFC8402]), such as a SID associated with the End.X behavior
(as defined in [RFC8986]) associated with link or adjacency
with Global IPv6 addresses. The headend is required to resolve
the specified Local IPv6 Address to the Node originating it and
then use the Remote IPv6 Address to identify the link adjacency
being referred to. The Local and Remote Address pair link
descriptors follow semantics as specified in [RFC7752]. The SR
Algorithm (refer to Section 3.1.1 of [RFC8402]), the SRv6 SID
behavior (as defined in [RFC8986] or other SRv6 specifications)
and structure (as defined in [RFC8986]) MAY also be provided.
When the algorithm is not specified for the SID types above which
optionally allow for it, the headend SHOULD use the Strict Shortest
Path algorithm if available and otherwise, it SHOULD use the default
Shortest Path algorithm. The specification of the algorithm enables
the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific
SIDs in SR Policy.
For SID types C-through-K, a SID value MAY also be optionally
provided to the headend for verification purposes. Section 5.1.
describes the resolution and verification of the SIDs and Segment
Lists on the headend.
When building the MPLS label stack or the IPv6 Segment list from the
Segment List, the node instantiating the policy MUST interpret the
set of Segments as follows:
o The first Segment represents the topmost label or the first IPv6
segment. It identifies the active segment the traffic will be
directed toward along the explicit SR path.
o The last Segment represents the bottommost label or the last IPv6
segment the traffic will be directed toward along the explicit SR
path.
Filsfils, et al. Expires September 23, 2022 [Page 16]
Internet-Draft SR Policy Architecture March 2022
4.1. Explicit Null
A Type A SID MAY be any MPLS label, including special purpose labels.
For example, assuming that the desired traffic-engineered path from a
headend 1 to an endpoint 4 can be expressed by the Segment-List
<16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer
to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic
can be traffic-engineered from nodes 1 to 4 via the previously
described path using an SR Policy with Segment-List <16002, 16003,
16004, 2> where the MPLS label value of 2 represents the "IPv6
Explicit NULL Label".
The penultimate node before node 4 will pop 16004 and will forward
the frame on its directly connected interface to node 4.
The endpoint receives the traffic with the top label "2" which
indicates that the payload is an IPv6 packet.
When steering unlabeled IPv6 BGP destination traffic using an SR
policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit
Null Label Policy is processed as specified in
[I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.5. When an
"IPv6 Explicit NULL label" is not present as the bottom label, the
headend SHOULD automatically impose one. Refer to Section 8 for more
details.
5. Validity of a Candidate Path
5.1. Explicit Candidate Path
An explicit candidate path is associated with a Segment-List or a set
of Segment-Lists.
An explicit candidate path is provisioned by the operator directly or
via a controller.
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
compute the Segment-List. The SR Policy headend only confirms its
validity.
An explicit candidate path MAY consist of a single explicit Segment-
List containing only an implicit-null label to indicate pop-and-
forward behavior. The Binding SID (BSID) is popped and the traffic
is forwarded based on the inner label or an IP lookup in the case of
unlabeled IP packets. Such an explicit path can serve as a fallback
Filsfils, et al. Expires September 23, 2022 [Page 17]
Internet-Draft SR Policy Architecture March 2022
or path of last resort for traffic being steered into an SR Policy
using its BSID (refer to Section 8.3).
A Segment-List of an explicit candidate path MUST be declared invalid
when any of the following is true:
o It is empty.
o Its weight is 0.
o It comprises a mix of SR-MPLS and SRv6 segment types.
o The headend is unable to perform path resolution for the first SID
into one or more outgoing interface(s) and next-hop(s).
o 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.
o The headend verification fails for any SID for which verification
has been explicitly requested.
"Unable to perform path resolution" means that the headend has no
path to the SID in its SR database.
SID verification is performed when the headend is explicitly
requested to verify SID(s) by the controller via the signaling
protocol used. Implementations MAY provide a local configuration
option to enable verification on a global or per policy or per
candidate path basis.
"Verification fails" for a SID means any of the following:
o The headend is unable to find the SID in its SR-DB
o The headend detects a mismatch between the SID value provided and
the SID value resolved by context provided for SIDs of type
C-through-K in its SR-DB.
o 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.
In multi-domain deployments, it is expected that the headend may be
unable to verify the reachability of the SIDs in remote domains.
Types A or B MUST be used for the SIDs for which the reachability
cannot be verified. Note that the first SID MUST always be reachable
regardless of its type.
Additionally, a Segment-List MAY be declared invalid when both of the
conditions below are met :
o Its last segment is not a Prefix SID (including BGP Peer Node-SID)
advertised by the node specified as the endpoint of the
corresponding SR policy.
o Its last segment is not an Adjacency SID (including BGP Peer
Adjacency SID) of any of the links present on neighbor nodes and
Filsfils, et al. Expires September 23, 2022 [Page 18]
Internet-Draft SR Policy Architecture March 2022
that terminate on the node specified as the endpoint of the
corresponding SR policy.
An explicit candidate path is invalid as soon as it has no valid
Segment-List.
Additionally, an explicit candidate path MAY be declared invalid when
its constituent segment lists (valid or invalid) are using segment
types of different SR data planes.
5.2. Dynamic Candidate Path
A dynamic candidate path is specified as an optimization objective
and constraints.
The headend of the policy leverages its SR database to compute a
Segment-List ("solution Segment-List") that solves this optimization
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
to the problem change (e.g., topology changes).
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
headend may rely on an external entity. For example, a path
computation request may be sent to a PCE supporting PCEP extensions
specified in [RFC8664].
If no solution is found to the optimization objective and
constraints, then the dynamic candidate path MUST be declared
invalid.
Section 3 of [I-D.filsfils-spring-sr-policy-considerations] discusses
some of the optimization objectives and constraints that may be
considered by a dynamic candidate path. It illustrates some of the
desirable properties of the computation of the solution Segment-List.
5.3. Composite Candidate Path
A composite candidate path is specified as a group of its constituent
SR Policies.
A composite candidate path is valid when it has at least one valid
constituent SR Policy.
Filsfils, et al. Expires September 23, 2022 [Page 19]
Internet-Draft SR Policy Architecture March 2022
6. Binding SID
The Binding SID (BSID) is fundamental to Segment Routing [RFC8402].
It provides scaling, network opacity, and service independence.
Section 6 of [I-D.filsfils-spring-sr-policy-considerations]
illustrates some of these benefits. This section describes the
association of BSID with an SR Policy.
6.1. BSID of a candidate path
Each candidate path MAY be defined with a 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.
6.2. BSID of an SR Policy
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
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 used
by some other MPLS forwarding entry, SRv6 SID used in some other
context, to another SID, to another SR Policy, outside the range of
SRv6 Locators).
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
MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g. with
different behaviors like End.B6.Encap and End.B6.Encap.Red [RFC8986])
MAY be associated with the SR Policy.
Optionally, instead of only checking that the BSID of the active path
is available, a headend MAY check that it is available within the
given SID range i.e., Segment Routing Local Block (SRLB) as specified
in [RFC8402].
When the specified BSID is not available (optionally is not in the
SRLB), an alert message MUST be generated via mechanisms like syslog.
In the cases (as described above) where SR Policy does not have a
BSID available, then the SR Policy MAY dynamically bind a BSID to
itself. Dynamically bound BSID SHOULD use an available SID outside
the SRLB.
Assuming that at time t the BSID of the SR Policy is B1, if at time
t+dt a different candidate path becomes active and this new active
Filsfils, et al. Expires September 23, 2022 [Page 20]
Internet-Draft SR Policy Architecture March 2022
path does not have a specified BSID or its BSID is specified but is
not available (e.g. it is in use by something else), then the SR
Policy MAY keep the previous BSID B1.
The association of an SR Policy with a BSID thus MAY change over the
life of the SR Policy (e.g., upon active path change). Hence, the
BSID SHOULD NOT be used as an identification of an SR Policy.
6.2.1. Frequent use-case : unspecified BSID
All the candidate paths of the same SR Policy can have an unspecified
BSID.
In such a case, a BSID MAY be dynamically bound to the SR Policy as
soon as the first valid candidate path is received. That BSID is
kept through the life of the SR Policy and across changes of active
candidate path.
6.2.2. Frequent use-case: all specified to the same BSID
All the paths of the SR Policy can have the same specified BSID.
6.2.3. Specified-BSID-only
An implementation MAY support the configuration of the Specified-
BSID-only restrictive behavior on the headend for all SR Policies or
individual SR Policies. Further, this restrictive behavior MAY also
be signaled on a per SR Policy basis to the headend.
When this restrictive behavior is enabled, if the candidate path has
an unspecified BSID or if the specified BSID is not available when
the candidate path becomes active then no BSID is bound to it and the
candidate path is considered invalid. An alert MUST be triggered for
this error via mechanisms like syslog. Other candidate paths MUST
then be evaluated for becoming the active candidate path.
6.3. Forwarding Plane
A valid SR Policy results in the installation of a BSID-keyed entry
in the forwarding plane with the action of steering the packets
matching this entry to the selected path of the SR Policy.
If the Specified-BSID-only restrictive behavior is enabled and 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
BSID in the forwarding plane.
Filsfils, et al. Expires September 23, 2022 [Page 21]
Internet-Draft SR Policy Architecture March 2022
6.4. Non-SR usage of Binding SID
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
tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
tunnel, etc). This enables the use of other non-SR enabled
interfaces and tunnels as segments in an SR Policy Segment-List
without the need of forming routing protocol adjacencies over them.
The details of this kind of usage are beyond the scope of this
document. A specific packet-optical integration use case is
described in [I-D.anand-spring-poi-sr].
7. SR Policy State
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
accurate representation of whether the SR Policy is being
instantiated in the forwarding plane and which of its candidate paths
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
active due to validation errors or not being preferred. The
operational state information reported for SR Policies are specified
in [I-D.ietf-spring-sr-policy-yang].
The SR Policy state can be reported by the headend node via BGP-LS
[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
[I-D.ietf-pce-binding-label-sid].
SR Policy state on the headend also includes traffic accounting
information for the flows being steered via the policies. The
details of the SR Policy accounting are beyond the scope of this
document. The aspects related to the SR traffic counters and their
usage in the broader context of traffic accounting in an SR network
are covered in [I-D.filsfils-spring-sr-traffic-counters] and
[I-D.ali-spring-sr-traffic-accounting] respectively.
Implementations MAY support an administrative state to control
locally provisioned policies via mechanisms like CLI or NETCONF.
8. Steering into an SR Policy
A headend can steer a packet flow into a valid SR Policy in various
ways:
o Incoming packets have an active SID matching a local BSID at the
headend.
Filsfils, et al. Expires September 23, 2022 [Page 22]
Internet-Draft SR Policy Architecture March 2022
o Per-destination Steering: incoming packets match a BGP/Service
route which recurses on an SR policy.
o Per-flow Steering: incoming packets match or recurse on a
forwarding array of which some of the entries are SR Policies.
o Policy-based Steering: incoming packets match a routing policy
that directs them on an SR policy.
8.1. Validity of an SR Policy
An SR Policy is invalid when all its candidate paths are invalid as
described in Section 5 and Section 2.10.
By default, upon transitioning to the invalid state,
o an SR Policy and its BSID are removed from the forwarding plane.
o any steering of a service (Pseudowire (PW)), destination (BGP-
VPN), flow or packet on the related SR policy is disabled and the
related service, destination, flow, or packet is routed per the
classic forwarding table (e.g. longest-match to the destination or
the recursing next-hop).
8.2. Drop upon invalid SR Policy
An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior:
o an invalid SR Policy and its BSID is kept in the forwarding plane
with an action to drop.
o any steering of a service (PW), destination (BGP-VPN), flow or
packet on the related SR policy is maintained with the action to
drop all of this traffic.
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
specific constraints. When these constraints are no longer met, the
operator wants the PW traffic to be dropped. Specifically, the
operator does not want the PW to be routed according to the IGP
shortest path to the PW endpoint.
8.3. Incoming Active SID is a BSID
Let us assume that headend H has a valid SR Policy P of Segment-List
<S1, S2, S3> and BSID B.
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
resulting packet according to SID S1.
Filsfils, et al. Expires September 23, 2022 [Page 23]
Internet-Draft SR Policy Architecture March 2022
"Forwarding the resulting packet according to S1" means: If S1 is
an Adj-SID or a PHP-enabled prefix SID advertised by a neighbor, H
sends the resulting packet with label stack <S2, S3, L2, L3> on
the outgoing interface associated with S1; Else H sends the
resulting packet with label stack <S1, S2, S3, L2, L3> along the
path of S1.
In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of [RFC8986].
H has steered the packet into the SR policy P.
H did not have to classify the packet. The classification was done
by a node upstream of H (e.g., the source of the packet or an
intermediate ingress edge node of the SR domain) and the result of
this classification was efficiently encoded in the packet header as a
BSID.
This is another key benefit of the segment routing in general and the
binding SID in particular: the ability to encode a classification and
the resulting steering in the packet header to better scale and
simplify intermediate aggregation nodes.
When Drop-Upon-Invalid (refer Section 8.2) is not in use, for an
invalid SR Policy P, its BSID B is not in the forwarding plane and
hence the packet K is dropped by H.
8.4. Per-Destination Steering
This section describes how a headend applies steering of flows
corresponding to BGP routes over SR Policy using the Color Extended
community [RFC9012].
In the case of SR-MPLS, let us assume that headend H:
o learns a BGP route R/r via next-hop N, Color Extended community C
and VPN label V.
o has a valid SR Policy P to (color = C, endpoint = N) of Segment-
List <S1, S2, S3> and BSID B.
o has a BGP policy that matches on the Color Extended community C
and allows its usage as SLA steering information.
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.
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
Filsfils, et al. Expires September 23, 2022 [Page 24]
Internet-Draft SR Policy Architecture March 2022
with the SLA associated with color C. The headend, therefore,
installs the BGP route on that policy.
This can be implemented by using the BSID as a 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
the label stack <S1, S2, S3, V> and sends the resulting packet along
the path to S1.
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>).
In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of [RFC8986].
The same behavior applies to any type of service route: any AFI/SAFI
of BGP [RFC4760] or LISP [RFC6830] for both IPv4/IPv6.
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
others resolved via the normal BGP nexthop resolution.
Implementations MAY provide options to prefer one type over the other
or other forms of local policy to determine the paths that are
selected.
8.4.1. Multiple Colors
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
giving preference to the Color Extended community with the highest
numerical value.
Let us assume that headend H:
o learns a BGP route R/r via next-hop N, Color Extended communities
C1 and C2.
o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment-
List <S1, S2, S3> and BSID B1.
o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment-
List <S4, S5, S6> and BSID B2.
o has a BGP policy that matches the Color Extended communities C1
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-
hop = SR Policy P2 of BSID=B2 (instead of N) because C2 > C1.
Filsfils, et al. Expires September 23, 2022 [Page 25]
Internet-Draft SR Policy Architecture March 2022
When the SR Policy with a specific color is not instantiated or in
the down/inactive state, the SR Policy with the next highest
numerical value of color is considered.
8.5. Recursion on an on-demand dynamic BSID
In the previous section, it was assumed that H had a pre-established
"explicit" SR Policy (color C, endpoint N).
In this section, independent of the a-priori existence of any
explicit candidate path of the SR policy (C, N), it is to be noted
that the BGP process at headend node H triggers the instantiation of
a dynamic candidate path for the SR policy (C, N) as soon as:
o the BGP process learns of a route R/r via N and with Color
Extended community C.
o a local policy at node H authorizes the on-demand SR Policy path
instantiation and maps the color to a dynamic SR Policy path
optimization template.
8.5.1. Multiple Colors
When a BGP route R/r via N has multiple Color Extended communities Ci
(with i=1 ... n), an individual on-demand SR Policy dynamic path
request (color Ci, endpoint N) is triggered for each color Ci. The
SR Policy that is used for steering is then determined as described
in Section 8.4.1.
8.6. Per-Flow Steering
This section provides an example of how a headend might apply per-
flow steering in practice.
Let us assume that headend H:
o has a valid SR Policy P1 to (color = C1, endpoint = N) of Segment-
List <S1, S2, S3> and BSID B1.
o has a valid SR Policy P2 to (color = C2, endpoint = N) of Segment-
List <S4, S5, S6> and BSID B2.
o is configured to instantiate an array of paths to N where the
entry 0 is the IGP path to N, color C1 is the first entry and
color C2 is the second entry. The index into the array is called
a Forwarding Class (FC). The index can have values 0 to 7,
especially when derived from the MPLS TC bits [RFC5462].
o is configured to match flows in its ingress interfaces (upon any
field such as Ethernet destination/source/VLAN/TOS or IP
destination/source/DSCP or transport ports etc.) and color them
Filsfils, et al. Expires September 23, 2022 [Page 26]
Internet-Draft SR Policy Architecture March 2022
with an internal per-packet forwarding-class variable (0, 1 or 2
in this example).
If all these conditions are met, H installs in RIB/FIB:
o N via recursion on an array A (instead of the immediate outgoing
link associated with the IGP shortest-path to N).
o Entry A(0) set to the immediate outgoing link of the IGP shortest-
path to N.
o Entry A(1) set to SR Policy P1 of BSID=B1.
o Entry A(2) set to SR Policy P2 of BSID=B2.
H receives three packets K, K1, and K2 on its incoming interface.
These three packets either longest-match on N or more likely on a
BGP/service route which recurses on N. H colors these 3 packets
respectively with forwarding-class 0, 1, and 2.
As a result, for SR-MPLS:
o H forwards K along the shortest path to N (i.e., pushes the
Prefix-SID of N).
o H pushes <S1, S2, S3> on packet K1 and forwards the resulting
frame along the shortest path to S1.
o H pushes <S4, S5, S6> on packet K2 and forwards the resulting
frame along the shortest path to S4.
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
using the SR Policy headend behaviors as specified in section 5 of
[RFC8986].
If the local configuration does not specify any explicit forwarding
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).
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
all the array entries have the same information as entry0, the
forwarding entry for N is updated to bypass the array and point
directly to its outgoing interface and next-hop.
The array index values (e.g. 0, 1, and 2) and the notion of
forwarding-class are implementation-specific and only meant to
describe the desired behavior. The same can be realized by other
mechanisms.
This realizes per-flow steering: different flows bound to the same
BGP endpoint are steered on different IGP or SR Policy paths.
Filsfils, et al. Expires September 23, 2022 [Page 27]
Internet-Draft SR Policy Architecture March 2022
A headend MAY support options to apply per-flow steering only for
traffic matching specific prefixes (e.g. specific IGP or BGP
prefixes).
8.7. Policy-based Routing
Finally, headend H MAY be configured with a local routing policy
which overrides any BGP/IGP path and steers a specified packet on an
SR Policy. This includes the use of mechanisms like IGP Shortcut for
automatic routing of IGP prefixes over SR Policies intended for such
purpose.
8.8. Optional Steering Modes for BGP Destinations
8.8.1. Color-Only BGP Destination Steering
In the previous section, it is seen that the steering on an SR Policy
is governed by the matching of the BGP route's next-hop N and the
authorized Color Extended community C with an SR Policy defined by
the tuple (N, C).
This is the most likely form of BGP destination steering and the one
recommended for most use-cases.
This section defines an alternative steering mechanism based only on
the Color Extended community.
Three types of steering modes are defined.
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
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE;
Steer on the IGP path to the next-hop N.
This is the classic case described in this document previously and
what is recommended in most scenarios.
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
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C) of the
Filsfils, et al. Expires September 23, 2022 [Page 28]
Internet-Draft SR Policy Architecture March 2022
same address-family of N;
Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C);
ELSE;
Steer on the IGP path to the next-hop N.
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
endpoint address and C is a color;
Steer into SR Policy (N, C);
ELSE IF there is a valid SR Policy (null endpoint, C)
of the same address-family of N;
Steer into SR Policy (null endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family null endpoint, C);
Steer into SR Policy (any null endpoint, C);
ELSE IF there is any valid SR Policy (any endpoint, C)
of the same address-family of N;
Steer into SR Policy (any endpoint, C);
ELSE IF there is any valid SR Policy
(any address-family endpoint, C);
Steer into SR Policy (any address-family endpoint, C);
ELSE;
Steer on the IGP path to the next-hop N.
The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set
to the 0 value).
Please refer to [I-D.ietf-idr-segment-routing-te-policy] for the
updates to the BGP Color Extended community for the implementation of
these mechanisms.
8.8.2. Multiple Colors and CO flags
The steering preference is first based on the highest Color Extended
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
preference order is:
o SR policy (NH, C1).
o SR policy (null, C1).
o SR policy (NH, C2).
o SR policy (null, C2).
o IGP to NH.
Filsfils, et al. Expires September 23, 2022 [Page 29]
Internet-Draft SR Policy Architecture March 2022
8.8.3. Drop upon Invalid
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
BSID B instead of via N.
o H learns a BGP route R/r via next-hop N, Color Extended community
C.
o H has a valid SR Policy P to (color = C, endpoint = N) of Segment-
List <S1, S2, S3> and BSID B.
o H has a BGP policy that matches the Color Extended community C and
allows its usage as SLA steering information.
This behavior is extended by noting that the BGP policy may require
the BGP steering to always stay on the SR policy whatever its
validity.
This is the "drop upon invalid" option described in Section 8.2
applied to BGP-based steering.
9. Recovering from Network Failures
9.1. Leveraging TI-LFA local protection of the constituent IGP segments
In any topology, Topology-Independent Loop-Free Alternate (TI-LFA)
[I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local
protection technique for IGP SIDs. The backup path is computed on a
per IGP SID basis along the post-convergence path.
In a network that has deployed TI-LFA, an SR Policy built on the
basis of TI-LFA protected IGP segments leverages the local protection
of the constituent segments. Since TI-LFA protection is based on IGP
computation, there are cases where the path used during the fast-
reroute time window may not meet the exact constraints of the SR
Policy.
In a network that has deployed TI-LFA, an SR Policy instantiated only
with non-protected Adj SIDs does not benefit from any local
protection.
9.2. Using an SR Policy to locally protect a link
Filsfils, et al. Expires September 23, 2022 [Page 30]
Internet-Draft SR Policy Architecture March 2022
1----2-----6----7
| | | |
4----3-----9----8
Figure 1: Local protection using SR Policy
An SR Policy can be instantiated at node 2 to protect link 2to6. A
typical explicit Segment-List would be <3, 9, 6>.
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
part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9
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
a fast-reroute backup path for the link 2to6.
9.3. Using a Candidate Path for Path Protection
An SR Policy allows for multiple candidate paths, of which at any
point in time there is a single active candidate path that is
provisioned in the forwarding plane and used for traffic steering.
However, another (lower preference) candidate path MAY be designated
as the backup for a specific or all (active) candidate path(s). The
following options are possible:
o A pair of disjoint candidate paths are provisioned with one of
them as primary and the other is identified as its backup.
o A specific candidate path is provisioned as the backup for any
(active) candidate path.
o The headend picks the next (lower) preference valid candidate path
as the backup for the active candidate path.
The headend MAY compute a-priori and validate such backup candidate
paths as well as provision them into the forwarding plane as a backup
for the active path. The backup candidate path may be dynamically
computed or explicitly provisioned in such a way that they provide
the most appropriate alternative for the active candidate path. A
fast re-route mechanism MAY then be used to trigger sub 50msec
switchover from the active to the backup candidate path in the
forwarding plane. Mechanisms like Bidirectional Forwarding Detection
(BFD) MAY be used for fast detection of such failures.
10. Security Considerations
This document specifies in detail the SR Policy construct introduced
in [RFC8402] and its instantiation on a router supporting SR along
with descriptions of mechanisms for steering of traffic flows over
Filsfils, et al. Expires September 23, 2022 [Page 31]
Internet-Draft SR Policy Architecture March 2022
it. Therefore, the security considerations of [RFC8402] apply. The
security consideration related to SR-MPLS [RFC8660] and SRv6
[RFC8754] [RFC8986] also apply.
The endpoint of the SR Policy, other than in the case of a null
endpoint, uniquely identifies the tail-end node of the segment routed
path. If an address that is used as an endpoint for an SR Policy is
advertised by more than one node due to a misconfiguration or
spoofing and the same is advertised via an IGP, the traffic steered
over the SR Policy may end up getting diverted to an undesired node
resulting is misrouting. Mechanisms for detection of duplicate
prefix advertisement can be used to identify and correct such
scenarios. The details of these mechanisms are outside the scope of
this document.
The Section 8 specifies mechanism for steering of traffic flows
corresponding to BGP routes over SR Policies matching the color value
signaled via the BGP Color Extended Community attached with the BGP
routes. Misconfiguration or error in setting of the Color Extended
Community with the BGP routes can result in forwarding of packets for
those routes along undesired paths.
In Section 2.1 and Section 2.6, the document mentions that a symbolic
name MAY be signaled along with a candidate path for the SR Policy
and for the SR Policy Candidate Path respectively. While the value
of symbolic names for display clarity is indisputable, as with any
unrestricted freeform text received from external parties, there can
be no absolute assurance that the information the text purports to
show is accurate or even truthful. For this reason, users of
implementations that display such information would be well-advised
not to rely on it without question and to use the specific
identifiers of the SR Policy and SR Policy Candidate Path for
validation. Furthermore, implementations that display such
information might wish to display it in such a fashion as to
differentiate it from known-good information. (Such display
conventions are inherently implementation-specific; one example might
be use of a distinguished text color or style for information that
should be treated with caution.)
This document does not define any new protocol extensions and does
not introduce any further security considerations.
11. Manageability Considerations
This document specifies in detail the SR Policy construct introduced
in [RFC8402] and its instantiation on a router supporting SR along
with descriptions of mechanisms for steering of traffic flows over
it. Therefore, the manageability considerations of [RFC8402] apply.
Filsfils, et al. Expires September 23, 2022 [Page 32]
Internet-Draft SR Policy Architecture March 2022
A YANG model for the configuration and operation of SR Policy has
been defined in [I-D.ietf-spring-sr-policy-yang].
12. IANA Considerations
The document requests IANA to create a new sub-registry called
"Segment Types" under the top-level "Segment Routing" registry that
was created by [RFC8986]. This sub-registry maintains the alphabetic
identifiers for the 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 and may be extended on exhaustion with
the identifiers AA to AZ, BA to BZ, and so on through till ZZ. This
sub-registry would follow the Specification Required allocation
policy as specified in [RFC8126].
The initial registrations for this sub-registry are as follows:
+-------+-----------------------------------------------+-----------+
| Value | Description | Reference |
+-------+-----------------------------------------------+-----------+
| A | SR-MPLS Label | [This.ID] |
| B | SRv6 SID | [This.ID] |
| C | IPv4 Prefix with optional SR Algorithm | [This.ID] |
| D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] |
| | for SR-MPLS | |
| E | IPv4 Prefix with Local Interface ID | [This.ID] |
| F | IPv4 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair | |
| G | IPv6 Prefix and Interface ID for link | [This.ID] |
| | endpoints as Local, Remote pair for SR-MPLS | |
| H | IPv6 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair for SR-MPLS | |
| I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] |
| | for SRv6 | |
| J | IPv6 Prefix and Interface ID for link | [This.ID] |
| | endpoints as Local, Remote pair for SRv6 | |
| K | IPv6 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair for SRv6 | |
+-------+-----------------------------------------------+-----------+
Table 2: Initial IANA Registration
12.1. Guidance for Designated Experts
The Designated Expert (DE) is expected to ascertain the existence of
suitable documentation (a specification) as described in [RFC8126]
and to verify that the document is permanently and publicly
available. The DE is also expected to check the clarity of purpose
Filsfils, et al. Expires September 23, 2022 [Page 33]
Internet-Draft SR Policy Architecture March 2022
and use of the requested assignment. Additionally, the DE must
verify that any request for one of these assignments has been made
available for review and comment within the IETF: the DE will post
the request to the SPRING Working Group mailing list (or a successor
mailing list designated by the IESG). If the request comes from
within the IETF, it should be documented in an Internet-Draft.
Lastly, the DE must ensure that any other request for a code point
does not conflict with work that is active or already published
within the IETF.
13. Acknowledgement
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha,
Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi,
Matthew Bocci, Cullen Jennings, and Carlos Bernardos for their review
comments and suggestions.
14. Contributors
The following people have contributed to this document:
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Jose Liste
Cisco Systems
Email: jliste@cisco.com
Francois Clad
Cisco Systems
Email: fclad@cisco.com
Kamran Raza
Cisco Systems
Email: skraza@cisco.com
Mike Koldychev
Cisco Systems
Email: mkoldych@cisco.com
Filsfils, et al. Expires September 23, 2022 [Page 34]
Internet-Draft SR Policy Architecture March 2022
Shraddha Hegde
Juniper Networks
Email: shraddha@juniper.net
Steven Lin
Google, Inc.
Email: stevenlin@google.com
Przemyslaw Krol
Google, Inc.
Email: pkrol@google.com
Martin Horneffer
Deutsche Telekom
Email: martin.horneffer@telekom.de
Dirk Steinberg
Steinberg Consulting
Email: dws@steinbergnet.net
Bruno Decraene
Orange Business Services
Email: bruno.decraene@orange.com
Stephane Litkowski
Orange Business Services
Email: stephane.litkowski@orange.com
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
Filsfils, et al. Expires September 23, 2022 [Page 35]
Internet-Draft SR Policy Architecture March 2022
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
15.2. Informative References
[I-D.ali-spring-sr-traffic-accounting]
Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S.,
Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D., and
R. Morton, "Traffic Accounting in Segment Routing
Networks", draft-ali-spring-sr-traffic-accounting-06 (work
in progress), November 2021.
Filsfils, et al. Expires September 23, 2022 [Page 36]
Internet-Draft SR Policy Architecture March 2022
[I-D.anand-spring-poi-sr]
Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J.,
Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical
Integration in Segment Routing", draft-anand-spring-poi-
sr-08 (work in progress), July 2019.
[I-D.filsfils-spring-sr-policy-considerations]
Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and
P. Mattes, "SR Policy Implementation and Deployment
Considerations", draft-filsfils-spring-sr-policy-
considerations-08 (work in progress), October 2021.
[I-D.filsfils-spring-sr-traffic-counters]
Filsfils, C., Ali, Z., Horneffer, M., Voyer, D., Durrani,
M., and R. Raszuk, "Segment Routing Traffic Accounting
Counters", draft-filsfils-spring-sr-traffic-counters-02
(work in progress), October 2021.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", draft-ietf-idr-segment-routing-te-
policy-16 (work in progress), March 2022.
[I-D.ietf-idr-te-lsp-distribution]
Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler,
H., and J. Tantsura, "Distribution of Traffic Engineering
(TE) Policies and State using BGP-LS", draft-ietf-idr-te-
lsp-distribution-16 (work in progress), October 2021.
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-18 (work in progress), October 2021.
[I-D.ietf-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. L. (editor), "Carrying Binding Label/Segment
Identifier (SID) in PCE-based Networks.", draft-ietf-pce-
binding-label-sid-15 (work in progress), March 2022.
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", draft-ietf-pce-segment-routing-policy-
cp-06 (work in progress), October 2021.
Filsfils, et al. Expires September 23, 2022 [Page 37]
Internet-Draft SR Policy Architecture March 2022
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", draft-ietf-rtgwg-segment-
routing-ti-lfa-08 (work in progress), January 2022.
[I-D.ietf-spring-sr-policy-yang]
Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M.,
Matsushima, S., and V. P. Beeram, "YANG Data Model for
Segment Routing Policy", draft-ietf-spring-sr-policy-
yang-01 (work in progress), April 2021.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
Filsfils, et al. Expires September 23, 2022 [Page 38]
Internet-Draft SR Policy Architecture March 2022
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
Filsfils, et al. Expires September 23, 2022 [Page 39]
Internet-Draft SR Policy Architecture March 2022
[RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,
and N. Triantafillis, "Signaling Maximum SID Depth (MSD)
Using the Border Gateway Protocol - Link State", RFC 8814,
DOI 10.17487/RFC8814, August 2020,
<https://www.rfc-editor.org/info/rfc8814>.
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K.,
Ray, S., and J. Dong, "Border Gateway Protocol - Link
State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
2021, <https://www.rfc-editor.org/info/rfc9086>.
Authors' Addresses
Clarence Filsfils
Cisco Systems, Inc.
Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM
Email: cfilsfil@cisco.com
Ketan Talaulikar (editor)
Cisco Systems, Inc.
India
Email: ketant.ietf@gmail.com
Daniel Voyer
Bell Canada
671 de la gauchetiere W
Montreal, Quebec H3B 2M8
Canada
Email: daniel.voyer@bell.ca
Alex Bogdanov
British Telecom
Email: alex.bogdanov@bt.com
Filsfils, et al. Expires September 23, 2022 [Page 40]
Internet-Draft SR Policy Architecture March 2022
Paul Mattes
Microsoft
One Microsoft Way
Redmond, WA 98052-6399
USA
Email: pamattes@microsoft.com
Filsfils, et al. Expires September 23, 2022 [Page 41]
