RFC 8986
Segment Routing over IPv6 (SRv6) Network Programming
RFC 8986: Segment Routing over IPv6 (SRv6) Network Programming 🦋
okay bestie, this is RFC 8986, titled Segment Routing over IPv6 (SRv6) Network Programming ✨ It's a Standards Track document from the IETF, so it's an actual official Internet standard, not just vibes 💅 It's dated February 2021, and its ISSN is 2070-1721 🌸
The editors are C. Filsfils and P. Camarillo (both marked "Ed.", meaning editor), and both are from Cisco Systems, Inc. 💖 The other authors are J. Leddy at Akamai Technologies, D. Voyer at Bell Canada, S. Matsushima at SoftBank, and Z. Li at Huawei Technologies 🫶 The title block here doesn't list any document it obsoletes or updates, so there's nothing to report on that front 🤷♀️
Abstract 🌸
The SRv6 Network Programming framework lets a network operator or an application write a packet processing program by encoding a sequence of instructions right into the IPv6 packet header 🧚
Each instruction runs on one or several nodes in the network, and it's identified by an SRv6 Segment Identifier in the packet 💌
This doc defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors. That's what makes it possible to build interoperable overlays with underlay optimization 🌈
Status of This Memo 📜
This is an Internet Standards Track document ⭐
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🙈
Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8986 💜
Copyright Notice 🎀
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💅
This doc 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. Please read them carefully, because they explain your rights and restrictions with respect to this doc 📖 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as described in the Simplified BSD License 🔥
Table of Contents 🗺️
1. Introduction
2. Terminology
2.1. Requirements Language
3. SRv6 SID
3.1. SID Format
3.2. SID Allocation within an SR Domain
3.3. SID Reachability
4. SR Endpoint Behaviors
4.1. End: Endpoint
4.1.1. Upper-Layer Header
4.2. End.X: L3 Cross-Connect
4.3. End.T: Specific IPv6 Table Lookup
4.4. End.DX6: Decapsulation and IPv6 Cross-Connect
4.5. End.DX4: Decapsulation and IPv4 Cross-Connect
4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup
4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup
4.8. End.DT46: Decapsulation and Specific IP Table Lookup
4.9. End.DX2: Decapsulation and L2 Cross-Connect
4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup
4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup
4.12. End.DT2M: Decapsulation and L2 Table Flooding
4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy with
Encapsulation
4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH
4.15. End.BM: Endpoint Bound to an SR-MPLS Policy
4.16. Flavors
4.16.1. PSP: Penultimate Segment Pop of the SRH
4.16.2. USP: Ultimate Segment Pop of the SRH
4.16.3. USD: Ultimate Segment Decapsulation
5. SR Policy Headend Behaviors
5.1. H.Encaps: SR Headend with Encapsulation in an SR Policy
5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation
5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames
5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 Frames
6. Counters
7. Flow-Based Hash Computation
8. Control Plane
8.1. IGP
8.2. BGP-LS
8.3. BGP IP/VPN/EVPN
8.4. Summary
9. Security Considerations
10. IANA Considerations
10.1. Ethernet Next Header Type
10.2. SRv6 Endpoint Behaviors Registry
10.2.1. Registration Procedures
10.2.2. Initial Registrations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
Segment Routing [RFC8402] is built on the source routing paradigm 🗺️ An ingress node steers a packet through an ordered list of instructions called "segments". Each one of those instructions stands for a function to be called at a specific location in the network. A function is defined locally on the node where it runs, and it can be anything from simply moving forward in the segment list to a complex, user-defined behavior 🤯 Network Programming mixes simple and complex Segment Routing functions together to reach a networking goal that's way beyond plain packet routing 🔥
This doc defines the SRv6 Network Programming concept and specifies the main Segment Routing behaviors, so you can build interoperable overlays with underlay optimization 💖
[SRV6-NET-PGM-ILLUST] illustrates the concepts from this document 🖼️
Familiarity with the Segment Routing Header [RFC8754] is expected 🎀
2. Terminology 📚
The following terms used in this document are defined in [RFC8402]: Segment Routing (SR), SR Domain, Segment ID (SID), SRv6, SRv6 SID, SR Policy, Prefix-SID, and Adj-SID 🧚
The following terms used in this document are defined in [RFC8754]: Segment Routing Header (SRH), SR source node, transit node, SR Segment Endpoint Node, Reduced SRH, Segments Left, and Last Entry 🌸
These terms are used in this document as defined below:
- FIB: Forwarding Information Base. A FIB lookup is a lookup in the forwarding table.
- SA: Source Address
- DA: Destination Address
- L3: Layer 3
- L2: Layer 2
- MAC: Media Access Control
- EVPN: Ethernet VPN
- ESI: Ethernet Segment Identifier
- Per-CE VPN label: A single label for each attachment circuit that is shared by all routes with the same "outgoing attachment circuit" (Section 4.3.2 of [RFC4364]) 💜
- Per-VRF VPN label: A single label for the entire VPN Routing and Forwarding (VRF) table that is shared by all routes from that VRF (Section 4.3.2 of [RFC4364]) 💜
- SL: The Segments Left field of the SRH
- SRv6 SID function: The function part of the SID is an opaque identification of a local behavior bound to the SID. It's formally defined in Section 3.1 of this document 🦋
- SRv6 Endpoint behavior: A packet processing behavior executed at an SRv6 Segment Endpoint Node. Section 4 of this document defines SRv6 Endpoint behaviors related to traffic-engineering and overlay use cases. Other behaviors (e.g., service programming) are outside the scope of this document 🌈
An SR Policy gets resolved to a SID list. A SID list is written as <S1, S2, S3>, where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path 🛣️
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
- Source Address (SA), Destination Address (DA), and next header (SRH).
- An SRH with SID list
<S1, S2, S3>withSegments Left = SL.
Note the difference between the <> and () symbols 👀 <S1, S2, S3> is a SID list where S1 is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) is the same SID list, but encoded in SRH format, where the rightmost SID in the SRH is the first SID and the leftmost SID in the SRH is the last SID. When you're talking about an SR Policy in a high-level use case, <S1, S2, S3> is simpler. When you're looking at an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notation is more convenient 💅
- The payload of the packet is omitted.
2.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 💖 Lowercase versions don't count, so they're just regular words 😌
3. SRv6 SID 🦋
[RFC8402] defines an SRv6 Segment Identifier as an IPv6 address that's explicitly associated with the segment 🌸
When an SRv6 SID sits in the Destination Address field of an IPv6 header, it gets routed through transit nodes in an IPv6 network, just like any other IPv6 address 🚀
Its processing is defined in Section 4.3 of [RFC8754], and it's reproduced here as a reminder (this is a direct quote, so I'm keeping it word for word 🫶):
| Without constraining the details of an implementation, the SR
| segment endpoint node creates Forwarding Information Base (FIB)
| entries for its local SIDs.
|
| When an SRv6-capable node receives an IPv6 packet, it performs a
| longest-prefix-match lookup on the packet's destination address.
| This lookup can return any of the following:
| * A FIB entry that represents a locally instantiated SRv6 SID
|
| * A FIB entry that represents a local interface, not locally
| instantiated as an SRv6 SID
|
| * A FIB entry that represents a nonlocal route
|
| * No MatchSection 4 of this document defines a new set of SRv6 SID behaviors on top of the one defined in Section 4.3.1 of [RFC8754] ✨
3.1. SID Format 🧁
This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG. A locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG) 🍓 The locator length, L, is flexible, so the operator can pick whatever locator length they like 🙌 F and A may be any value as long as L+F+A <= 128. When L+F+A is less than 128, the remaining bits of the SID MUST be zero 🔒
A locator may be represented as B:N, where B is the SRv6 SID block (the IPv6 prefix the operator allocates for SRv6 SIDs) and N is the identifier of the parent node that instantiates the SID 🏠
When the LOC part of the SRv6 SIDs is routable, it leads to the node which instantiates the SID 🛬
The FUNCT is an opaque identification of a local behavior bound to the SID 🎭
The term "function" refers to the bit string in the SRv6 SID. The term "behavior" identifies the behavior bound to the SID. Some behaviors are defined in Section 4 of this document 🌈
An SRv6 Endpoint behavior may require additional information for its processing (e.g., related to the flow or service). This information may be encoded in the ARG bits of the SID 💌
In that case, the semantics and format of the ARG bits are defined as part of the SRv6 Endpoint behavior specification 📝
The ARG value of a routed SID SHOULD remain constant among packets in a given flow. Varying ARG values among packets in a flow may result in different ECMP hashing and cause reordering 🌀
3.2. SID Allocation within an SR Domain 🎀
Okay so locators get handed out the same way regular IPv6 infrastructure addresses do 💅 For example, a network operator can:
- Assign block
B::/48to the SR domain - Assign a unique
B:N::/64block to each SRv6-enabled node in the domain
Real world flex time 🔥 One mobile service provider has commercially deployed SRv6 across more than 1000 commercial routers and 1800 whitebox routers. All of these devices are SRv6-enabled and advertise SRv6 SIDs. The provider already ran IPv6 and gave its infrastructure addresses from the Unique Local Address (ULA) space [RFC4193]. They specifically allocated three /48 prefixes (Country X, Country Y, Country Z) to support their SRv6 infrastructure. From those /48 prefixes, each router got a /64 prefix, and all of that router's SIDs are allocated from it 🧚
Another example: a large mobile and fixed-line service provider has commercially deployed SRv6 across their country-wide network 🌈 This provider was assigned a /20 prefix by a Regional Internet Registry (RIR). They sub-allocated a few /48 prefixes to their infrastructure to deploy SRv6. Each router is assigned a /64 prefix, and all SIDs of that router are allocated from it.
Honestly the address usage is tiny in both cases 🫶 It's less than one billionth and one millionth of the available address space, respectively.
A service provider that receives the current minimum allocation of a /32 prefix from an RIR can assign a /48 prefix to its SRv6 infrastructure, then allocate /64 prefixes for SIDs at each SRv6 node. That /48 assignment is one sixty-five thousandth (1/2^16) of the usable IPv6 address space available for assignment by the provider 💖
When an operator instantiates a SID at a node, they specify a SID value B:N:FUNCT and the behavior bound to that SID, using one of the SRv6 Endpoint Behavior codepoints from the registry defined in this document (see Table 6) 👑
The node advertises the SID, B:N:FUNCT, in the control plane (see Section 8), together with the SRv6 Endpoint Behavior codepoint that identifies the behavior of the SID 📣
An SR source node cannot figure out the behavior just by looking at the FUNCT value of a SID 🙈
So the SRv6 Endpoint Behavior codepoint gets advertised along with the SID in the control plane. That's the whole trick ✨
An SR source node uses the SRv6 Endpoint Behavior codepoint to map the received SID (B:N:FUNCT) to a behavior 🦋
An SR source node picks a desired behavior at an advertising node by choosing the SID (B:N:FUNCT) that was advertised with that behavior 💅
Here's how it looks:
- A network operator may assign an SRv6 SID block
2001:db8:bbbb::/48from their in-house operation block for their SRv6 infrastructure. - A network operator may assign an SRv6 Locator
2001:db8:bbbb:3::/64to one particular router, for example Router 3, in their SR Domain. - At Router 3, within the locator
2001:db8:bbbb:3::/64, the network operator or the router performs dynamic assignment for:- Function
0x0100associated with the behavior End.X (Endpoint with L3 cross-connect) between Router 3 and its connected neighbor router (e.g., Router 4). This function is encoded as a 16-bit value and has no arguments (F=16, A=0). This SID is advertised in the control plane as2001:db8:bbbb:3:100::with an SRv6 Endpoint Behavior codepoint value of5. - Function
0x0101associated with the behavior End.X (Endpoint with L3 cross-connect) between Router 3 and its connected neighbor router (e.g., Router 2). This function is encoded as a 16-bit value and has no arguments (F=16, A=0). This SID is advertised in the control plane as2001:db8:bbbb:3:101::with an SRv6 Endpoint Behavior codepoint value of5.
- Function
These examples don't rule out any other IPv6 addressing allocation scheme 🌸
3.3. SID Reachability 🦋
Most often, node N would advertise IPv6 prefix(es) matching the LOC parts that cover its SIDs, or a shorter-mask prefix. How these advertisements get distributed and how their reachability gets calculated is specific to the routing protocol, so that stuff is outside the scope of this document 🤓
An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix advertised via a routing protocol. An SRv6 SID that doesn't meet this condition is non-routed 💜
Let's look at a classic illustration 🎀
Node N is explicitly configured with two SIDs: 2001:db8:b:1:100:: and 2001:db8:b:2:101::.
The network learns about a path to 2001:db8:b:1::/64 via the IGP, so a packet destined to 2001:db8:b:1:100:: would be routed up to N. The network does not learn about a path to 2001:db8:b:2::/64 via the IGP, so a packet destined to 2001:db8:b:2:101:: would not be routed up to N 😭
A packet can be steered through a non-routed SID 2001:db8:b:2:101:: by using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...>, where the non-routed SID is preceded by a routed SID to the same node. A packet can also be steered to a node instantiating a non-routed SID by putting an Adj-SID to that node in front of it in the SID list 🧚 Routed and non-routed SRv6 SIDs are the SRv6 instantiation of global and local segments, respectively [RFC8402] 🌈
4. SR Endpoint Behaviors ✨
okay so here's the lineup of well-known behaviors that can get attached to a SID 💅
+-------------------+---------------------------------------------+
| End | Endpoint |
| | |
| | The SRv6 instantiation of a Prefix-SID |
| | [RFC8402] |
+-------------------+---------------------------------------------+
| End.X | Endpoint with L3 cross-connect |
| | |
| | The SRv6 instantiation of an Adj-SID |
| | [RFC8402] |
+-------------------+---------------------------------------------+
| End.T | Endpoint with specific IPv6 table lookup |
+-------------------+---------------------------------------------+
| End.DX6 | Endpoint with decapsulation and IPv6 cross- |
| | connect |
| | |
| | e.g., IPv6-L3VPN (equivalent to per-CE VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DX4 | Endpoint with decapsulation and IPv4 cross- |
| | connect |
| | |
| | e.g., IPv4-L3VPN (equivalent to per-CE VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT6 | Endpoint with decapsulation and specific |
| | IPv6 table lookup |
| | |
| | e.g., IPv6-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT4 | Endpoint with decapsulation and specific |
| | IPv4 table lookup |
| | |
| | e.g., IPv4-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DT46 | Endpoint with decapsulation and specific IP |
| | table lookup |
| | |
| | e.g., IP-L3VPN (equivalent to per-VRF VPN |
| | label) |
+-------------------+---------------------------------------------+
| End.DX2 | Endpoint with decapsulation and L2 cross- |
| | connect |
| | |
| | e.g., L2VPN use case |
+-------------------+---------------------------------------------+
| End.DX2V | Endpoint with decapsulation and VLAN L2 |
| | table lookup |
| | |
| | e.g., EVPN Flexible Cross-connect use case |
+-------------------+---------------------------------------------+
| End.DT2U | Endpoint with decapsulation and unicast MAC |
| | L2 table lookup |
| | |
| | e.g., EVPN Bridging Unicast use case |
+-------------------+---------------------------------------------+
| End.DT2M | Endpoint with decapsulation and L2 table |
| | flooding |
| | |
| | e.g., EVPN Bridging Broadcast, Unknown |
| | Unicast, and Multicast (BUM) use case with |
| | Ethernet Segment Identifier (ESI) filtering |
+-------------------+---------------------------------------------+
| End.B6.Encaps | Endpoint bound to an SRv6 Policy with |
| | encapsulation |
| | |
| | SRv6 instantiation of a Binding SID |
+-------------------+---------------------------------------------+
| End.B6.Encaps.Red | End.B6.Encaps with reduced SRH |
| | |
| | SRv6 instantiation of a Binding SID |
+-------------------+---------------------------------------------+
| End.BM | Endpoint bound to an SR-MPLS Policy |
| | |
| | SRv6 instantiation of an SR-MPLS Binding |
| | SID |
+-------------------+---------------------------------------------+
Table 1: Endpoint BehaviorsThe list isn't exhaustive, bestie. Basically any behavior can be attached to a local SID 🦋 For example, a node N can bind a SID to a local Virtual Machine (VM) or container that does any complex processing on the packet, as long as there's an SRv6 Endpoint Behavior codepoint allocated for that processing 🧚
When an SRv6-capable node (N) gets an IPv6 packet whose destination address matches a FIB entry for a locally instantiated SRv6 SID (S), the IPv6 header chain is processed as defined in Section 4 of [RFC8200]. For SRv6 SIDs tied to an Endpoint behavior defined in this document, the SRH and Upper-Layer header are processed as laid out in the subsections below 🎀
The pseudocode describing these behaviors spells out the local processing at a node. An implementation of that pseudocode is compliant as long as the externally observable wire protocol matches what the pseudocode describes 🫶
Section 4.16 defines flavors of some of these behaviors ✨
Section 10.2 of this document defines the IANA registry used to maintain all these behaviors, plus future ones defined in other documents 🌈
4.1. End: Endpoint
The Endpoint behavior ("End" for short) is the most basic behavior, and it's giving foundational 👑 It is the instantiation of a Prefix-SID [RFC8402].
When N receives a packet whose IPv6 DA is S and S is a local End SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S16. }
| Note:
|
| The End behavior operates on the same FIB table (i.e.,
| identified by VRF or L3 relay ID) associated to the packet.
| Hence, the FIB lookup on line S15 is done in the same FIB table
| as the ingress interface.4.1.1. Upper-Layer Header
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End SID, N does the following:
S01. If (Upper-Layer header type is allowed by local configuration) {
S02. Proceed to process the Upper-Layer header
S03. } Else {
S04. Send an ICMP Parameter Problem to the Source Address
with Code 4 (SR Upper-layer Header Error)
and Pointer set to the offset of the Upper-Layer header,
interrupt packet processing, and discard the packet.
S05 }Allowing processing of specific Upper-Layer header types is useful for Operations, Administration, and Maintenance (OAM) 🔧 As an example, an operator might want to permit pinging of SIDs. To do that, they may enable local configuration to allow Upper-Layer header type 58 (ICMPv6) 🙈
It is RECOMMENDED that an implementation of local configuration only allows Upper-Layer header processing of types that do not result in the packet being forwarded (e.g., ICMPv6). 💀
4.2. End.X: L3 Cross-Connect
The "Endpoint with L3 cross-connect" behavior ("End.X" for short) is a variant of the End behavior. It's giving End but make it cross-connect 🍓
It is the SRv6 instantiation of an Adj-SID [RFC8402], and its main use is for traffic-engineering policies 🌸
Any SID instance of this behavior is associated with a set, J, of one or more L3 adjacencies.
When N receives a packet destined to S and S is a local End.X SID, the line S15 from the End processing is replaced by the following:
S15. Submit the packet to the IPv6 module for transmission
to the new destination via a member of J
| Note:
|
| S15. If the set J contains several L3 adjacencies, then one
| element of the set is selected based on a hash of the packet's
| header (see Section 7).If a node N has 30 outgoing interfaces to 30 neighbors, usually the operator would explicitly instantiate 30 End.X SIDs at N: one per L3 adjacency to a neighbor. Potentially, more End.X could be explicitly defined (groups of L3 adjacencies to the same neighbor or to different neighbors) 🧁
Note that if N has an outgoing interface bundle I to a neighbor Q made of 10 member links, N might allocate up to 11 End.X local SIDs: one for the bundle itself and then up to one for each L2 member link. The flows steered using the End.X SID corresponding to the bundle itself get load-balanced across the member links via hashing, while the flows steered using the End.X SID corresponding to a member link get steered over that specific member link alone 💖
When the End.X behavior is associated with a BGP Next-Hop, it is the SRv6 instantiation of the BGP peering segments [RFC8402].
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.X SID, process the packet as per Section 4.1.1. 🩷
4.3. End.T: Specific IPv6 Table Lookup ✨
okay so the "Endpoint with specific IPv6 table lookup" behavior (that's End.T for short) is a variant of the End behavior 💅 and it's giving multi-table energy.
End.T is used for multi-table operation in the core 🦋 so, for this reason, an instance of End.T is associated with an IPv6 FIB table T 🌸
When N receives a packet destined to S and S is a local End.T SID, the line S15 from the End processing gets swapped out for the following 🎀
S15.1. Set the packet's associated FIB table to T
S15.2. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destinationWhen processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.T SID, process the packet as per Section 4.1.1 🫶
4.4. End.DX6: Decapsulation and IPv6 Cross-Connect 🧚
The "Endpoint with decapsulation and IPv6 cross-connect" behavior (End.DX6 for short) is a variant of the End.X behavior, and honestly it's so iconic 👑
One of the applications of End.DX6 is the L3VPNv6 use case, where a FIB lookup in a specific tenant table at the egress Provider Edge (PE) is not required 💖 This is equivalent to the per-CE VPN label in MPLS [RFC4364].
The End.DX6 SID MUST be the last segment in an SR Policy, and it is associated with one or more L3 IPv6 adjacencies J. no skipping that, bestie 🙈
When N receives a packet destined to S and S is a local End.DX6 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX6 SID, N does the following:
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IPv6 packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }Note: S01. "41" refers to "IPv6 encapsulation" as defined in the IANA "Assigned Internet Protocol Numbers" registry. S03. If the End.DX6 SID is bound to an array of L3 adjacencies, then one entry of the array is selected based on the hash of the packet's header (see Section 7).
4.5. End.DX4: Decapsulation and IPv4 Cross-Connect 🌈
The "Endpoint with decapsulation and IPv4 cross-connect" behavior (End.DX4 for short) is a variant of the End.X behavior ✨
One of the applications of End.DX4 is the L3VPNv4 use case, where a FIB lookup in a specific tenant table at the egress PE is not required 🎀 This is equivalent to the per-CE VPN label in MPLS [RFC4364].
The End.DX4 SID MUST be the last segment in an SR Policy, and it is associated with one or more L3 IPv4 adjacencies J. 💅
When N receives a packet destined to S and S is a local End.DX4 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX4 SID, N does the following:
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IPv4 packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }Note: S01. "4" refers to "IPv4 encapsulation" as defined in the IANA "Assigned Internet Protocol Numbers" registry. S03. If the End.DX4 SID is bound to an array of L3 adjacencies, then one entry of the array is selected based on the hash of the packet's header (see Section 7).
4.6. End.DT6: Decapsulation and Specific IPv6 Table Lookup 🦋
The "Endpoint with decapsulation and specific IPv6 table lookup" behavior (End.DT6 for short) is a variant of the End.T behavior, lowkey my favourite name in this whole section 😭
One of the applications of End.DT6 is the L3VPNv6 use case, where a FIB lookup in a specific tenant table at the egress PE is required 🫶 This is equivalent to the per-VRF VPN label in MPLS [RFC4364].
Note that an End.DT6 may be defined for the main IPv6 table, in which case End.DT6 supports the equivalent of an IPv6-in-IPv6 decapsulation (without VPN/tenant implication) 🌸
The End.DT6 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv6 FIB table T. 👑
When N receives a packet destined to S and S is a local End.DT6 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT6 SID, N does the following:
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S05. } Else {
S06. Process as per Section 4.1.1
S07. }4.7. End.DT4: Decapsulation and Specific IPv4 Table Lookup 💜
The "Endpoint with decapsulation and specific IPv4 table lookup" behavior (End.DT4 for short) is a variant of the End.T behavior 🍓
One of the applications of End.DT4 is the L3VPNv4 use case, where a FIB lookup in a specific tenant table at the egress PE is required ✨ This is equivalent to the per-VRF VPN label in MPLS [RFC4364].
Note that an End.DT4 may be defined for the main IPv4 table, in which case End.DT4 supports the equivalent of an IPv4-in-IPv6 decapsulation (without VPN/tenant implication) 🦋
The End.DT4 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv4 FIB table T. 💖
When N receives a packet destined to S and S is a local End.DT4 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 SID, N does the following:
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S05. } Else {
S06. Process as per Section 4.1.1
S07. }4.8. End.DT46: Decapsulation and Specific IP Table Lookup 🎀
The "Endpoint with decapsulation and specific IP table lookup" behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 behavior, so it's basically the best of both worlds 🌈
One of the applications of End.DT46 is the L3VPN use case, where a FIB lookup in a specific IP tenant table at the egress PE is required 🧚 This is equivalent to the single per-VRF VPN label (for IPv4 and IPv6) in MPLS [RFC4364].
Note that an End.DT46 may be defined for the main IP table, in which case End.DT46 supports the equivalent of an IP-in-IPv6 decapsulation (without VPN/tenant implication) 💅
The End.DT46 SID MUST be the last segment in an SR Policy, and a SID instance is associated with an IPv4 FIB table T4 and an IPv6 FIB table T6. 👑
When N receives a packet destined to S and S is a local End.DT46 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT46 SID, N does the following:
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T4
S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S05. } Else if (Upper-Layer header type == 41(IPv6) ) {
S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T6
S08. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S09. } Else {
S10. Process as per Section 4.1.1
S11. }4.9. End.DX2: Decapsulation and L2 Cross-Connect 🍓
The "Endpoint with decapsulation and L2 cross-connect" behavior (End.DX2 for short) is a variant of the Endpoint behavior, and it's giving layer-2 glow-up 🌸
One of the applications of End.DX2 is the L2VPN [RFC4664] / EVPN Virtual Private Wire Service (VPWS) [RFC7432] [RFC8214] use case 🦋
The End.DX2 SID MUST be the last segment in an SR Policy, and it is associated with one outgoing interface I. 🫶
When N receives a packet destined to S and S is a local End.DX2 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX2 SID, N does the following:
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the Ethernet frame to the OIF I
S04. } Else {
S05. Process as per Section 4.1.1
S06. }Note: S01. IANA has allocated value "143" for "Ethernet" [IEEE.802.3_2018] in the "Assigned Internet Protocol Numbers" registry (see Section 10.1). S03. An End.DX2 behavior could be customized to expect a specific IEEE header (e.g., VLAN tag) and rewrite the egress IEEE header before forwarding on the outgoing interface.
Note that an End.DX2 SID may also be associated with a bundle of outgoing interfaces, so there's more than one way to get out the door 💖
4.10. End.DX2V: Decapsulation and VLAN L2 Table Lookup ✨
okay so the "Endpoint with decapsulation and VLAN L2 table lookup" behavior (End.DX2V for short) is basically a glow-up of End.DX2 🎀 It's giving variant energy.
One of the big applications is the EVPN Flexible Cross-connect use case 💅 The End.DX2V behavior looks up the Ethernet frame's VLANs in a particular L2 table. Every SID instance of this behavior is tied to an L2 table T 🧚
When N gets a packet whose IPv6 DA is S, and S is a local End.DX2 SID, everything is the same as End.DX2 except for the Upper-Layer header processing, which gets updated like this:
S03. Look up the exposed VLANs in L2 table T, and forward
via the matched table entry.✨ Note (S03): an End.DX2V behavior can be customized to expect a specific VLAN format and rewrite the egress VLAN header before forwarding on the outgoing interface. Ooh, customizable 💖
4.11. End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup 🦋
the "Endpoint with decapsulation and unicast MAC L2 table lookup" behavior (End.DT2U for short) is a variant of the End behavior. bestie, it's a whole vibe 💜
one of its applications is EVPN Bridging Unicast [RFC7432]. Any SID instance of End.DT2U is associated with an L2 table T 🌸
when N receives a packet whose IPv6 DA is S, and S is a local End.DT2U SID, the processing is identical to End.DX2 except for the Upper-Layer header processing, which goes like this:
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Look up the exposed MAC Destination Address in L2 table T
S05. If (matched entry in T) {
S06. Forward via the matched table T entry
S07. } Else {
S08. Forward via all L2 OIFs in table T
S09. }
S10. } Else {
S11. Process as per Section 4.1.1
S12. }🫶 Notes, because they matter: S01: IANA has allocated value "143" for "Ethernet" in the "Assigned Internet Protocol Numbers" registry (see Section 10.1). S03: in EVPN [RFC7432], the learning of the exposed MAC Source Address happens via the control plane. In L2VPN Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762], reachability is obtained by standard learning bridge functions in the data plane.
4.12. End.DT2M: Decapsulation and L2 Table Flooding 🌈
the "Endpoint with decapsulation and L2 table flooding" behavior (End.DT2M for short) is a variant of End.DT2U, and it's the flooding queen 👑
two of its applications are EVPN Bridging of Broadcast, Unknown Unicast, and Multicast (BUM) traffic with Ethernet Segment Identifier (ESI) filtering [RFC7432], and the EVPN Ethernet-Tree (E-Tree) [RFC8317] use cases 🍓
every SID instance of this behavior is associated with an L2 table T. It also takes an argument called "Arg.FE2". This argument gives a local mapping to ESI for split-horizon filtering of the received traffic, so a specific OIF (or set of OIFs) gets excluded from L2 table T flooding. The allocation of argument values is local to the SR Segment Endpoint Node instantiating this behavior. Signaling the argument to other nodes for the EVPN functionality happens via the control plane 🦋
when N receives a packet whose IPv6 DA is S, and S is a local End.DT2M SID, the processing is identical to End.DX2 except for the Upper-Layer header processing, which is:
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 table T
S04. Forward via all L2 OIFs excluding those associated with the
identifier Arg.FE2
S05. } Else {
S06. Process as per Section 4.1.1
S07. }🫶 Notes, because they matter: S01: IANA has allocated value "143" for "Ethernet" in the "Assigned Internet Protocol Numbers" registry (see Section 10.1). S03: in EVPN [RFC7432], the learning of the exposed MAC Source Address happens via the control plane. In L2VPN VPLS [RFC4761] [RFC4762], reachability is obtained by standard learning bridge functions in the data plane.
4.13. End.B6.Encaps: Endpoint Bound to an SRv6 Policy with Encapsulation 🔥
this is a variation of the End behavior, and it's giving scalable traffic engineering 💅
one of its applications is expressing scalable traffic-engineering policies across multiple domains. It's one of the SRv6 instantiations of a Binding SID [RFC8402], so yes, it's iconic 👑
any SID instance of this behavior is associated with an SR Policy B and a source address A.
when N receives a packet whose IPv6 DA is S, and S is a local End.B6.Encaps SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push a new IPv6 header with its own SRH containing B
S16. Set the outer IPv6 SA to A
S17. Set the outer IPv6 DA to the first SID of B
S18. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields
S19. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S20. }🫶 Notes, because they matter: S15: the SRH MAY be omitted when the SRv6 Policy B only contains one SID and there is no need to use any flag, tag, or TLV. S18: the Payload Length, Traffic Class, Hop Limit, and Next Header fields are set as per [RFC2473]. The Flow Label is computed as per [RFC6437].
when processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.B6.Encaps SID, process the packet as per Section 4.1.1 💖
4.14. End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH 🦋
this is an optimization of the End.B6.Encaps behavior, and honestly it's so efficient 🧚
End.B6.Encaps.Red reduces the size of the SRH by one SID by leaving out the first SID in the SRH of the new IPv6 header. So the first segment only lives in the IPv6 Destination Address of the new IPv6 header, and the packet is forwarded according to it ✨
the SRH Last Entry field is set as defined in Section 4.1.1 of [RFC8754].
🫶 Note: the SRH MAY be omitted when the SRv6 Policy only contains one SID and there is no need to use any flag, tag, or TLV.
4.15. End.BM: Endpoint Bound to an SR-MPLS Policy 🌸
the "Endpoint bound to an SR-MPLS Policy" behavior (End.BM for short) is a variant of the End behavior 💜
the End.BM behavior is required to express scalable traffic-engineering policies across multiple domains where some domains support the MPLS instantiation of Segment Routing. This is an SRv6 instantiation of an SR-MPLS Binding SID [RFC8402], which is a lot of acronyms but a very cute idea 🎀
any SID instance of this behavior is associated with an SR-MPLS Policy B.
when N receives a packet whose IPv6 DA is S, and S is a local End.BM SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by
the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address
with Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S11. }
S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push the MPLS label stack for B
S16. Submit the packet to the MPLS engine for transmission
S17. }when processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.BM SID, process the packet as per Section 4.1.1 🫶
4.16. Flavors 💅
okay the flavors are where it gets extra fun ✨ The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors are variants of the End, End.X, and End.T behaviors. The End, End.X, and End.T behaviors can support these flavors either individually or in combinations 🌈
4.16.1. PSP: Penultimate Segment Pop of the SRH 🧚
4.16.1.1. Guidelines 📝
SR Segment Endpoint Nodes advertise the SIDs instantiated on them via control-plane protocols, as described in Section 8. Flavored and unflavored SIDs get different behavior IDs (see Table 6) 💖
an SR Segment Endpoint Node that offers both PSP- and non-PSP-flavored behavior advertises them as two different SIDs. Two separate SIDs, bestie, no mix-ups 🎀
the SR Segment Endpoint Node only advertises the PSP flavor if the operator enables this capability at the node 🔥
the PSP operation is deterministically controlled by the SR source node 👑
a PSP-flavored SID is used by the SR source node when it needs to instruct the penultimate SR Segment Endpoint Node listed in the SRH to remove the SRH from the IPv6 header 🦋
4.16.1.2. Definition ✨
okay so SR Segment Endpoint Nodes receive the IPv6 packet with the Destination Address field of the IPv6 header equal to their SID address 💖
a penultimate SR Segment Endpoint Node is the one that, as part of SID processing, copies the last SID out of the SRH into the IPv6 Destination Address and drops Segments Left from one to zero 🦋
the PSP operation only happens at a penultimate SR Segment Endpoint Node. it does NOT happen at any transit node 🙈 and if a SID with PSP flavor shows up at a non-penultimate SR Segment Endpoint Node, the PSP behavior is not performed as described in the pseudocode below, since Segments Left wouldn't be zero. not me being picky, it's just how it works 💅
the SRH processing for End, End.X, and End.T gets a glow-up. after the instruction "S14. Update IPv6 DA with Segment List[Segments Left]" runs, these instructions must be executed as well:
S14.1. If (Segments Left == 0) {
S14.2. Update the Next Header field in the preceding header to
the Next Header value from the SRH
S14.3. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. }the usage of PSP does not increase the MTU of the IPv6 packet, so it has zero impact on the Path MTU (PMTU) discovery mechanism 🌸 no drama there!
quick reminder, [RFC8754] Section 5 defines the SR Deployment Model inside the SR Domain [RFC8402] 🎀 in that framework, the Authentication Header (AH) is not used to secure the SRH, as described in Section 7.5 of [RFC8754]. so talking about whether PSP works with AH usage is beyond the scope of this document. that's a different party, bestie 🫶
and in the context of this spec, End, End.X, and End.T with PSP do not contravene Section 4 of [RFC8200], because the destination address of the incoming packet is the address of the node executing the behavior. iconic logic, honestly 👑
4.16.1.3. Use Case
one use case for PSP is streamlining the operation of an egress border router 🧚
+----------------------------------------------------+
| |
+-+-+ +--+ +--+ +--+ +-+-+
|iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE|
| R1| +--+ +--+ +--+ |R5 |
+-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+
| |IPv6 | |IPv6 | |IPv6 | |IPv6 | |
| |DA=R3| |DA=R3| |DA=R5| |DA=R5| |
| +-----+ +-----+ +-----+ +-----+ |
| | SRH | | SRH | | IP | | IP | |
| |SL=1 | |SL=1 | +-----+ +-----+ |
| | R5 | | R5 | |
| +-----+ +-----+ |
| | IP | | IP | |
| +-----+ +-----+ |
| |
+----------------------------------------------------+
Figure 1: PSP Use Case Topologyin the diagram above, a packet goes from the ingress provider edge (iPE) to the egress provider edge (ePE). R3 is an intermediate traffic-engineering waypoint and the penultimate segment endpoint router. it copies the last segment from the SRH into the IPv6 Destination Address and drops Segments Left to 0 🍓 the Software-Defined Networking (SDN) controller knows no other node after R3 needs to inspect the SRH, so it tells R3 to yeet the exhausted SRH using a PSP-flavored SID 🚀
the perks for the egress PE are honestly so clean:
- as part of decapsulation, the egress PE is required to parse and remove fewer bytes from the packet 🫧
- if a lookup on an upper-layer IP header is required (e.g., per-VRF VPN), that header is more likely to sit within the memory the lookup engine in the forwarding ASIC (Application-Specific Integrated Circuit) can access 💜
4.16.2. USP: Ultimate Segment Pop of the SRH
the SRH processing for End, End.X, and End.T gets modified here, and instructions S02-S04 are swapped out for these:
S02. If (Segments Left == 0) {
S03.1. Update the Next Header field in the preceding header to
the Next Header value of the SRH
S03.2. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S03.3. Remove the SRH from the IPv6 extension header chain
S03.4. Proceed to process the next header in the packet
S04. }one application of the USP flavor is when a packet with an SRH is destined to an application on hosts with smartNICs ("Smart Network Interface Cards") implementing SRv6 🌈 the USP flavor removes the consumed SRH from the extension header chain before the packet is sent on to the host. clean handoff, no leftovers 🧼
4.16.3. USD: Ultimate Segment Decapsulation
the Upper-Layer header processing for End, End.X, and End.T gets modified like so 🦋
End:
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S04. } Else if (Upper-Layer header type == 4(IPv4) ) {
S05. Remove the outer IPv6 header with all its extension headers
S06. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S07. Else {
S08. Process as per Section 4.1.1
S09. }End.T:
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S05. } Else if (Upper-Layer header type == 4(IPv4) ) {
S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T
S08. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
S09. Else {
S10. Process as per Section 4.1.1
S11. }End.X:
S01. If (Upper-Layer header type == 41(IPv6) ||
Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IP packet to the L3 adjacency J
S04. } Else {
S05. Process as per Section 4.1.1
S06. }one application of the USD flavor is Topology Independent Loop-Free Alternate (TI-LFA) in P routers with encapsulation 🌟 it lets the last SR Segment Endpoint Node in the repair path list decapsulate the IPv6 header that was added at the TI-LFA Point of Local Repair, then forward the inner packet. peeling the layers like an onion, but make it efficient 🧅
5. SR Policy Headend Behaviors ✨
this section describes a set of SRv6 Policy Headend [RFC8402] behaviors 💅
+-----------------+-----------------------------------------------+
| H.Encaps | SR Headend with Encapsulation in an SR Policy |
+-----------------+-----------------------------------------------+
| H.Encaps.Red | H.Encaps with Reduced Encapsulation |
+-----------------+-----------------------------------------------+
| H.Encaps.L2 | H.Encaps Applied to Received L2 Frames |
+-----------------+-----------------------------------------------+
| H.Encaps.L2.Red | H.Encaps.Red Applied to Received L2 Frames |
+-----------------+-----------------------------------------------+
Table 2: SR Policy Headend Behaviorsthis list is not exhaustive, and future documents may define additional behaviors 🔮
5.1. H.Encaps: SR Headend with Encapsulation in an SR Policy
okay picture this 🎀 node N gets two packets, P1=(A, B2) and P2=(A,B2)(B3, B2, B1; SL=1). B2 is neither a local address nor a SID of N.
node N is configured with an IPv6 address T (e.g., assigned to its loopback) 🌸
N steers the transit packets P1 and P2 into an SRv6 Policy with a Source Address T and a segment list <S1, S2, S3> 🧚
the H.Encaps encapsulation behavior goes like this:
S01. Push an IPv6 header with its own SRH
S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
in the segment list
S03. Set outer Payload Length, Traffic Class, Hop Limit, and
Flow Label fields
S04. Set the outer Next Header value
S05. Decrement inner IPv6 Hop Limit or IPv4 TTL
S06. Submit the packet to the IPv6 module for transmission to S1Note: S03: As described in [RFC2473] and [RFC6437].
after H.Encaps, P1' and P2' look like this:
(T, S1) (S3, S2, S1; SL=2) (A, B2)(T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
the received packet is encapsulated unmodified (except for the IPv4 TTL or IPv6 Hop Limit, which gets decremented as described in [RFC2473]) 🫶
the H.Encaps behavior is valid for any kind of L3 traffic 💖 it's commonly used for L3VPN with IPv4 and IPv6 deployments, and it may also be used for TI-LFA [SR-TI-LFA] at the Point of Local Repair ✨
the push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV 🦋
5.2. H.Encaps.Red: H.Encaps with Reduced Encapsulation
H.Encaps.Red is an optimization of H.Encaps, and it's giving efficiency 🍓
it reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. the first SID only gets placed in the Destination Address field of the pushed IPv6 header 🌈
after H.Encaps.Red, P1' and P2' look like this:
(T, S1) (S3, S2; SL=2) (A, B2)(T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)
the push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV 💅
5.3. H.Encaps.L2: H.Encaps Applied to Received L2 Frames
H.Encaps.L2 encapsulates a received Ethernet [IEEE.802.3_2018] frame, plus its attached VLAN header if one is present, in an IPv6 packet with an SRH. the Ethernet frame becomes the payload of the new IPv6 packet 🚀
The Next Header field of the SRH MUST be set to 143.
the push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV 🌸
The encapsulating node MUST remove the preamble (if any) and frame check sequence (FCS) from the Ethernet frame upon encapsulation, and the decapsulating node MUST regenerate, as required, the preamble and FCS before forwarding the Ethernet frame.
5.4. H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 Frames
H.Encaps.L2.Red is an optimization of H.Encaps.L2 🧚 same vibe as H.Encaps.Red, just for L2 frames.
it reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. the first SID is only placed in the Destination Address field of the pushed IPv6 header 🫧
the push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV 💜
6. Counters 📊
okay bestie, so a node that supports this doc SHOULD keep a pair of traffic counters per local SID entry 🔢, one for packets and one for bytes. They only count traffic that matched that SID AND got processed successfully. So packets that generate ICMP Error Messages or get dropped? Not counted 🙅♀️. Getting those numbers out through MIB, NETCONF/YANG, or any other data structure is out of scope for this document, so that's a whole other vibe 💅
7. Flow-Based Hash Computation 🌊
when a flow-based selection within a set needs to happen, the IPv6 Source Address, the IPv6 Destination Address, and the IPv6 Flow Label of the outer IPv6 header MUST be included in the flow-based hash 🔑. Non-negotiable, periodt 💅
This may occur in any of the following scenarios:
- A FIB lookup is performed and multiple ECMP paths exist to the updated destination address.
- End.X, End.DX4, or End.DX6 is bound to an array of adjacencies.
- The packet is steered in an SR Policy whose selected path has multiple SID lists.
Additionally, any transit router in an SRv6 domain includes the outer flow label in its ECMP flow-based hash [RFC6437]. Even the transit routers are getting in on the flow label action 🧚
8. Control Plane 🎛️
In an SDN environment, one expects the controller to explicitly provision the SIDs and/or discover them as part of a service discovery function. Applications sitting on top of the controller could then discover the required SIDs and combine them to form a distributed network program 🧩
The concept of "SRv6 Network Programming" refers to the capability of an application to encode any complex program as a set of individual functions distributed through the network. Some functions relate to underlay SLA, others to overlay/tenant, and others to complex applications residing in VMs and containers. It's giving distributed superpower ✨
While not necessary for an SDN control plane, the remainder of this section provides a high-level illustrative overview of how control-plane protocols may be involved with SRv6. Their specification is outside the scope of this document 📝
8.1. IGP 🗺️
The End, End.T, and End.X SIDs express topological behaviors and hence are expected to be signaled in the IGP together with the flavors PSP, USP, and USD. The IGP should also advertise the Maximum SID Depth (MSD) capability of the node for each type of SRv6 operation — in particular, the SR source (e.g., H.Encaps), intermediate endpoint (e.g., End and End.X), and final endpoint (e.g., End.DX4 and End.DT6) behaviors. These capabilities are factored in by an SR source node (or a controller) during the SR Policy computation 🧮
The presence of SIDs in the IGP does not imply any routing semantics to the addresses represented by these SIDs. The routing reachability to an IPv6 address is solely governed by the non-SID-related IGP prefix reachability information that includes locators. Routing is neither governed nor influenced in any way by a SID advertisement in the IGP. So a SID showing up in the IGP is NOT a routing vibe, not me 🙅♀️
These SIDs provide important topological behaviors for the IGP to build Fast Reroute (FRR) solutions based on TI-LFA [SR-TI-LFA] and for TE processes relying on an IGP topology database to build SR Policies 🚀
8.2. BGP-LS 🛰️
BGP-LS provides the functionality for topology discovery that includes the SRv6 capabilities of the nodes, their locators, and locally instantiated SIDs. This enables controllers or applications to build an inter-domain topology that can be used for computation of SR Policies using the SRv6 SIDs 💖
8.3. BGP IP/VPN/EVPN 🌐
The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, End.DT2U, and End.DT2M SIDs can be signaled in BGP.
In some scenarios, an egress PE advertising a VPN route might wish to abstract the specific behavior bound to the SID from the ingress PE and other routers in the network. In such case, the SID may be advertised using the Opaque SRv6 Endpoint Behavior codepoint defined in Table 6. The details of such control-plane signaling mechanisms are out of the scope of this document 🎀
8.4. Summary 📋
The following table summarizes which SID behaviors may be signaled in which control-plane protocol.
+=======================+=====+========+=================+
| | IGP | BGP-LS | BGP IP/VPN/EVPN |
+=======================+=====+========+=================+
| End (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.X (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.T (PSP, USP, USD) | X | X | |
+-----------------------+-----+--------+-----------------+
| End.DX6 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX4 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT6 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT4 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT46 | X | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX2 | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DX2V | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT2U | | X | X |
+-----------------------+-----+--------+-----------------+
| End.DT2M | | X | X |
+-----------------------+-----+--------+-----------------+
| End.B6.Encaps | | X | |
+-----------------------+-----+--------+-----------------+
| End.B6.Encaps.Red | | X | |
+-----------------------+-----+--------+-----------------+
| End.B6.BM | | X | |
+-----------------------+-----+--------+-----------------+ Table 3: SRv6 Locally Instantiated SIDs SignalingThe following table summarizes which SR Policy Headend capabilities may be signaled in which control-plane protocol.
+=================+=====+========+=================+
| | IGP | BGP-LS | BGP IP/VPN/EVPN |
+=================+=====+========+=================+
| H.Encaps | X | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.Red | X | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.L2 | | X | |
+-----------------+-----+--------+-----------------+
| H.Encaps.L2.Red | | X | |
+-----------------+-----+--------+-----------------+ Table 4: SRv6 Policy Headend Behaviors SignalingThe previous table describes generic capabilities. It does not describe specific instantiated SR Policies.
For example, a BGP-LS advertisement of H.Encaps behavior would describe the capability of node N to perform H.Encaps behavior. Specifically, it would describe how many SIDs could be pushed by N without significant performance degradation 📊
As a reminder, an SR Policy is always assigned a Binding SID [RFC8402]. Binding SIDs are also advertised in BGP-LS as shown in Table 3. Hence, Table 4 only focuses on the generic capabilities related to H.Encaps 💜
9. Security Considerations 🔐
Buckle up, this section is serious business 😭
The security considerations for Segment Routing are discussed in [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model and the requirements for securing the SR Domain. The security considerations of [RFC8754] also cover topics such as attack vectors and their mitigation mechanisms that also apply the behaviors introduced in this document. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust. Having such a well-defined trust boundary is necessary in order to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services.
Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and systems (as illustrated in Section 5.1 of [RFC8754]), can provide the clear distinction between internal and external address space that is required to maintain the integrity and security of the SRv6 Domain. So be careful with those addresses, bestie 🫶
Additionally, [RFC8754] defines a Hashed Message Authentication Code (HMAC) TLV permitting SR Segment Endpoint Nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, regardless of the number of segments in the segment list. When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in Section 2.1.2.1 of [RFC8754] 🛡️
This document introduces SRv6 Endpoint and SR Policy Headend behaviors for implementation on SRv6-capable nodes in the network. The definition of the SR Policy Headend should be consistent with the specific behavior used and any local configuration (as specified in Section 4.1.1). As such, this document does not introduce any new security considerations 🎀
The SID behaviors specified in this document have the same HMAC TLV handling and mutability properties with regard to the Flags, Tag, and Segment List field as the SID behavior specified in [RFC8754] ✨
10. IANA Considerations 🧾
10.1. Ethernet Next Header Type 🌸
IANA has allocated "Ethernet" (value 143) in the "Assigned Internet Protocol Numbers" registry (see <https://www.iana.org/assignments/protocol-numbers/>). Value 143 in the Next Header field of an IPv6 header or any extension header indicates that the payload is an Ethernet frame [IEEE.802.3_2018] 🧚
10.2. SRv6 Endpoint Behaviors Registry 📚
IANA has created a new top-level registry called "Segment Routing" (see <https://www.iana.org/assignments/segment-routing/>). This registry serves as a top-level registry for all Segment Routing subregistries.
Additionally, IANA has created a new subregistry called "SRv6 Endpoint Behaviors" under the top-level "Segment Routing" registry. This subregistry maintains 16-bit identifiers for the SRv6 Endpoint behaviors. This registry is established to provide consistency for control-plane protocols that need to refer to these behaviors. These values are not encoded in the function bits within a SID 🔥
10.2.1. Registration Procedures
Okay so bestie, the registry range is 0-65535 (0x0000-0xFFFF) 🎀 and here's how each chunk gets handled, no cap 💅:
+=============+===============+=========================+===========+
| Range | Range (Hex) | Registration | Note |
| | | Procedures | |
+=============+===============+=========================+===========+
| 0 | 0x0000 | Reserved | Not to be |
| | | | allocated |
+-------------+---------------+-------------------------+-----------+
| 1-32767 | 0x0001-0x7FFF | First Come | |
| | | First Served | |
+-------------+---------------+-------------------------+-----------+
| 32768-34815 | 0x8000-0x87FF | Private Use | |
+-------------+---------------+-------------------------+-----------+
| 34816-65534 | 0x8800-0xFFFE | Reserved | |
+-------------+---------------+-------------------------+-----------+
| 65535 | 0xFFFF | Reserved | Opaque |
+-------------+---------------+-------------------------+-----------+Table 5: Registration Procedures ✨
10.2.2. Initial Registrations
Now the starter pack 🧚 for this subregistry, the initial registrations are:
+=============+===============+=========================+===========+
| Value | Hex | Endpoint Behavior | Reference |
+=============+===============+=========================+===========+
| 0 | 0x0000 | Reserved | |
+-------------+---------------+-------------------------+-----------+
| 1 | 0x0001 | End | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 2 | 0x0002 | End with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 3 | 0x0003 | End with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 4 | 0x0004 | End with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 5 | 0x0005 | End.X | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 6 | 0x0006 | End.X with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 7 | 0x0007 | End.X with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 8 | 0x0008 | End.X with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 9 | 0x0009 | End.T | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 10 | 0x000A | End.T with PSP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 11 | 0x000B | End.T with USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 12 | 0x000C | End.T with PSP & USP | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 13 | 0x000D | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 14 | 0x000E | End.B6.Encaps | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 15 | 0x000F | End.BM | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 16 | 0x0010 | End.DX6 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 17 | 0x0011 | End.DX4 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 18 | 0x0012 | End.DT6 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 19 | 0x0013 | End.DT4 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 20 | 0x0014 | End.DT46 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 21 | 0x0015 | End.DX2 | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 22 | 0x0016 | End.DX2V | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 23 | 0x0017 | End.DT2U | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 24 | 0x0018 | End.DT2M | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 25 | 0x0019 | Reserved | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 26 | 0x001A | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 27 | 0x001B | End.B6.Encaps.Red | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 28 | 0x001C | End with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 29 | 0x001D | End with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 30 | 0x001E | End with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 31 | 0x001F | End with PSP, USP & | RFC 8986 |
| | | USD | |
+-------------+---------------+-------------------------+-----------+
| 32 | 0x0020 | End.X with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 33 | 0x0021 | End.X with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 34 | 0x0022 | End.X with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 35 | 0x0023 | End.X with PSP, USP | RFC 8986 |
| | | & USD | |
+-------------+---------------+-------------------------+-----------+
| 36 | 0x0024 | End.T with USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 37 | 0x0025 | End.T with PSP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 38 | 0x0026 | End.T with USP & USD | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 39 | 0x0027 | End.T with PSP, USP | RFC 8986 |
| | | & USD | |
+-------------+---------------+-------------------------+-----------+
| 40-32766 | 0x0028-0x7FFE | Unassigned | |
+-------------+---------------+-------------------------+-----------+
| 32767 | 0x7FFF | The SID defined in | RFC 8986, |
| | | RFC 8754 | RFC 8754 |
+-------------+---------------+-------------------------+-----------+
| 32768-34815 | 0x8000-0x87FF | Reserved for Private | RFC 8986 |
| | | Use | |
+-------------+---------------+-------------------------+-----------+
| 34816-65534 | 0x8800-0xFFFE | Reserved | RFC 8986 |
+-------------+---------------+-------------------------+-----------+
| 65535 | 0xFFFF | Opaque | RFC 8986 |
+-------------+---------------+-------------------------+-----------+Table 6: Initial Registrations 🦋
11. References 📚
11.1. Normative References
Here are the normative refs, the must-reads 💜:
[IEEE.802.3_2018]
IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018,
DOI 10.1109/IEEESTD.2018.8457469, 31 August 2018,
<https://ieeexplore.ieee.org/document/8457469>.
[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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[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>.11.2. Informative References 📚
okay bestie, this is the background reading shelf 🧚 these are the papers behind the whole vibe, and they're worth a skim if you want the lore ✨
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, https://www.rfc-editor.org/info/rfc4193.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, https://www.rfc-editor.org/info/rfc4364.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, https://www.rfc-editor.org/info/rfc4664.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, https://www.rfc-editor.org/info/rfc4761.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, https://www.rfc-editor.org/info/rfc4762.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, https://www.rfc-editor.org/info/rfc7432.
[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.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, https://www.rfc-editor.org/info/rfc8214.
[RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, January 2018, https://www.rfc-editor.org/info/rfc8317.
[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-06, 1 February 2021, https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-06.
[SRV6-NET-PGM-ILLUST] Filsfils, C., Camarillo, P., Ed., Li, Z., Matsushima, S., Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and J. Leddy, "Illustrations for SRv6 Network Programming", Work in Progress, Internet-Draft, draft-filsfils-spring-srv6-net-pgm-illustration-03, 25 September 2020, https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-illustration-03.
Acknowledgements 🫶
the authors wanna give a huge shoutout to Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, Jisu Bhattacharya, Saleem Hafeez, and Brian Carpenter 💖 literally the whole squad, no notes 👑
Contributors 💜
these are the people who put in the work on the document itself 💅 here are their details, exactly as listed:
Daniel Bernier
Bell Canada
Canada
Email: daniel.bernier@bell.ca
Dirk Steinberg
Lapishills Consulting Limited
Cyprus
Email: dirk@lapishills.com
Robert Raszuk
Bloomberg LP
United States of America
Email: robert@raszuk.net
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com
Hani Elmalky
Google
United States of America
Email: helmalky@google.com
Prem Jonnalagadda
Barefoot Networks
United States of America
Email: prem@barefootnetworks.com
Milad Sharif
SambaNova Systems
United States of America
Email: milad.sharif@sambanova.ai
David Lebrun
Google
Belgium
Email: dlebrun@google.com
Stefano Salsano
Universita di Roma "Tor Vergata"
Italy
Email: stefano.salsano@uniroma2.it
Ahmed AbdelSalam
Gran Sasso Science Institute
Italy
Email: ahmed.abdelsalam@gssi.it
Gaurav Naik
Drexel University
United States of America
Email: gn@drexel.edu
Arthi Ayyangar
Arrcus, Inc
United States of America
Email: arthi@arrcus.com
Satish Mynam
Arrcus, Inc
United States of America
Email: satishm@arrcus.com
Wim Henderickx
Nokia
Belgium
Email: wim.henderickx@nokia.com
Shaowen Ma
Juniper
Singapore
Email: mashao@juniper.net
Ahmed Bashandy
Individual
United States of America
Email: abashandy.ietf@gmail.com
Francois Clad
Cisco Systems, Inc.
France
Email: fclad@cisco.com
Kamran Raza
Cisco Systems, Inc.
Canada
Email: skraza@cisco.com
Darren Dukes
Cisco Systems, Inc.
Canada
Email: ddukes@cisco.com
Patrice Brissete
Cisco Systems, Inc.
Canada
Email: pbrisset@cisco.com
Zafar Ali
Cisco Systems, Inc.
United States of America
Email: zali@cisco.com
Ketan Talaulikar
Cisco Systems, Inc.
India
Email: ketant@cisco.comAuthors' Addresses 🦋
and last but definitely not least, the authors' contact details, copied exactly 🌸
Clarence Filsfils (editor)
Cisco Systems, Inc.
Belgium
Email: cf@cisco.com
Pablo Camarillo Garvia (editor)
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
John Leddy
Akamai Technologies
United States of America
Email: john@leddy.net
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca
Satoru Matsushima
SoftBank
Japan
Email: satoru.matsushima@g.softbank.co.jp
Zhenbin Li
Huawei Technologies
China
Email: lizhenbin@huawei.com📦 where this page comes from
- ietf: rfc8986 2021-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms