RFC 9256
Segment Routing Policy Architecture
Segment Routing Policy Architecture 🌈
Okay bestie, this is RFC 9256 💖, and it's called Segment Routing Policy Architecture. The IETF (Internet Engineering Task Force) published it in July 2022. It's a Standards Track document, so it's a real Internet standard 🔥. Its ISSN is 2070-1721.
The authors are C. Filsfils, K. Talaulikar (who edited it, so it says Ed.), D. Voyer, A. Bogdanov, and P. Mattes 🫶. Talaulikar is at Cisco Systems, Inc., Voyer is at Bell Canada, Bogdanov is at British Telecom, and Mattes is at Microsoft. The header doesn't give an affiliation for Filsfils.
This RFC updates RFC 8402 ✨. The header doesn't list anything it obsoletes.
Abstract ✨
Segment Routing (SR) lets a node steer a packet flow along any path 🦋. Intermediate per-path states get eliminated thanks to source routing, which is so iconic. An SR Policy is an ordered list of segments (aka instructions) that represents a source-routed policy 💅.
Packet flows get steered into an SR Policy on the node where it's instantiated, called the headend node 👑. The packets steered into an SR Policy carry an ordered list of segments tied to that policy. This document updates RFC 8402 because it spells out 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). More info on Internet Standards is in Section 2 of RFC 7841 🧚.
Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9256 🔗.
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, because 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 they are provided without warranty as described in the Revised BSD License ⚖️.
Table of Contents 📚
1. Introduction
1.1. Requirements Language
2. SR Policy
2.1. Identification of an SR Policy
2.2. Candidate Path and Segment List
2.3. Protocol-Origin of a Candidate Path
2.4. Originator of a Candidate Path
2.5. Discriminator of a Candidate Path
2.6. Identification of a Candidate Path
2.7. Preference of a Candidate Path
2.8. Validity of a Candidate Path
2.9. Active Candidate Path
2.10. Validity of an SR Policy
2.11. Instantiation of an SR Policy in the Forwarding Plane
2.12. Priority of an SR Policy
2.13. Summary
3. Segment Routing Database
4. Segment Types
4.1. Explicit Null
5. Validity of a Candidate Path
5.1. Explicit Candidate Path
5.2. Dynamic Candidate Path
5.3. Composite Candidate Path
6. Binding SID
6.1. BSID of a Candidate Path
6.2. BSID of an SR Policy
6.3. Forwarding Plane
6.4. Non-SR Usage of Binding SID
7. SR Policy State
8. Steering into an SR Policy
8.1. Validity of an SR Policy
8.2. Drop-upon-Invalid SR Policy
8.3. Incoming Active SID is a BSID
8.4. Per-Destination Steering
8.5. Recursion on an On-Demand Dynamic BSID
8.6. Per-Flow Steering
8.7. Policy-Based Routing
8.8. Optional Steering Modes for BGP Destinations
9. Recovering from Network Failures
9.1. Leveraging TI-LFA Local Protection of the Constituent IGP
Segments
9.2. Using an SR Policy to Locally Protect a Link
9.3. Using a Candidate Path for Path Protection
10. Security Considerations
11. Manageability Considerations
12. IANA Considerations
12.1. Guidance for Designated Experts
13. References
13.1. Normative References
13.2. Informative References
Acknowledgement
Contributors
Authors' Addresses1. Introduction ✨
Segment Routing (SR) [RFC8402] lets a node steer a packet flow along any path 🦋. The headend is the node where the instructions for source routing (i.e., segments) get written into the packet. That makes it the starting node for a specific segment routing path 👑. Once again, 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 represents 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. [RFC8660] describes how this ordered list is represented and processed as an MPLS label stack for SR-MPLS. Meanwhile, [RFC8754] and [RFC8986] describe the same thing for Segment Routing over IPv6 (SRv6), using the Segment Routing Header (SRH) 🌸.
[RFC8402] introduces the SR Policy construct and gives an overview of how it's used in Segment Routing use cases. This document updates [RFC8402] to spell out the detailed concepts of SR Policy and steering packets into an SR Policy 📝. It applies equally to the SR-MPLS and SRv6 flavours of segment routing 🦋.
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 gives you a framework for setting up an ordered list of segments on a node. That's how you implement a source routing policy to steer traffic for a specific purpose from that node, like a specific Service Level Agreement (SLA) 🔥.
The Segment Routing architecture [RFC8402] says any instruction can be bound to a segment. So an SR Policy can be built out of any type of Segment Identifier (SID), including ones tied to 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 gets instantiated or implemented. The headend is specified as an IPv4 or IPv6 address, and it 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). In that 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) 🤖.
An implementation MAY allow the assignment of a symbolic name made of printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy. This works as a user-friendly attribute for debugging and troubleshooting 🐛. 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 an SR Policy to a headend, via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR Policy [BGP-SR-POLICY] 📡.
A segment list represents a specific source-routed path for sending 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 a 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. It lets you combine 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 to including constituent SR Policies under a parent SR Policy using a composite candidate path:
- 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 a weight for load-balancing purposes (refer to Section 2.11 for details). The default weight is 1 🎀.
Section 2.13 illustrates an information model for the hierarchical relationships between the SR Policy constructs described in this section 🧠✨.
2.3. Protocol-Origin of a Candidate Path
Okay so a headend can hear about a candidate path for an SR Policy <Color, Endpoint> in a few ways: through configuration, through PCEP [RFC8664] [PCEP-SR-POLICY-CP], or through BGP [BGP-SR-POLICY]. 💌
Protocol-Origin is an 8-bit value tied to whatever mechanism or protocol was used to signal or provision the SR Policy. It tells you which protocol/mechanism gave you the candidate path, and it shows how much that source is preferred over the others. 👑
The headend gives each source of SR Policy info its own Protocol-Origin value. This value works as a tiebreaker between candidate paths with equal Preference (more on that in Section 2.9) ✨. Here are the RECOMMENDED default values:
+=================+===================+
| Protocol-Origin | Description |
+=================+===================+
| 10 | PCEP |
+-----------------+-------------------+
| 20 | BGP SR Policy |
+-----------------+-------------------+
| 30 | Via Configuration |
+-----------------+-------------------+
Table 1: Protocol-Origin Default ValuesNote that the order above is there to give a clear ordering, and implementations MAY allow modifications of these default values assigned to protocols on the headend, kinda like a routing administrative distance. 🦋 How it gets applied in candidate path selection is in Section 2.9.
2.4. Originator of a Candidate Path
The Originator is the node that provisioned or signaled the candidate path on the headend. It's a 160-bit numerical value made by smooshing together the fields of the tuple <Autonomous System Number (ASN), node-address>, like so: 🧚
- Autonomous System Number (ASN): 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: 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 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's or the provisioning controller/node's ASN and address. The default value is 0 for both AS and node address. 🌸
When signaling is via PCEP, it's the IPv4 or IPv6 address of the PCE, and the AS number is expected to be set to 0 by default when it's not available or known. 🎀
When signaling is via BGP SR Policy, the ASN and node address are provided by BGP (see [BGP-SR-POLICY]) on the headend. 🫶
2.5. Discriminator of a Candidate Path
The Discriminator is a 32-bit value attached to a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin. Here's how it works for each source: 🔥
- When provisioning is via configuration, this is a unique identifier for a candidate path. It's 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 [PCEP-SR-POLICY-CP]. The default value is 0.
- When signaling is via BGP SR Policy, the BGP process receiving the route provides the distinguisher (see [BGP-SR-POLICY]) as the Discriminator. Note that 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 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> so that add, delete, or modify operations on them happen in an unambiguous manner, regardless of their source(s). This is non-negotiable, bestie. 😭
The tuple <Protocol-Origin, Originator, Discriminator> uniquely identifies a candidate path. ✨
Candidate paths MAY also be assigned or signaled with a symbolic name made of printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E). This is a user-friendly attribute for debugging and troubleshooting, so it's kinda like a nickname 🍓. 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 [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
2.7. Preference of a Candidate Path
The Preference of the candidate path is what gets used to select the best candidate path for an SR Policy. It's a 32-bit value where a higher value means 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 [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.
2.8. Validity of a Candidate Path
A candidate path is usable when it's 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 Section 5. 🫶
2.9. Active Candidate Path
A candidate path is selected when it's valid and it's determined to be the best path of the SR Policy. The selected path is called the "active path" of the SR Policy in this document. 👑
Whenever a new path is learned, 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. Non-stop re-running, periodt. 🔥
The candidate path selection process mainly runs on the candidate path Preference. A candidate path is selected when it's valid and it has the highest Preference value among all the valid candidate paths of the SR Policy. 💅
When there are multiple valid candidate paths with the same Preference, the tie-breaking rules get evaluated on the identification tuple in the following order until only one valid best path is selected: 🎀
- The higher value of Protocol-Origin is selected.
- If specified by configuration, prefer the existing installed path.
- The lower value of the Originator is selected.
- Finally, the higher value of the Discriminator is selected.
The rules are built with multiple protocols and sources in mind, so they may not follow the logic of a single protocol (e.g., BGP best path selection). The motivation behind these rules is as follows: 🧠
- The Preference, being the primary criterion, lets an operator influence selection across paths, so they can provision multiple path options. For example, CP1 is preferred because 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. For example, you can prefer a path signaled via BGP SR Policy over what is configured. 🦋
- The Protocol-Origin lets an operator set up a default selection mechanism across protocol sources. For example, to prefer configured paths over paths signaled via BGP SR Policy or PCEP. 🌸
- The Originator lets an operator run multiple redundant controllers and still keep deterministic behavior over which of them are preferred, even if they're providing the same candidate paths for the same SR Policies to the headend. 🫶
- The Discriminator performs the final tie-breaking step to make sure selection is deterministic regardless of the order in which candidate paths are signaled across multiple transport channels or sessions. 💜
[SR-POLICY-CONSID] 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 get instantiated in the forwarding plane. 🧚
Only the active candidate path MUST be used for forwarding traffic that's 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. Main character rules only, bestie. 👑
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. 🙈
2.12. 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. 🎀
2.13. Summary ✨
okay so let's recap the whole info model in one go 💅 Here's POL1, which is identified by <Headend = H1, Color = 1, Endpoint = E1> 🎀
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 W4POL1 has two candidate paths, CP1 and CP2 🦋 Each one is identified by a <Protocol-Origin, Originator, Discriminator> tuple, but only within the scope of POL1, so it's like a little address book just for this policy 📖 CP1 is the active candidate path because it's valid and has the highest Preference 👑 Its two segment lists get installed as the forwarding instantiation of POL1, and traffic steered on POL1 is flow-based hashed on <SID11...SID1i> with a ratio of W1/(W1+W2). Literally the main character of the whole setup 🌸
Now for the composite one, SR Policy POL100 with a composite candidate path 🧚
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 W2The constituent SR Policies POL1 and POL2 each have an info model like the one we just saw at the start of this section 💜 They're only referenced by color inside the composite candidate path, because their headend and endpoint match POL100's. The valid segment lists of the active candidate path of POL1 and POL2 are what get installed in the forwarding. Traffic steered on POL100 is hashed per flow across POL1 with a proportion of W1/(W1+W2), and inside POL1 the flow-based hashing over its segment lists works exactly like we covered earlier in this section 🫶
3. Segment Routing Database 🗄️
An SR Policy computation node (think headend or controller) keeps track of the Segment Routing Database, aka the SR-DB 💖 The SR-DB is a conceptual database, meaning it's a way to picture all the different pieces of info and where they come from, which can help with SR Policy computation and validation. There's no specific requirement that an implementation actually builds a new database like that, so don't stress about it 😌
An SR headend uses the SR-DB to validate explicit candidate paths and to compute dynamic candidate paths ✨
The info in the SR-DB may include:
- IGP information (topology, IGP metrics based on IS-IS [RFC1195] and OSPF [RFC2328] [RFC5340])
- Segment Routing information (such as Segment Routing Global Block, Segment Routing Local Block, Prefix-SIDs, Adj-SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] [RFC8986]
- TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group) [RFC5305] [RFC3630] [RFC5329]
- Extended TE Link attributes (such as latency, loss) [RFC8570] [RFC7471]
- Inter-AS Topology information [RFC9086]
The attached domain topology may be learned through protocols or mechanisms like IGP, Border Gateway Protocol - Link State (BGP-LS), or NETCONF 🌈
A non-attached (remote) domain topology may be learned through protocols or mechanisms like BGP-LS or NETCONF 🍓
Some use cases only need the attached domain topology in the SR-DB, but in others the SR-DB holds the topology of multiple domains, and in that case it's multi-domain capable 🦋
The SR-DB may also hold the SR Policies instantiated in the network. That info can be collected via BGP-LS [BGP-LS-TE-POLICY] or PCEP [RFC8231] (along with [PCEP-SR-POLICY-CP] and [PCEP-BSID-LABEL]). This lets you build an end-to-end policy out of intermediate SR policies, and Section 6 has the deets 🎀
The SR-DB may also contain the Maximum SID Depth (MSD) capability of nodes in the topology. That can be collected via IS-IS [RFC8491], OSPF [RFC8476], BGP-LS [RFC8814], or PCEP [RFC8664] 🔥
Using the SR-DB for path computation, and for validating optimization objectives and constraints of paths, is outside the scope of this document 🙈 Some implementation aspects related to path computation are covered in [SR-POLICY-CONSID] 💅
4. Segment Types ✨
Okay bestie, so a segment list is an ordered set of segments written as <S1, S2, ... Sn>, where S1 is the first segment. 🦋 Think of it like a playlist where the order really matters.
Depending on the data plane you want, the headend builds either an MPLS label stack or an SRv6 Segment Routing Header [RFC8754] from that list. 💖 The segment list itself can be written using different segment-descriptor types, and these are the ones defined so far:
- Type A: SR-MPLS Label: Any MPLS label that matches one of the segment types defined for SR-MPLS (as in [RFC8402] or other SR-MPLS specifications) can be used. Special purpose labels like explicit-null, or in general any MPLS label, MAY also be used. 🌸 For example, this type can point at a label that maps to an optical transport path on a packet transport node.
- Type B: SRv6 SID: An IPv6 address that matches any of the SID behaviors for SRv6 (as in [RFC8986] or other SRv6 specifications) can be used. Optionally, the SRv6 SID behavior (as in [RFC8986] or other SRv6 specifications) and structure (as in [RFC8986]) MAY also be provided, so the headend can validate the SID when it builds the segment list. 🔥
- Type C: IPv4 Prefix with optional SR Algorithm: Here the headend is required to resolve the specified IPv4 Prefix Address to the SR-MPLS label for its Prefix SID segment (as in [RFC8402]). The SR algorithm (see Section 3.1.1 of [RFC8402]) to use MAY also be provided. 🧚
- Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: Same vibe as Type C, but with an IPv6 Global Prefix Address. The headend is required to resolve it to the SR-MPLS label for its Prefix SID segment (as in [RFC8402]). The SR Algorithm (see Section 3.1.1 of [RFC8402]) to use MAY also be provided. 💅
- Type E: IPv4 Prefix with Local Interface ID: This one lets you identify an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]) SR-MPLS label for point-to-point links, including IP unnumbered links. ✨ The headend is required to resolve the IPv4 Prefix Address to the node that originates it, then use the Local Interface ID to find the point-to-point link whose adjacency is being referred to. The Local Interface ID link descriptor follows the semantics in [RFC5307]. This type can also indicate indirection into a layer 2 interface (so, no IP address), like an optical transport path, a layer 2 Ethernet port, or a circuit on the specified node. 🫶
- Type F: IPv4 Addresses for link endpoints as Local, Remote pair: This type identifies an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]) SR-MPLS label for links. 🦋 The headend is required to resolve the IPv4 Local Address to the node that originates it, then use the IPv4 Remote Address to identify the link adjacency being referred to. The Local and Remote Address pair link descriptors follow the semantics in [RFC7752].
- Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SR-MPLS: This type identifies an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]) label for links, including ones that only have Link-Local IPv6 addresses. 🌈 The headend is required to resolve the IPv6 Prefix Address to the node that originates it, then use the Local Interface ID to find the point-to-point link whose adjacency is being referred to. For anything other than a point-to-point link, the specific adjacency over that link also needs to be resolved using the Remote Prefix and Interface ID. The Local and Remote pair of Prefix and Interface ID link descriptor follows the semantics in [RFC7752]. This type can also indicate indirection into a layer 2 interface (so, no IP address), like an optical transport path, a layer 2 Ethernet port, or a circuit on the specified node. 👑
- Type H: IPv6 Addresses for link endpoints as Local, Remote pair for SR-MPLS: This type identifies an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]) label for links with Global IPv6 addresses. 💜 The headend is required to resolve the Local IPv6 Address to the node that originates it, then use the Remote IPv6 Address to identify the link adjacency being referred to. The Local and Remote Address pair link descriptors follow the semantics in [RFC7752].
- Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: The headend is required to resolve the IPv6 Global Prefix Address to an SRv6 SID for a Prefix SID segment (as in [RFC8402]), such as a SID tied to the End behavior (as in [RFC8986]) of the node that originates the prefix. ⭐ The SR Algorithm (see Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as in [RFC8986] or other SRv6 specifications), and structure (as in [RFC8986]) MAY also be provided.
- Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair for SRv6: This type identifies an SRv6 SID for an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]), such as a SID tied to the End.X behavior (as in [RFC8986]) of a link or adjacency with only Link-Local IPv6 addresses. 🎀 The headend is required to resolve the IPv6 Prefix Address to the node that originates it, then use the Local Interface ID to find the point-to-point link whose adjacency is being referred to. For anything other than a point-to-point link, the specific adjacency also needs to be resolved using the Remote Prefix and Interface ID. The Local and Remote pair of Prefix and Interface ID link descriptor follows the semantics in [RFC7752]. The SR Algorithm (see Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as in [RFC8986] or other SRv6 specifications), and structure (as in [RFC8986]) MAY also be provided.
- Type K: IPv6 Addresses for link endpoints as Local, Remote pair for SRv6: This type identifies an SRv6 SID for an Adjacency SID or BGP Peer Adjacency SID (as in [RFC8402]), such as a SID tied to the End.X behavior (as in [RFC8986]) of a link or adjacency with Global IPv6 addresses. 🍓 The headend is required to resolve the Local IPv6 Address to the node that originates it, then use the Remote IPv6 Address to identify the link adjacency being referred to. The Local and Remote Address pair link descriptors follow the semantics in [RFC7752]. The SR Algorithm (see Section 3.1.1 of [RFC8402]), the SRv6 SID behavior (as in [RFC8986] or other SRv6 specifications), and structure (as in [RFC8986]) MAY also be provided.
When the algorithm isn't specified for the SID types above that optionally allow it, the headend SHOULD use the Strict Shortest Path algorithm if it's available. Otherwise, it SHOULD use the default Shortest Path algorithm. 🌸 Specifying the algorithm is what lets you use SIDs that belong to the IGP Flex Algorithm [IGP-FLEX-ALGO] in an SR Policy, which is honestly so iconic.
For SID types C through K, a SID value MAY also be optionally provided to the headend for verification purposes. 🔍 Section 5.1 explains how the headend resolves and verifies the SIDs and segment lists.
When the node instantiating the policy builds the MPLS label stack or the SRv6 SID list from the segment list, it MUST interpret the set of Segments like this:
- 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. 🌈
4.1. Explicit Null 🧚
A Type A SID MAY be any MPLS label, including special purpose labels. 💖
Let's do an example, because examples are everything 🙈. Say the traffic-engineered path you want from headend 1 to endpoint 4 can be written as the segment list <16002, 16003, 16004>, where 16002, 16003, and 16004 are the IPv4 Prefix SIDs bound to nodes 2, 3, and 4. Then IPv6 traffic can be steered from node 1 to node 4 along that same 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 forward the frame out its directly connected interface to node 4. 🦋
The endpoint receives the traffic with the top label "2", which tells it the payload is an IPv6 packet. 💅
When you steer unlabeled IPv6 BGP destination traffic with an SR Policy made of segment lists based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [BGP-SR-POLICY]. If an "IPv6 Explicit NULL label" isn't present as the bottom label, the headend SHOULD automatically impose one. 🫶 See Section 8 for more details.
5. Validity of a Candidate Path 🌈
5.1. Explicit Candidate Path ✨
okay so an explicit candidate path is tied to a segment list, or a whole set of them 💅 It's set up by the operator directly or through a controller 🎀
The brains behind picking that segment list live outside the SR Policy headend. The headend does NOT compute the list. It only double-checks that the list is valid 🫶
An explicit candidate path MAY be just one explicit segment list that holds only an implicit-null label 🦋 That label means pop-and-forward. The BSID gets popped, and then traffic is forwarded based on the inner label, or on an IP lookup if the packets are unlabeled IP. Honestly this is giving fallback energy 😭 It can act as a backup or a path of last resort for traffic steered in through its BSID (see Section 8.3) 💖
A segment list on an explicit candidate path MUST be declared invalid when any of these are true:
- It is empty.
- Its weight is 0.
- It mixes SR-MPLS and SRv6 segment types.
- The headend can't do path resolution for the first SID into one or more outgoing interface(s) and next-hop(s).
- The headend can't do SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.
- SID verification fails for any SID that was explicitly asked to be verified.
"Unable to perform path resolution" just means the headend has no path to the SID in its SR database 🌸
SID verification happens when the controller explicitly asks the headend to verify SID(s) through the signaling protocol being used. Implementations MAY give you a local config option to turn verification on globally, per policy, or per candidate path 🧚
"Verification fails" for a SID means any of these:
- The headend can't find the SID in its SR-DB.
- The headend spots a mismatch between the SID value it was given and the SID value it resolves from the context for SIDs of type C through K in its SR-DB.
- The headend can't do SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.
In multi-domain setups, the headend might not be able to verify that SIDs in remote domains are reachable 🌈 Types A or B MUST be used for any SIDs whose reachability can't be verified. Also, the first SID MUST always be reachable, no matter what type it is 👑
A segment list MAY additionally be declared invalid when BOTH of these conditions are met:
- Its last segment is not a Prefix SID (including BGP Peer Node-SID) advertised by the node named as the endpoint of the corresponding SR Policy.
- Its last segment is not an Adjacency SID (including BGP Peer Adjacency SID) on any of the links that exist on neighbor nodes and terminate on the node named as the endpoint of the corresponding SR Policy.
An explicit candidate path becomes invalid as soon as it has no valid segment list left 💀
And an explicit candidate path MAY additionally be declared invalid when its segment lists (valid or invalid) use segment types from different SR data planes 🙈
5.2. Dynamic Candidate Path
A dynamic candidate path is described by an optimization objective and a set of constraints 🎯
The headend of the policy taps into its SR database to compute a segment list (the "solution segment list") that solves this optimization problem, for either the SR-MPLS or the SRv6 data plane, whichever one is specified 💜
The headend recomputes the solution segment list any time the inputs to the problem change (for example, when the topology changes) 🔄
When computing it locally isn't possible (say the policy's tail end is outside the topology the headend knows about) or isn't wanted, the headend can lean on an external entity instead ✨ For example, it can send a path computation request to a PCE that supports the PCEP extensions specified in [RFC8664].
If no solution is found for the optimization objective and constraints, then the dynamic candidate path MUST be declared invalid 💀
[SR-POLICY-CONSID] talks about some of the optimization objectives and constraints a dynamic candidate path might consider. It also shows some of the lovely properties you'd want from computing the solution segment list 🫶
5.3. Composite Candidate Path
A composite candidate path is defined as a group of its constituent SR Policies 🧩
A composite candidate path is valid when it has at least one valid constituent SR Policy 🌟
6. Binding SID
The Binding SID (BSID) is a core piece of Segment Routing [RFC8402] 💖 It brings scaling, network opacity, and service independence. [SR-POLICY-CONSID] shows off some of these perks. This section covers how a BSID gets tied to 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 as long as the value (a label in MPLS, an IPv6 address in SRv6) is available. A BSID counts as available when its value isn't already tied to some other usage. Examples: a label used by another MPLS forwarding entry, or an SRv6 SID used in some other context (like for another segment, for another SR Policy, or sitting outside the range of SRv6 Locators) 🙈
For SR-MPLS, SRv6 BSIDs (for example, with the End.BM [RFC8986] behavior) MAY be associated with the SR Policy alongside the MPLS BSID 🌈 For SRv6, multiple SRv6 BSIDs (for example, with behaviors like End.B6.Encaps and End.B6.Encaps.Red [RFC8986]) MAY be associated with the SR Policy 💅
Optionally, rather than only checking that the active path's BSID is available, a headend MAY check that it's available within the given SID range, which is the Segment Routing Local Block (SRLB) described in [RFC8402] 🧚
When the specified BSID isn't available (or, if the optional check is used, isn't in the SRLB), an alert message MUST be generated through mechanisms like syslog 🚨
In the situations described above where the SR Policy has no BSID available, the SR Policy MAY dynamically bind a BSID to itself ✨ Dynamically bound BSIDs SHOULD use an available SID outside the SRLB 🌸
Say 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 either has no specified BSID or has one that isn't available (because something else is using it), then the SR Policy MAY keep the previous BSID B1 🦋
So the association between an SR Policy and a BSID MAY change over the life of the SR Policy (for example, when the active path changes). Because of that, the BSID SHOULD NOT be used to identify 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 that case, a BSID MAY be dynamically bound to the SR Policy as soon as the first valid candidate path is received. That BSID then sticks around for the whole life of the SR Policy, even when the active candidate path changes 💜
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 configuring the Specified-BSID-only restrictive behavior on the headend, either for all SR Policies or for individual ones. On top of that, this restrictive behavior MAY also be signaled to the headend on a per-SR-Policy basis 🔥
When this restrictive behavior is enabled, if the candidate path has an unspecified BSID, or if the specified BSID isn't 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 through mechanisms like syslog. After that, the other candidate paths MUST be evaluated for becoming the active candidate path 🫶
6.3. Forwarding Plane
A valid SR Policy results in a BSID-keyed entry being installed in the forwarding plane, with the action of steering matching packets onto the selected path of the SR Policy 🚀
If the Specified-BSID-only restrictive behavior is enabled and the BSID of the active path isn't available (or, optionally, isn't in the SRLB), then the SR Policy does not install any BSID-indexed entry in the forwarding plane 💀
6.4. Non-SR Usage of Binding SID
An implementation MAY choose to associate a Binding SID with any type of interface (for example, a layer 3 termination of an Optical Circuit) or with a tunnel (for example, an IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel, and so on) 🌈 This lets non-SR-enabled interfaces and tunnels be used as segments in an SR Policy segment list, without having to form 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 [POI-SR] ✨
7. SR Policy State
The SR Policy state is kept on the headend to represent the state of the policy and its candidate paths 🧠 It gives an accurate picture of whether the SR Policy is 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 because of validation errors or because it wasn't preferred 🙅♀️ The operational state info reported for SR Policies is specified in [SR-POLICY-YANG] 📋
The headend node can report the SR Policy state via BGP-LS [BGP-LS-TE-POLICY] or PCEP [RFC8231] [PCEP-BSID-LABEL] 📡
SR Policy state on the headend also covers traffic accounting for the flows steered through the policies 🧾 The details of SR Policy accounting are beyond the scope of this document. The SR traffic counters and how they're used in the bigger picture of traffic accounting across an SR network are covered in [SR-TRAFFIC-COUNTERS] and [SR-TRAFFIC-ACCOUNTING], respectively 💅
Implementations MAY support an administrative state to control locally provisioned policies, through mechanisms like the command-line interface (CLI) or NETCONF 🎀
8. Steering into an SR Policy
A headend can steer a packet flow into a valid SR Policy in a few different ways 🦋
- Incoming packets have an active SID that matches 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, some of whose entries are SR Policies 🌊
- Policy-Based Steering: incoming packets match a routing policy that directs them onto an SR Policy 🧚
8.1. Validity of an SR Policy 💅
okay so an SR Policy is invalid when ALL of its candidate paths are invalid, as described in Sections 2.10 and 5. 💀
By default, when it flips to the invalid state:
- an SR Policy and its BSID get 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 gets 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. This is what it looks like:
- an invalid SR Policy and its BSID stay 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 stays in place 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 those constraints are no longer met, the operator wants the PW traffic dropped. Specifically, the operator does not want the PW routed according to the IGP shortest path to the PW endpoint. Main character boundaries, honestly 🎀
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. 🔥
This part is important, so here's the note exactly as written:
"Forwards the resulting packet according to SID 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 segment routing in general and the binding SID in particular: the ability to encode a classification and the resulting steering in the packet header, which helps scale and simplify intermediate aggregation nodes. it's giving efficiency 👑
When Drop-Upon-Invalid (refer to 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:
- learns a BGP route
R/rvia 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. Iconic. 👑
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 the Locator/ID Separation Protocol (LISP) [RFC6830], for both IPv4/IPv6. the range on this one is wild 🦋
In a BGP multi-path scenario, the BGP route MAY be resolved over a mix of paths that include those 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. 🎀
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:
- learns a BGP route
R/rvia 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 is 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:
- 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. ⭐
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:
- 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 [RFC5462].
- 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 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 entry 0, the forwarding entry for N is updated to bypass the array and point directly to its outgoing interface and next-hop. so efficient, I'm obsessed ✨
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). 🦋
8.7. 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. 💅
8.8. Optional Steering Modes for BGP Destinations 💖
8.8.1. Color-Only BGP Destination Steering 💅
okay so in the last section, the steering on an SR Policy depends on matching the BGP route's next-hop N with the authorized Color Extended community C, which together make the SR Policy tuple (N, C) 💖 this is the most likely form of BGP destination steering, and it's the one recommended for most use cases ✨
this section is about a different mechanism that's based only on the Color Extended community 🦋 there are three steering modes, and we're going to look at all of them 🫶
for the default one, Type 0, the BGP destination gets steered like this:
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 we already covered earlier in this document, and it's what's recommended in most scenarios 🌸
Type 1 is a bit more flexible 🎀
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.and Type 2 goes even further, adding two more fallback steps before it gives up and uses the IGP 👑
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, which is all bits set to the 0 value 🧚
✨ if you want the details on how the BGP Color Extended community gets updated to support these mechanisms, check out [BGP-SR-POLICY] 📚
8.8.2. Multiple Colors and CO flags 🌈
okay, so the steering preference is decided first by the highest Color Extended community value, and then by the Color-Only steering type for that color 💜 let's say a prefix comes in via (NH, C1(CO=01), C2(CO=01)), where 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.
8.8.3. Drop-upon-Invalid 🙈
this is where the earlier rule gets an upgrade 💅 the document already defined that when all of 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.
now the BGP Policy is allowed to say that the BGP steering must always stay on the SR Policy, no matter whether that policy is valid or not 😭 this is the "drop-upon-invalid" option from Section 8.2, just 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) [SR-TI-LFA] gives you 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 TI-LFA protected IGP segments gets to borrow the local protection of its constituent segments 🫶 but 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 💀
also 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 🍓
here's the picture:
1----2-----6----7
| | | |
4----3-----9----8
Figure 1: Local Protection Using SR Policyan 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 is links outside an IGP domain: for example, 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 that setup, links 2-to-6 and 3to9 can't benefit from TI-LFA automated local protection. but the SR Policy with segment list <3, 9, 6> on node 2 can be configured locally to act as a fast-reroute backup path for link 2-to-6 🎀
9.3. Using a Candidate Path for Path Protection 🧚♀️
an SR Policy can have multiple candidate paths, but at any point in time there's a single active candidate path 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) ✨ these are the options:
- a pair of disjoint candidate paths gets provisioned, with one as primary and the other identified as its backup.
- a specific candidate path gets 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, so that it gives 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 ⚡ and 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 the mechanisms for steering traffic flows over it 💜 so the security considerations of [RFC8402] apply, and the security considerations related to SR-MPLS [RFC8660] and SRv6 [RFC8754] [RFC8986] also apply too 🫶
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 used as an endpoint for an SR Policy is advertised by more than one node, due to misconfiguration or spoofing, and the same is advertised via an IGP, then the traffic steered over the SR Policy may end up getting diverted to an undesired node, resulting in misrouting 😱 mechanisms for detecting duplicate prefix advertisement can be used to identify and correct such scenarios 🚨 the details of these mechanisms are outside the scope of this document 🙈
Section 8 specifies mechanisms for steering traffic flows corresponding to BGP routes over SR Policies that match the color value signaled via the BGP Color Extended Community attached to the BGP routes 🌈 a misconfiguration or error in setting the Color Extended Community on BGP routes can result in packets for those routes being forwarded along undesired paths 💀
in Sections 2.1 and 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 🏷️ symbolic names are so nice for display clarity, but 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 🔎 implementations that display this kind of information might also wish to display it in a way that differentiates it from known-good information 🎨 (display conventions are inherently implementation specific; one example might be using 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 the mechanisms for steering traffic flows over it 🧁 so the manageability considerations of [RFC8402] apply too ✨
a YANG model for the configuration and operation of SR Policy has been defined in [SR-POLICY-YANG] 📋
12. IANA Considerations ✨
Okay bestie, IANA time 📋🦋 A brand new subregistry called "Segment Types" is being created under the "Segment Routing" registry that [RFC8986] made. It keeps track of the alphabetic identifiers for the segment types from Section 4 that can show up in an SR Policy's segment list 💜 The identifiers go A to Z, and when those run out they continue with AA to AZ, then BA to BZ, and so on, all the way to ZZ 🔤 This subregistry follows the Specification Required allocation policy from [RFC8126], so new entries need a real spec 📝
The initial registrations look like this:
+=======+=============================================+===========+
| 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 | RFC 9256 |
| | Algorithm for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| E | IPv4 Prefix with Local Interface ID | RFC 9256 |
+-------+---------------------------------------------+-----------+
| F | IPv4 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair | |
+-------+---------------------------------------------+-----------+
| G | IPv6 Prefix and Interface ID for link | RFC 9256 |
| | endpoints as Local, Remote pair for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| H | IPv6 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair for SR-MPLS | |
+-------+---------------------------------------------+-----------+
| I | IPv6 Global Prefix with optional SR | RFC 9256 |
| | Algorithm for SRv6 | |
+-------+---------------------------------------------+-----------+
| J | IPv6 Prefix and Interface ID for link | RFC 9256 |
| | endpoints as Local, Remote pair for SRv6 | |
+-------+---------------------------------------------+-----------+
| K | IPv6 Addresses for link endpoints as Local, | RFC 9256 |
| | Remote pair for SRv6 | |
+-------+---------------------------------------------+-----------+
Table 2: Segment Types12.1. Guidance for Designated Experts 🧑🏫💅
The Designated Expert (DE) is expected to make sure there's suitable documentation (a specification) like [RFC8126] describes, and to check that the document is permanently and publicly available 📚 The DE should also check that the purpose and use of the requested assignment are clear 🔍 On top of that, the DE must make sure any request for one of these assignments has been put out for review and comment within the IETF. That means the DE posts the request to the SPRING Working Group mailing list (or a successor mailing list the IESG picks) 📬 If the request comes from inside the IETF, it should be documented in an Internet-Draft 📄 And lastly, the DE must make sure that any other request for a code point doesn't clash with work that's active or already published within the IETF 🚫 Protect the vibes, protect the code points 🫶
13. References 📚✨
13.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>.
[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>.13.2. Informative References ✨
okay so these are the informative ones 📚 they're not required reading, but they're the vibes-check for everything the doc touches 💅
[BGP-LS-TE-POLICY]
Previdi, S., Talaulikar, K., Ed., Dong, J., Ed., Chen, M.,
Gredler, H., and J. Tantsura, "Distribution of Traffic
Engineering (TE) Policies and State using BGP-LS", Work in
Progress, Internet-Draft, draft-ietf-idr-te-lsp-
distribution-17, April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-
lsp-distribution-17>.
[BGP-SR-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., Jain, D., and S. Lin, "Advertising Segment Routing
Policies in BGP", Work in Progress, Internet-Draft, draft-
ietf-idr-segment-routing-te-policy-18, June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-18>.
[IGP-FLEX-ALGO]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-20, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
flex-algo-20>.
[PCEP-BSID-LABEL]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/Segment Identifier
(SID) in PCE-based Networks.", Work in Progress, Internet-
Draft, draft-ietf-pce-binding-label-sid-15, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
binding-label-sid-15>.
[PCEP-SR-POLICY-CP]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-07, 21 April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-07>.
[POI-SR] Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J.,
Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical
Integration in Segment Routing", Work in Progress,
Internet-Draft, draft-anand-spring-poi-sr-08, 29 July
2019, <https://datatracker.ietf.org/doc/html/draft-anand-
spring-poi-sr-08>.
[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>.
[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>.
[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>.
[SR-POLICY-CONSID]
Filsfils, C., Talaulikar, K., Ed., Krol, P., Horneffer,
M., and P. Mattes, "SR Policy Implementation and
Deployment Considerations", Work in Progress, Internet-
Draft, draft-filsfils-spring-sr-policy-considerations-09,
24 April 2022, <https://datatracker.ietf.org/doc/html/
draft-filsfils-spring-sr-policy-considerations-09>.
[SR-POLICY-YANG]
Raza, K., Ed., Sawaya, S., Shunwan, Z., Voyer, D.,
Durrani, M., Matsushima, S., and V. Beeram, "YANG Data
Model for Segment Routing Policy", Work in Progress,
Internet-Draft, draft-ietf-spring-sr-policy-yang-01, April
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
spring-sr-policy-yang-01>.
[SR-TI-LFA]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
08, 21 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-08>.
[SR-TRAFFIC-ACCOUNTING]
Ali, Z., Filsfils, C., Talaulikar, K., Sivabalan, S.,
Horneffer, M., Raszuk, R., Litkowski, S., Voyer, D.,
Morton, R., and G. Dawra, "Traffic Accounting in Segment
Routing Networks", Work in Progress, Internet-Draft,
draft-ali-spring-sr-traffic-accounting-07, May 2022,
<https://datatracker.ietf.org/doc/html/draft-ali-spring-
sr-traffic-accounting-07>.
[SR-TRAFFIC-COUNTERS]
Filsfils, C., Ali, Z., Ed., Horneffer, M., Voyer, D.,
Durrani, M., and R. Raszuk, "Segment Routing Traffic
Accounting Counters", Work in Progress, Internet-Draft,
draft-filsfils-spring-sr-traffic-counters-02, October
2021, <https://datatracker.ietf.org/doc/html/draft-
filsfils-spring-sr-traffic-counters-02>.Acknowledgement 🫶
The authors sent a huge thank-you to 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 J. Bernardos for their review, comments, and suggestions. literally the real MVPs 👑✨
Contributors 🌈
these people all helped build this doc, so they get their flowers too 🌸
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
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.comAuthors' Addresses 💅
and here are the authors, with where to find them 💜
Clarence Filsfils
Cisco Systems, Inc.
Pegasus Parc
De kleetlaan 6a
1831 Diegem
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
Paul Mattes
Microsoft
One Microsoft Way
Redmond, WA 98052-6399
United States of America
Email: pamattes@microsoft.com📦 where this page comes from
- ietf: rfc9256 2022-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms