Segment Routing Policy Architecture Cisco Systems, Inc.
Pegasus Parc De kleetlaan 6a Diegem 1831 Belgium cfilsfil@cisco.com
Cisco Systems, Inc.
India ketant.ietf@gmail.com
Bell Canada
671 de la gauchetiere W Montreal Quebec H3B 2M8 Canada daniel.voyer@bell.ca
British Telecom
alex.bogdanov@bt.com
Microsoft
One Microsoft Way Redmond WA 98052-6399 United States of America pamattes@microsoft.com
rtg spring Segment Routing SR Policy SR-MPLS SRv6 Traffic Engineering 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 an 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 RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
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 () 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
  • .  SR Policy
    • .  Identification of an SR Policy
    • .  Candidate Path and Segment List
    • .  Protocol-Origin of a Candidate Path
    • .  Originator of a Candidate Path
    • .  Discriminator of a Candidate Path
    • .  Identification of a Candidate Path
    • .  Preference of a Candidate Path
    • .  Validity of a Candidate Path
    • .  Active Candidate Path
    • . Validity of an SR Policy
    • . Instantiation of an SR Policy in the Forwarding Plane
    • . Priority of an SR Policy
    • . Summary
  • .  Segment Routing Database
  • .  Segment Types
    • .  Explicit Null
  • .  Validity of a Candidate Path
    • .  Explicit Candidate Path
    • .  Dynamic Candidate Path
    • .  Composite Candidate Path
  • .  Binding SID
    • .  BSID of a Candidate Path
    • .  BSID of an SR Policy
    • .  Forwarding Plane
    • .  Non-SR Usage of Binding SID
  • .  SR Policy State
  • .  Steering into an SR Policy
    • .  Validity of an SR Policy
    • .  Drop-upon-Invalid SR Policy
    • .  Incoming Active SID is a BSID
    • .  Per-Destination Steering
    • .  Recursion on an On-Demand Dynamic BSID
    • .  Per-Flow Steering
    • .  Policy-Based Routing
    • .  Optional Steering Modes for BGP Destinations
  • .  Recovering from Network Failures
    • .  Leveraging TI-LFA Local Protection of the Constituent IGP Segments
    • .  Using an SR Policy to Locally Protect a Link
    • .  Using a Candidate Path for Path Protection
  • . Security Considerations
  • . Manageability Considerations
  • . IANA Considerations
    • .  Guidance for Designated Experts
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgement
  • Contributors
  • Authors' Addresses
Introduction Segment Routing (SR) 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. It 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) 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 an SR Policy. The packets steered into an SR Policy have an ordered list of segments associated with that SR Policy written into them. describes the representation and processing of this ordered list of segments as an MPLS label stack for SR-MPLS, while and describe the same for Segment Routing over IPv6 (SRv6) with the use of the Segment Routing Header (SRH). introduces the SR Policy construct and provides an overview of how it is leveraged for Segment Routing use cases. This document updates 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.
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 when, and only when, they appear in all capitals, as shown here.
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 Service Level Agreement (SLA)) from that node. The Segment Routing architecture 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.
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 . 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 ), 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 ). An implementation MAY allow the assignment of a symbolic name comprising printable ASCII 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 ). 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.
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 the Path Computation Element Communication Protocol (PCEP) or BGP SR 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 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:
  • The endpoints of the constituent SR Policies and the parent SR Policy MUST be identical.
  • The colors of each of the constituent SR Policies and the parent SR Policy MUST be different.
  • 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 for details). The default weight is 1. illustrates an information model for hierarchical relationships between the SR Policy constructs described in this section.
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 , or BGP . 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 headend assigns different Protocol-Origin values to each source of SR Policy information. The Protocol-Origin value is used as a tiebreaker between candidate paths of equal Preference, as described in . The table below specifies the RECOMMENDED default values of Protocol-Origin: Protocol-Origin Default Values
Protocol-Origin Description
10 PCEP
20 BGP SR Policy
30 Via Configuration
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 routing administrative distance. Its application in the candidate path selection is described in .
Originator of a Candidate Path The Originator identifies the node that 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:
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 0.
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 0.
Its application in the candidate path selection is described in . 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 ) on the headend.
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:
  • When provisioning is via configuration, this is a unique identifier for a candidate path; it is specific to the implementation's configuration model. The default value is 0.
  • When signaling is via PCEP, the method to uniquely signal an individual candidate path along with its Discriminator is described in . The default value is 0.
  • When signaling is via BGP SR Policy, the BGP process receiving the route provides the distinguisher (refer to ) 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 .
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). 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 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 and , respectively.
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. 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 and , respectively.
Validity of a Candidate Path A candidate path is usable when it is valid. The RECOMMENDED candidate path validity criterion is the validity of at least one of its constituent segment lists. The validation rules are specified in .
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. The higher value of Protocol-Origin is selected.
  2. If specified by configuration, prefer the existing installed path.
  3. The lower value of the Originator is selected.
  4. Finally, the higher value of the 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:
  • The Preference, being the primary criterion, allows an operator to influence selection across paths thus allowing provisioning of multiple path options, e.g., CP1 is preferred as its Preference value is the highest, and if it becomes invalid, then CP2 with the next highest Preference value is selected, and so on. Since Preference works across protocol sources, it also enables (where necessary) selective override of the default Protocol-Origin preference, e.g., to prefer a path signaled via BGP SR Policy over what is configured.
  • The Protocol-Origin allows an operator to set up a default selection mechanism across protocol sources, e.g., to prefer configured paths over paths signaled via BGP SR Policy or PCEP.
  • 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.
  • The Discriminator performs the final tie-breaking step to ensure a deterministic outcome of selection regardless of the order in which candidate paths are signaled across multiple transport channels or sessions.
provides a set of examples to illustrate the active candidate path selection rules.
Validity of an SR Policy An SR Policy is valid when it has at least one valid candidate path.
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 . 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. 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.
Priority of an SR Policy Upon topological change, many policies could be re-computed 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.
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> 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 hashed on a per-flow basis 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.
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:
  • IGP information (topology, IGP metrics based on IS-IS and OSPF )
  • Segment Routing information (such as Segment Routing Global Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering SID, SRv6 SIDs)
  • TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group)
  • Extended TE Link attributes (such as latency, loss)
  • Inter-AS Topology information
The attached domain topology may be learned via protocol/mechanisms such as IGP, Border Gateway Protocol - Link State (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 or PCEP (along with and ). This information allows to build an end-to-end policy on the basis of intermediate SR policies (see 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 , OSPF , BGP-LS , or PCEP . 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 .
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 data plane, either the MPLS label stack or the SRv6 Segment Routing Header 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 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. For example, this type can be used to specify a label 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 or other SRv6 specifications) can be used. Optionally, the SRv6 SID behavior (as defined in or other SRv6 specifications) and structure (as defined in ) 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 ). The SR algorithm (refer to ) 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 ). The SR Algorithm (refer to ) to be used MAY also be provided.
Type E: IPv4 Prefix with Local Interface ID:
This type allows for identification of an Adjacency SID or BGP Peer Adjacency SID (as defined in ) 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 . 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 for identification of an Adjacency SID or BGP Peer Adjacency SID (as defined in ) 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 .
Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS:
This type allows for identification of an Adjacency SID or BGP Peer Adjacency SID (as defined in ) 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 . 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 for identification of an Adjacency SID or BGP Peer Adjacency SID (as defined in ) 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 .
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 ), such as a SID associated with the End behavior (as defined in ) of the node that is originating the prefix. The SR Algorithm (refer to ), the SRv6 SID behavior (as defined in or other SRv6 specifications), and structure (as defined in ) MAY also be provided.
Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6:
This type allows for identification of an SRv6 SID corresponding to an Adjacency SID or BGP Peer Adjacency SID (as defined in ), such as a SID associated with the End.X behavior (as defined in ) 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. 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 . The SR Algorithm (refer to ), the SRv6 SID behavior (as defined in or other SRv6 specifications), and structure (as defined in ) MAY also be provided.
Type K: IPv6 Addresses for link endpoints as Local, Remote pair for SRv6:
This type allows for identification of an SRv6 SID corresponding to an Adjacency SID or BGP Peer Adjacency SID (as defined in ), such as a SID associated with the End.X behavior (as defined in ) 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 . The SR Algorithm (refer to ), the SRv6 SID behavior (as defined in or other SRv6 specifications), and structure (as defined in ) 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 SIDs specific to the IGP Flex Algorithm in SR Policy. For SID types C through K, a SID value MAY also be optionally provided to the headend for verification purposes. describes the resolution and verification of the SIDs and segment lists on the headend. When building the MPLS label stack or the SRv6 SID list from the segment list, the node instantiating the policy MUST interpret the set of Segments as follows:
  • The first Segment represents the topmost MPLS label or the first SRv6 SID. It identifies the active segment the traffic will be directed toward along the explicit SR path.
  • The last segment represents the bottommost MPLS label or the last SRv6 SID the traffic will be directed toward along the explicit SR path.
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 . When an "IPv6 Explicit NULL label" is not present as the bottom label, the headend SHOULD automatically impose one. Refer to for more details.
Validity of a Candidate Path
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 or path of last resort for traffic being steered into an SR Policy using its BSID (refer to ). A segment list of an explicit candidate path MUST be declared invalid when any of the following is true:
  • It is empty.
  • Its weight is 0.
  • It comprises a mix of SR-MPLS and SRv6 segment types.
  • The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s).
  • 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.
  • 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:
  • The headend is unable to find the SID in its SR-DB
  • 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.
  • 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 :
  • 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.
  • Its last segment is not an Adjacency SID (including BGP Peer Adjacency SID) of any of the links present on neighbor nodes and 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.
Dynamic Candidate Path A dynamic candidate path is specified as an optimization objective and a set of 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 . If no solution is found to the optimization objective and constraints, then the dynamic candidate path MUST be declared invalid. 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.
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.
Binding SID The Binding SID (BSID) is fundamental to Segment Routing . It provides scaling, network opacity, and service independence. illustrates some of these benefits. This section describes the association of BSID with an SR Policy.
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.
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. A BSID is available when its value is not associated with any other usage, e.g., a label used by some other MPLS forwarding entry or an SRv6 SID used in some other context (such as to another segment, to another SR Policy, or that it is outside the range of SRv6 Locators). In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM ) 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.Encaps and End.B6.Encaps.Red ) 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 . 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, the SR Policy MAY dynamically bind a BSID to itself. Dynamically bound BSIDs 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 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.
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 the active candidate path.
Frequent Use Case: All Specified to the Same BSID All the paths of the SR Policy can have the same specified BSID.
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.
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.
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 .
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 . The SR Policy state can be reported by the headend node via BGP-LS or PCEP . 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 and , respectively. Implementations MAY support an administrative state to control locally provisioned policies via mechanisms like command-line interface (CLI) or NETCONF.
Steering into an SR Policy A headend can steer a packet flow into a valid SR Policy in various ways:
  • Incoming packets have an active SID matching a local BSID at the headend.
  • Per-Destination Steering: incoming packets match a BGP/Service route, which recurses on an SR Policy.
  • Per-Flow Steering: incoming packets match or recurse on a forwarding array of which some of the entries are SR Policies.
  • Policy-Based Steering: incoming packets match a routing policy that directs them on an SR Policy.
Validity of an SR Policy An SR Policy is invalid when all its candidate paths are invalid as described in Sections and . By default, upon transitioning to the invalid state,
  • an SR Policy and its BSID are removed from the forwarding plane.
  • 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).
Drop-upon-Invalid SR Policy An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This would entail the following:
  • an invalid SR Policy and its BSID is kept in the forwarding plane with an action to drop.
  • 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.
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. In the case of SRv6, the processing is similar and follows the SR Policy headend behaviors as specified in . 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 to ) 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.
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 . 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, and VPN label V.
  • has a valid SR Policy P to (color = C, endpoint = N) of segment list <S1, S2, S3> and BSID B.
  • 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 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 . The same behavior applies to any type of service route: any AFI/SAFI of BGP or the Locator/ID Separation Protocol (LISP) 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 next-hop 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.
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:
  • learns a BGP route R/r via next-hop N, Color Extended communities C1 and C2.
  • has a valid SR Policy P1 to (color = C1, endpoint = N) of segment list <S1, S2, S3> and BSID B1.
  • has a valid SR Policy P2 to (color = C2, endpoint = N) of segment list <S4, S5, S6> and BSID B2.
  • 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. 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.
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:
  • the BGP process learns of a route R/r via N and with Color Extended community C.
  • 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.
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 .
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:
  • has a valid SR Policy P1 to (color = C1, endpoint = N) of segment list <S1, S2, S3> and BSID B1.
  • has a valid SR Policy P2 to (color = C2, endpoint = N) of segment list <S4, S5, S6> and BSID B2.
  • 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 .
  • is configured to match flows in its ingress interfaces (upon any field such as Ethernet destination/source/VLAN/TOS or IP destination/source/Differentiated Services Code Point (DSCP), or transport ports etc.), and color them 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:
  • N via recursion on an array A (instead of the immediate outgoing link associated with the IGP shortest path to N).
  • Entry A(0) set to the immediate outgoing link of the IGP shortest path to N.
  • Entry A(1) set to SR Policy P1 of BSID=B1.
  • 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 that recurses on N. H colors these 3 packets respectively with forwarding-class 0, 1, and 2. As a result, for SR-MPLS:
  • H forwards K along the shortest path to N (i.e., pushes the Prefix-SID of N).
  • H pushes <S1, S2, S3> on packet K1 and forwards the resulting frame along the shortest path to S1.
  • 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 . 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 entry 0, 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. A headend MAY support options to apply per-flow steering only for traffic matching specific prefixes (e.g., specific IGP or BGP prefixes).
Policy-Based Routing Finally, headend H MAY be configured with a local routing policy that overrides any BGP/IGP path and steers a specified packet on an SR Policy. This includes the use of mechanisms like IGP Shortcut for automatic routing of IGP prefixes over SR Policies intended for such purpose.
Optional Steering Modes for BGP Destinations
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 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 for the updates to the BGP Color Extended community for the implementation of these mechanisms.
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:
  • SR Policy (NH, C1).
  • SR Policy (null, C1).
  • SR Policy (NH, C2).
  • SR Policy (null, C2).
  • IGP to NH.
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.
  • H learns a BGP route R/r via next-hop N, Color Extended community C.
  • H has a valid SR Policy P to (color = C, endpoint = N) of segment list <S1, S2, S3> and BSID B.
  • 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 applied to BGP-based steering.
Recovering from Network Failures
Leveraging TI-LFA Local Protection of the Constituent IGP Segments In any topology, Topology-Independent Loop-Free Alternate (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 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.
Using an SR Policy to Locally Protect a Link
Local Protection Using SR Policy 1----2-----6----7 | | | | 4----3-----9----8
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>. 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 2-to-6 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 2-to-6.
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:
  • A pair of disjoint candidate paths are provisioned with one of them as primary and the other identified as its backup.
  • A specific candidate path is provisioned as the backup for any (active) candidate path.
  • 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-reroute mechanism MAY then be used to trigger sub-50 msec 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.
Security Considerations This document specifies in detail the SR Policy construct introduced in and its instantiation on a router supporting SR along with descriptions of mechanisms for the steering of traffic flows over it. Therefore, the security considerations of apply. The security consideration related to SR-MPLS and SRv6 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 in 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. specifies mechanisms for the 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 the forwarding of packets for those routes along undesired paths. In Sections and , 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 free-form 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.
Manageability Considerations This document specifies in detail the SR Policy construct introduced in and its instantiation on a router supporting SR along with descriptions of mechanisms for the steering of traffic flows over it. Therefore, the manageability considerations of apply. A YANG model for the configuration and operation of SR Policy has been defined in .
IANA Considerations IANA has created a new subregistry called "Segment Types" under the "Segment Routing" registry that was created by . This subregistry maintains the alphabetic identifiers for the segment types (as specified in ) 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 ZZ. This subregistry follows the Specification Required allocation policy as specified in . The initial registrations for this subregistry are as follows: Segment Types
Value Description Reference
A SR-MPLS Label RFC 9256
B SRv6 SID RFC 9256
C IPv4 Prefix with optional SR Algorithm RFC 9256
D IPv6 Global Prefix with optional SR Algorithm for SR-MPLS RFC 9256
E IPv4 Prefix with Local Interface ID RFC 9256
F IPv4 Addresses for link endpoints as Local, Remote pair RFC 9256
G IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS RFC 9256
H IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS RFC 9256
I IPv6 Global Prefix with optional SR Algorithm for SRv6 RFC 9256
J IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6 RFC 9256
K IPv6 Addresses for link endpoints as Local, Remote pair for SRv6 RFC 9256
Guidance for Designated Experts The Designated Expert (DE) is expected to ascertain the existence of suitable documentation (a specification) as described in and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested assignment. Additionally, the DE must verify that any request for one of these assignments has been made available for review and comment within the IETF: the DE will post the request to the SPRING Working Group mailing list (or a successor mailing list designated by the IESG). If the request comes from within the IETF, it should be documented in an Internet-Draft. Lastly, the DE must ensure that any other request for a code point does not conflict with work that is active or already published within the IETF.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing with the MPLS Data Plane Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). IPv6 Segment Routing Header (SRH) Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The BGP Tunnel Encapsulation Attribute This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. Informative References Distribution of Traffic Engineering (TE) Policies and State using BGP-LS Work in Progress Advertising Segment Routing Policies in BGP Work in Progress IGP Flexible Algorithm Work in Progress Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. Work in Progress PCEP extension to support Segment Routing Policy Candidate Paths Cisco Systems, Inc. Ciena Corporation Juniper Networks, Inc. Huawei Technologies Nokia This document introduces a mechanism to specify a Segment Routing (SR) policy, as a collection of SR candidate paths. An SR policy is identified by <headend, color, endpoint> tuple. An SR policy can contain one or more candidate paths where each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. This document proposes extension to PCEP to support association among candidate paths of a given SR policy. The mechanism proposed in this document is applicable to both MPLS and IPv6 data planes of SR. Work in Progress Packet-Optical Integration in Segment Routing Ciena Corporation Infinera Corporation Individual Apstra Equinix Inc Cisco Systems This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport/optical networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric by having very few devices with the capability to process packets. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation to packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains. Work in Progress ASCII format for network interchange Use of OSI IS-IS for routing in TCP/IP and dual environments This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] Traffic Engineering (TE) Extensions to OSPF Version 2 This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. Multiprotocol Extensions for BGP-4 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] IS-IS Extensions for Traffic Engineering This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] Traffic Engineering Extensions to OSPF Version 3 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK] OSPF for IPv6 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK] The Locator/ID Separation Protocol (LISP) This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community. OSPF Traffic Engineering (TE) Metric Extensions In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. Signaling Maximum SID Depth (MSD) Using OSPF This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3. Signaling Maximum SID Depth (MSD) Using IS-IS This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. IS-IS Traffic Engineering (TE) Metric Extensions In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. SR Policy Implementation and Deployment Considerations Work in Progress YANG Data Model for Segment Routing Policy Work in Progress Topology Independent Fast Reroute using Segment Routing Cisco Systems Individual Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two connected network using a link-state IGP. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. Work in Progress Traffic Accounting in Segment Routing Networks Work in Progress Segment Routing Traffic Accounting Counters Work in Progress
Acknowledgement The authors would like to thank , , , , , , , , , , , , , , and for their review, comments, and suggestions.
Contributors The following people have contributed to this document: Cisco Systems
msiva@cisco.com
Cisco Systems
zali@cisco.com
Cisco Systems
jliste@cisco.com
Cisco Systems
fclad@cisco.com
Cisco Systems
skraza@cisco.com
Cisco Systems
mkoldych@cisco.com
Juniper Networks
shraddha@juniper.net
Google, Inc.
stevenlin@google.com
Google, Inc.
pkrol@google.com
Deutsche Telekom
martin.horneffer@telekom.de
Steinberg Consulting
dws@steinbergnet.net
Orange Business Services
bruno.decraene@orange.com
Orange Business Services
stephane.litkowski@orange.com
Verizon
luay.jalil@verizon.com
Authors' Addresses Cisco Systems, Inc.
Pegasus Parc De kleetlaan 6a Diegem 1831 Belgium cfilsfil@cisco.com
Cisco Systems, Inc.
India ketant.ietf@gmail.com
Bell Canada
671 de la gauchetiere W Montreal Quebec H3B 2M8 Canada daniel.voyer@bell.ca
British Telecom
alex.bogdanov@bt.com
Microsoft
One Microsoft Way Redmond WA 98052-6399 United States of America pamattes@microsoft.com