RFC 9252
BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) 💖
Okay bestie, this is RFC 9252 🎀, a Standards Track doc from the Internet Engineering Task Force (IETF), published July 2022 with ISSN 2070-1721. The editors are G. Dawra and K. Talaulikar (both marked Ed.), from LinkedIn and Cisco Systems. The rest of the squad is R. Raszuk (NTT Network Innovations), B. Decraene (Orange), S. Zhuang (Huawei Technologies), and J. Rabadan (Nokia) 👑. The title block lists no Obsoletes or Updates entries.
Abstract 🌸
This doc lays out the procedures and messages for SRv6-based BGP services 🦋. That covers Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432) ✨.
Status of This Memo 📜
This is an Internet Standards Track document.
This doc is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 💅.
Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc9252 🔥.
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) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Revised BSD License 💀.
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
2. SRv6 Services TLVs
3. SRv6 Service Sub-TLVs
3.1. SRv6 SID Information Sub-TLV
3.2. SRv6 Service Data Sub-Sub-TLVs
3.2.1. SRv6 SID Structure Sub-Sub-TLV
4. Encoding SRv6 SID Information
5. BGP-Based L3 Service over SRv6
5.1. IPv4 VPN over SRv6 Core
5.2. IPv6 VPN over SRv6 Core
5.3. Global IPv4 over SRv6 Core
5.4. Global IPv6 over SRv6 Core
6. BGP-Based Ethernet VPN (EVPN) over SRv6
6.1. Ethernet Auto-Discovery Route over SRv6 Core
6.1.1. Ethernet A-D per ES Route
6.1.2. Ethernet A-D per EVI Route
6.2. MAC/IP Advertisement Route over SRv6 Core
6.2.1. MAC/IP Advertisement Route with MAC Only
6.2.2. MAC/IP Advertisement Route with MAC+IP
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core
6.4. Ethernet Segment Route over SRv6 Core
6.5. IP Prefix Route over SRv6 Core
6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6
Core
7. Error Handling
8. IANA Considerations
8.1. BGP Prefix-SID TLV Types Registry
8.2. SRv6 Service Sub-TLV Types Registry
8.3. SRv6 Service Data Sub-Sub-TLV Types Registry
8.4. BGP SRv6 Service SID Flags Registry
8.5. SAFI Values Registry
9. Security Considerations
9.1. Considerations Related to BGP Sessions
9.2. Considerations Related to BGP Services
9.3. Considerations Related to SR over IPv6 Data Plane
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
SRv6 means Segment Routing running on the IPv6 data plane [RFC8402] 🧚.
BGP is how the reachability of prefixes for a particular service gets advertised, going from an egress Provider Edge (PE) to ingress PE nodes 🦋.
SRv6-based BGP services are Layer 3 (L3) and Layer 2 (L2) overlay services where BGP is the control plane and SRv6 is the data plane 💖. This doc lays out the procedures and messages for them, including L3VPN, EVPN, and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4364] and "BGP MPLS-Based Ethernet VPN" [RFC7432] 🌈.
An SRv6 SID is an SRv6 Segment Identifier, as defined in [RFC8402] 🎀.
An SRv6 Service SID is an SRv6 SID tied to one of the service-specific SRv6 Endpoint Behaviors on the advertising PE router 👑. Examples (not an exhaustive list) are End.DT, which looks things up in the Virtual Routing and Forwarding (VRF) table, and End.DX, which cross-connects to a next hop, both for L3VPN service, as defined in [RFC8986] 💅. This doc describes how existing BGP messages between PEs can carry SRv6 Service SIDs to interconnect PEs and form VPNs 🫶.
For best-effort SRv6 service, the egress PE signals an SRv6 Service SID along with the BGP overlay service route 🌸. The ingress PE wraps the payload in an outer IPv6 header whose destination address is the SRv6 Service SID the egress PE gave it. The underlay between the PEs only needs plain IPv6 forwarding [RFC8200] 🍓.
For SRv6 service paired with an underlay Service Level Agreement (SLA) from ingress PE to egress PE, the egress PE colors the overlay service route with a Color Extended Community [RFC9012], which steers flows for those routes, as specified in Section 8 of [SEGMENT-ROUTING-POLICY] 🔥. The ingress PE wraps the payload packet in an outer IPv6 header carrying the SR Policy segment list tied to that SLA, plus the SRv6 Service SID for the route, using the Segment Routing Header (SRH) [RFC8754] 💜. The underlay nodes whose SRv6 SIDs are part of the SRH segment list MUST support the SRv6 data plane 🚨.
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. SRv6 Services TLVs 🌈
This doc extends the BGP Prefix-SID attribute [RFC8669] so it can carry SRv6 SIDs and their associated info for the BGP address families listed later in this section 💖.
The SRv6 Service TLVs are two new TLVs under the BGP Prefix-SID attribute, built to signal SRv6 SIDs for L3 and L2 services 🎀.
SRv6 L3 Service TLV: this one encodes Service SID info for SRv6-based L3 services. It does the same job an MPLS label does when it comes with a Layer 3 service route, as defined in [RFC4364], [RFC4659], [RFC8950], and [RFC9136] ✨. Some SRv6 Endpoint Behaviors it can encode are (but not limited to) End.DX4, End.DT4, End.DX6, End.DT6, and End.DT46 🧚.
SRv6 L2 Service TLV: this one encodes Service SID info for SRv6-based L2 services. It matches what an MPLS label does for Ethernet VPN (EVPN) Route Types for Layer 2 services, as defined in [RFC7432] 🦋. Some SRv6 Endpoint Behaviors it can encode are (but not limited to) End.DX2, End.DX2V, End.DT2U, and End.DT2M 💅.
When an egress PE has BGP Services turned on over the SRv6 data plane, it signals one or more SRv6 Service SIDs inside SRv6 Service TLV(s), which live inside the BGP Prefix-SID attribute attached to Multiprotocol BGP (MP-BGP) Network Layer Reachability Information (NLRI). The NLRI types are defined in [RFC4760], [RFC4659], [RFC8950], [RFC7432], [RFC4364], and [RFC9136], wherever they apply, as described in Sections 5 and 6 🌸.
Support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6 is out of scope for this doc 🙈.
Here's the layout of the SRv6 Service TLVs inside the BGP Prefix-SID attribute 👀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: SRv6 Service TLVs
TLV Type (1 octet): this field gets a value from IANA's "BGP Prefix-SID TLV Types" subregistry. It's set to 5 for the SRv6 L3 Service TLV and to 6 for the SRv6 L2 Service TLV 🍓.
TLV Length (2 octets): this field gives the total length, in octets, of the TLV Value 📏.
RESERVED (1 octet): this field is reserved. It MUST be set to 0 by the sender and ignored by the receiver 🔒.
SRv6 Service Sub-TLVs (variable): this field holds SRv6 service-related info, encoded as an unordered list of Sub-TLVs whose format is described below 🧩.
A BGP speaker that receives a route with the BGP Prefix-SID attribute carrying one or more SRv6 Service TLVs follows these rules when it advertises that route to other peers 🚦:
- If the BGP next hop is unchanged during the advertisement, the SRv6 Service TLVs, including any unrecognized Types of Sub-TLV and Sub-Sub-TLV, SHOULD be propagated further. Also, all Reserved fields in the TLV, Sub-TLV, or Sub-Sub-TLV MUST be propagated unchanged 💖.
- If the BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs SHOULD be updated with the locally allocated SRv6 SID information. Any received Sub-TLVs and Sub-Sub-TLVs that are unrecognized MUST be removed 🧹.
3. SRv6 Service Sub-TLVs 💅
Here's the format of a single SRv6 Service Sub-TLV 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | SRv6 Service //
| Sub-TLV | Sub-TLV | Sub-TLV //
| Type | Length | Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: SRv6 Service Sub-TLVs
SRv6 Service Sub-TLV Type (1 octet): this field says what kind of SRv6 service info it is. It gets a value from IANA's "SRv6 Service Sub-TLV Types" subregistry 🔖.
SRv6 Service Sub-TLV Length (2 octets): this field gives the total length, in octets, of the Sub-TLV Value field 📐.
SRv6 Service Sub-TLV Value (variable): this field holds data specific to the Sub-TLV Type. Along with fixed-length data, it carries other properties of the SRv6 service, encoded as a set of SRv6 Service Data Sub-Sub-TLVs. Their format is described in Section 3.2 below 🌈.
3.1. SRv6 SID Information Sub-TLV ✨
okay so bestie, this is the sub-TLV that carries one single SRv6 SID plus all its juicy properties 💅 It's giving "one SID, many vibes." Here's how it's laid out:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | |
| Sub-TLV | Sub-TLV | |
| Type=1 | Length | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Value (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SRv6 SID Information Sub-TLVHere's the field rundown, slowly, because every bit matters 🎀
- SRv6 Service Sub-TLV Type (1 octet): set to
1to say "hey, this is the SRv6 SID Information Sub-TLV" 🦋 - SRv6 Service Sub-TLV Length (2 octets): the total length, in octets, of the Value field of the Sub-TLV 📏
- RESERVED1 (1 octet): this field MUST be set to
0by the sender and ignored by the receiver 🙈 - SRv6 SID Value (16 octets): encodes an SRv6 SID, as defined in [RFC8986] 💖
- SRv6 Service SID Flags (1 octet): encodes SRv6 Service SID Flags, and none are currently defined 🌸 It MUST be set to
0by the sender, and any unknown flags MUST be ignored by the receiver. - SRv6 Endpoint Behavior (2 octets): encodes the SRv6 Endpoint Behavior codepoint associated with the SRv6 SID. The codepoints come from IANA's "SRv6 Endpoint Behaviors" subregistry under the "Segment Routing" registry, introduced by [RFC8986] 🧚 The opaque SRv6 Endpoint Behavior (i.e., value
0xFFFF) MAY be used when the advertising router wants to hide the actual behavior of its locally instantiated SRv6 SID 🫶 - RESERVED2 (1 octet): this field MUST be set to
0by the sender and ignored by the receiver 🙈 - SRv6 Service Data Sub-Sub-TLV Value (variable): used to advertise properties of the SRv6 SID, encoded as a set of SRv6 Service Data Sub-Sub-TLVs 👑
The choice of SRv6 Endpoint Behavior is entirely up to whoever originates the advertisement, no cap 💅 Sections 5 and 6 list the behaviors normally expected for specific route advertisements, but receiving other behaviors (like new ones introduced in the future) is not considered an error 🌈 An unrecognized SRv6 Endpoint Behavior MUST NOT be considered invalid by the receiver, except for behaviors that involve arguments (see Section 3.2.1 for argument validation details) 😭 An implementation MAY log a rate-limited warning when it gets an unexpected behavior ⭐
When there are multiple SRv6 SID Information Sub-TLVs, the ingress PE SHOULD use the SRv6 SID from the first instance of the Sub-TLV. An implementation MAY provide a local policy to override this selection 🔥
3.2. SRv6 Service Data Sub-Sub-TLVs 🍓
Here's the format of the SRv6 Service Data Sub-Sub-TLV, bestie 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Data | Sub-Sub-TLV Length |Sub-Sub TLV //
| Sub-Sub-TLV | | Value //
| Type | | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Service Data Sub-Sub-TLVs- SRv6 Service Data Sub-Sub-TLV Type (1 octet): identifies the type of Sub-Sub-TLV, assigned from IANA's "SRv6 Service Data Sub-Sub-TLV Types" subregistry 🌷
- SRv6 Service Data Sub-Sub-TLV Length (2 octets): the total length, in octets, of the Sub-Sub-TLV Value field 📐
- SRv6 Service Data Sub-Sub-TLV Value (variable): data specific to the Sub-Sub-TLV Type 💜
3.2.1. SRv6 SID Structure Sub-Sub-TLV 🧁
okay this one is the lengths-of-everything sub-sub-TLV, and it's SO important 🤓 Type 1 is assigned for the SRv6 SID Structure Sub-Sub-TLV. It advertises the lengths of the individual parts of the SRv6 SID, as defined in [RFC8986]. The terms Locator Block and Locator Node line up with the B and N parts of the SRv6 Locator defined in Section 3.1 of [RFC8986]. It's carried as a Sub-Sub-TLV inside the SRv6 SID Information Sub-TLV ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | Locator Block |
| Data Sub-Sub | Data Sub-Sub-TLV | Length |
| -TLV Type=1 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Node | Function | Argument | Transposition |
| Length | Length | Length | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transposition |
| Offset |
+-+-+-+-+-+-+-+-+
Figure 5: SRv6 SID Structure Sub-Sub-TLVThe fields, one by one 💖
- SRv6 Service Data Sub-Sub-TLV Type (1 octet): set to
1to represent the SRv6 SID Structure Sub-Sub-TLV 🦋 - SRv6 Service Data Sub-Sub-TLV Length (2 octets): contains a total length of
6octets 📏 - Locator Block Length (1 octet): the length of the SRv6 SID Locator Block, in bits 🌸
- Locator Node Length (1 octet): the length of the SRv6 SID Locator Node, in bits 🌸
- Function Length (1 octet): the length of the SRv6 SID Function, in bits 🧚
- Argument Length (1 octet): the length of the SRv6 SID Argument, in bits 🧚
- Transposition Length (1 octet): the size in bits of the part of the SID that has been transposed (or shifted) into an MPLS Label field 🫶
- Transposition Offset (1 octet): the offset position in bits of the part of the SID that has been transposed (or shifted) into an MPLS Label field 🫶
Section 4 describes how to signal the SRv6 Service SID by transposing a variable part of the SRv6 SID value and carrying that part in existing MPLS Label fields. This packs service prefix NLRIs more efficiently into BGP update messages ✨ The SRv6 SID Structure Sub-Sub-TLV carries the right length fields when the SRv6 Service SID is signaled in split parts, so the receiver can put the SID back together accurately 💅
Transposition Offset gives the bit position, and Transposition Length gives the number of bits taken out of the SRv6 SID value and encoded in the MPLS Label field. The bits that were shifted out MUST be set to 0 in the SID value 🙈
A Transposition Length of 0 means nothing is transposed, and the entire SRv6 SID value is encoded in the SID Information Sub-TLV. In that case, the Transposition Offset MUST be set to 0 🌈
The size of the MPLS Label field limits how many bits can be transposed from the SRv6 SID value into it. For example, the MPLS Label field is 20 bits in [RFC4364] and [RFC8277], and 24 bits in [RFC7432] 🎀
As defined in [RFC8986], the sum of the Locator Block Length (LBL), Locator Node Length (LNL), Function Length (FL), and Argument Length (AL) fields MUST be less than or equal to 128 and greater than the sum of Transposition Offset and Transposition Length 🔥
Here's an example, bestie 🧚 Say the sum of the Locator Block and Locator Node parts is 64. For an SRv6 SID where the entire 16-bit Function part is transposed, the Transposition Offset is set to 64 and the Transposition Length is set to 16. Meanwhile, for an SRv6 SID whose FL is 24 bits where only the lower-order 20 bits get transposed (because of the MPLS Label field size limit), the Transposition Offset is set to 68 and the Transposition Length is set to 20 💜
BGP speakers that don't support this specification may misread, on receiving an SRv6-based BGP service route update, the part of the SRv6 SID encoded in an MPLS Label field as MPLS label values for MPLS-based services 😭 Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis 🛑 The details of deployment designs and implementation options are outside the scope of this document 🌸
Arguments are generally only applicable to SIDs of specific SRv6 Endpoint Behaviors (e.g., End.DT2M), so the AL MUST be set to 0 for SIDs where the Argument isn't applicable 🙈 A receiver can't validate arguments for SRv6 Endpoint Behaviors it doesn't know, so it MUST ignore SRv6 SIDs with arguments (indicated by a non-zero AL) that have unknown SRv6 Endpoint Behaviors 🫠 For SIDs corresponding to a known SRv6 Endpoint Behavior, a receiver MUST validate that the AL is consistent with that specific SRv6 Endpoint Behavior definition 💅✨
4. Encoding SRv6 SID Information 💅✨
okay bestie, so the SRv6 Service SID(s) for a BGP service prefix gets carried in the SRv6 Services TLVs of the BGP Prefix-SID attribute 🎀
now here's the tea 🫖. for some BGP services, like L3VPN where you do per-VRF SID allocation (aka End.DT4 or End.DT6 behaviors), the same SID gets shared across multiple NLRIs. so it packs super efficiently 🧚 but for other services, like EVPN VPWS where you need per-PW SID allocation (End.DX2 behavior), every NLRI gets its own unique SID, and that means the packing is kinda inefficient 😭
so to get efficient packing, this doc lets you do either 1) encode the whole SRv6 Service SID in the SRv6 Services TLVs, or 2) encode only the common part of the SID (like the Locator) in the SRv6 Services TLVs and put the variable part (like the Function or Argument parts) into the existing label fields for that service encoding 🦋. the second option is called the Transposition Scheme 💜. the SRv6 SID Structure Sub-Sub-TLV tells you the sizes of the parts of the SID, and also where the variable part starts (the Transposition Offset) and how long it is (the Transposition Length) 🍓. using the Transposition Scheme is RECOMMENDED for the specific service encodings that allow it, which you'll see more about in Sections 5 and 6 ✨
example time 🙈. for the EVPN VPWS service prefix in Section 6.1.2, the Function part of the SRv6 SID goes in the MPLS Label field of the NLRI, and the SID value in the SRv6 Services TLV only carries the Locator part, with the SRv6 SID Structure Sub-Sub-TLV. that Sub-Sub-TLV defines the lengths of the Locator Block, Locator Node, and Function parts (Arguments aren't applicable for End.DX2, so skip those 🙅♀️). Transposition Offset is the bit position, and Transposition Length is how many bits get taken out of the SID and put into the label field 💖
another one 👑. for the EVPN Ethernet Auto-Discovery (A-D) per Ethernet Segment (ES) route in Section 6.1.1, only the Argument of the SID needs to be signaled 🌸. this Argument part MAY be transposed in the Ethernet Segment Identifier (ESI) Label field of the ESI Label extended community, and the SID value in the SRv6 Services TLV is set to 0, along with including the SRv6 SID Structure Sub-Sub-TLV 🫶. that Sub-Sub-TLV defines the lengths of Locator Block, Locator Node, Function, and Argument parts. the offset and length of the Argument part that got moved into the label field are set in the transposition offset and length of the SID Structure TLV 🔥. then the receiving router can put the whole SRv6 Service SID back together (e.g., for End.DT2M behavior), by slotting the label value from the ESI Label field of the Ethernet A-D per ES route into the correct transposition offset and length in the SRv6 SID, with the End.DT2M behavior received for an EVPN Route Type 3 value 🌈
5. BGP-Based L3 Service over SRv6 🌍
okay so BGP egress nodes (egress PEs) advertise a set of reachable prefixes 🦋. standard BGP update propagation schemes [RFC4271] are used to spread these prefixes, and they may use route reflectors [RFC4456] 🧚. BGP ingress nodes (ingress PEs) receive these advertisements and may add the prefix to the RIB in an appropriate VRF 💅
egress PEs that support SRv6-based L3 services advertise overlay service prefixes along with a Service SID, which is enclosed in an SRv6 L3 Service TLV within the BGP Prefix-SID attribute 🎀. this TLV does two jobs ✨. first, it tells everyone the egress PE supports SRv6 overlay, and the BGP ingress PE that gets this route MUST perform IPv6 encapsulation and insert an SRH [RFC8754] when required 👑. second, it tells you the value of the Service SID to use in the encapsulation 💜
so the Service SID only has local significance at the egress PE 🫶, where it may be allocated or configured on a per-Customer-Edge (CE) or per-VRF basis. in practice, the SID may encode a cross-connect to a specific address family table (End.DT) or a next hop / interface (End.DX), as defined in [RFC8986] 🌸
the SRv6 Service SID SHOULD be routable (see Section 3.3 of [RFC8986]) within the Autonomous System (AS) of the egress PE 🔥. it does a double shift 💖: it gives reachability between ingress PE and egress PE, and it also encodes the SRv6 Endpoint Behavior 🙈
when steering for SRv6 services is based on shortest path forwarding (e.g., best effort, or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the egress PE, the ingress PE wraps the IPv4 or IPv6 customer packet in an outer IPv6 header 🦋. it uses the H.Encaps or H.Encaps.Red flavors from [RFC8986], and the destination address is the SRv6 Service SID tied to the related BGP route update 🍓. so the ingress PE MUST do a resolvability check for the SRv6 Service SID before it considers the received prefix for BGP best path computation 🫶. resolvability gets evaluated as per [RFC4271] 🧚. if the SRv6 SID is reachable through more than one forwarding table, local policy decides which table to use 🎀. the result of an SRv6 Service SID resolvability check (e.g., when it's provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE 🌈. the details of those steering mechanisms are outside the scope of this document 🙃
for service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses 💅. that address MAY be covered by the SRv6 Locator the SRv6 Service SID was allocated from 🌟. the BGP next hop is used to track the reachability of the egress PE, based on existing BGP procedures 💖
when the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, steering for service flows is done as described in Section 8 of [SEGMENT-ROUTING-POLICY] 🦋. when the ingress PE figures out (with the help of the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY leave that last SRv6 SID out when steering the service flow ✨. for example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID> 🧚
5.1. IPv4 VPN over SRv6 Core 🌸
the MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN unicast over IPv6 core, as defined in [RFC8950] 💜
the label field of the IPv4-VPN NLRI is encoded as specified in [RFC8277], with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme (Section 4) is used 🎀. otherwise, it's set to Implicit NULL 🙈. when using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL 🔥
the SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV 🫶. the SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46 👑
5.2. IPv6 VPN over SRv6 Core 🦋
the MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN over IPv6 core, as defined in [RFC4659] 🧚
the label field of the IPv6-VPN NLRI is encoded as specified in [RFC8277], with the 20-bit Label Value set to the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme (Section 4) is used 💖. otherwise, it's set to Implicit NULL ✨. when using the Transposition Scheme, the Transposition Length MUST be less than or equal to 20 and less than or equal to the FL 🌈
the SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV 💅. the SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46 🍓
5.3. Global IPv4 over SRv6 Core 🌍
the MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over IPv6 core, as defined in [RFC8950] 🎀
the SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV 🫶. the SRv6 Endpoint Behavior SHOULD be one of these: End.DX4, End.DT4, or End.DT46 🌸
5.4. Global IPv6 over SRv6 Core 💜
the MP_REACH_NLRI over SRv6 core is encoded according to [RFC2545] 🙈
the SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV 🔥. the SRv6 Endpoint Behavior SHOULD be one of these: End.DX6, End.DT6, or End.DT46 👑
6. BGP-Based Ethernet VPN (EVPN) over SRv6 💖
Okay bestie, so [RFC7432] gives us an extendable way to build an EVPN overlay ✨. It mostly focuses on MPLS-based EVPNs, and [RFC8365] stretches it out to IP-based EVPN overlays 🦋. [RFC7432] defines Route Types 1, 2, and 3, which carry prefixes and MPLS Label fields. Those Label fields have a very specific job for MPLS encapsulation of EVPN traffic 🎀. Route Type 5 carrying MPLS label info (so encapsulation info too) for an EVPN is defined in [RFC9136] 💅, and Route Types 6, 7, and 8 come from [RFC9251] 👑.
- Ethernet Auto-Discovery (A-D) route (Route Type 1)
- MAC/IP Advertisement route (Route Type 2)
- Inclusive Multicast Ethernet Tag route (Route Type 3)
- Ethernet Segment route (Route Type 4)
- IP Prefix route (Route Type 5)
- Selective Multicast Ethernet Tag route (Route Type 6)
- Multicast Membership Report Synch route (Route Type 7)
- Multicast Leave Synch route (Route Type 8)
The specs for the other EVPN Route Types are outside the scope of this doc, so we're not going there 🙈.
To support SRv6-based EVPN overlays, one or more SRv6 Service SIDs get advertised with Route Types 1, 2, 3, and 5 🌸. The SRv6 Service SID(s) for each Route Type ride along in SRv6 L3/L2 Service TLVs inside the BGP Prefix-SID attribute. Signaling the SRv6 Service SID(s) does two jobs ✨. First, it tells everyone that the BGP egress device supports SRv6 overlay, so the BGP ingress device that receives this route MUST do IPv6 encapsulation and insert an SRH [RFC8754] when it's needed. Second, it tells you the value of the Service SID(s) to use in the encapsulation 🧚.
The SRv6 Service SID SHOULD be routable (see Section 3.3 of [RFC8986]) within the AS of the egress PE. It's doing double duty here: it gives reachability between the ingress PE and egress PE, and it also encodes the SRv6 Endpoint Behavior 💜.
When steering for SRv6 services is based on shortest path forwarding (like best effort or IGP Flexible Algorithm [IGP-FLEX-ALGO]) to the egress PE, the ingress PE encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 header 📦. It uses the H.Encaps.L2 or H.Encaps.L2.Red flavors from [RFC8986], and the destination address is the SRv6 Service SID tied to the related BGP route update. So the ingress PE MUST do a resolvability check on the SRv6 Service SID before it even considers the received prefix for BGP best path computation 🫶. Resolvability gets evaluated as per [RFC4271]. If the SRv6 SID is reachable through more than one forwarding table, local policy decides which table to use 🗺️. The result of the SRv6 Service SID resolvability check (for example, when it's provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE 🔥. The details of those steering mechanisms are outside the scope of this document 🙈.
For service over SRv6 core, the egress PE sets the BGP next hop to one of its IPv6 addresses 💅. That address MAY be covered by the SRv6 Locator the SRv6 Service SID was allocated from. The BGP next hop is what tracks the reachability of the egress PE, using the existing BGP procedures ✨.
When the BGP route received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, service flows get steered as described in Section 8 of [SEGMENT-ROUTING-POLICY] 🌈. Now here's the cute part 🦋: when the ingress PE figures out (with the help of the SRv6 SID Structure) that the Service SID is in the same SRv6 Locator as the last SRv6 SID (of the egress PE) in the SR Policy segment list, it MAY leave out that last SRv6 SID when steering the service flow. For example, the effective segment list of the SRv6 Policy associated with SID list <S1, S2, S3> would be <S1, S2, S3-Service-SID> 💖.
6.1. Ethernet Auto-Discovery Route over SRv6 Core
Ethernet A-D routes are Route Type 1, as defined in [RFC7432] 🎀. They can be used for split-horizon filtering, fast convergence, and aliasing ⚡. EVPN Route Type 1 is also used in EVPN-VPWS and in EVPN-flexible cross-connect, mostly to advertise point-to-point service IDs 🧁.
Quick reminder, EVPN Route Type 1 is encoded like this 👀:
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| MPLS label (3 octets) |
+-----------------------------------------+
Figure 6: EVPN Route Type 16.1.1. Ethernet A-D per ES Route
The Ethernet A-D per ES route NLRI encoding over SRv6 core is the same as in [RFC7432] 📝.
Here's the vibe for the 24-bit ESI Label field of the ESI Label extended community 🌷. It carries the whole thing or a portion of the Argument part of the SRv6 SID when the ESI filtering approach is used together with the Transposition Scheme of encoding (Section 4). Otherwise it gets set to Implicit NULL in the higher-order 20 bits (so it's 0x000030). Either way, the value goes in all 24 bits. When you're using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24, and less than or equal to the AL 🫶.
A Service SID enclosed in an SRv6 L2 Service TLV inside the BGP Prefix-SID attribute gets advertised along with the A-D route 💌. The SRv6 Endpoint Behavior SHOULD be End.DT2M 💜. When the ESI filtering approach is used, the Service SID signals the Arg.FE2 SID Argument for the applicable End.DT2M behavior [RFC8986] ✨. When the local-bias approach [RFC8365] is used, the Service SID MAY have the value 0 🙈.
6.1.2. Ethernet A-D per EVI Route
The Ethernet A-D per EVPN Instance (EVI) route NLRI encoding over SRv6 core is similar to what [RFC7432] and [RFC8214] describe, with one change 🦋:
MPLS Label: The 24-bit field carries the whole thing or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used. Otherwise it gets set to Implicit NULL in the higher-order 20 bits (so it's 0x000030). Either way, the value goes in all 24 bits. When you're using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24, and less than or equal to the FL 🌸.
A Service SID enclosed in an SRv6 L2 Service TLV inside the BGP Prefix-SID attribute gets advertised along with the A-D route 🎀. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2, End.DX2V, or End.DT2U 💅.
6.2. MAC/IP Advertisement Route over SRv6 Core
EVPN Route Type 2 advertises unicast MAC + IP address reachability through MP-BGP to all the other PEs in a given EVPN instance 🌈.
Quick reminder, EVPN Route Type 2 is encoded like this 👀:
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| MAC Address Length (1 octet) |
+-----------------------------------------+
| MAC Address (6 octets) |
+-----------------------------------------+
| IP Address Length (1 octet) |
+-----------------------------------------+
| IP Address (0, 4, or 16 octets) |
+-----------------------------------------+
| MPLS Label1 (3 octets) |
+-----------------------------------------+
| MPLS Label2 (0 or 3 octets) |
+-----------------------------------------+
Figure 7: EVPN Route Type 2NLRI encoding over SRv6 core is similar to [RFC7432], with the following changes 🧚:
MPLS Label1: This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole thing or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used. Otherwise it gets set to Implicit NULL in the higher-order 20 bits (so it's 0x000030). Either way, the value goes in all 24 bits. When you're using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24, and less than or equal to the FL 💖.
MPLS Label2: This is associated with the SRv6 L3 Service TLV. This 24-bit field carries the whole thing or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used. Otherwise it gets set to Implicit NULL in the higher-order 20 bits (so it's 0x000030). Either way, the value goes in all 24 bits. When you're using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24, and less than or equal to the FL ✨.
Service SIDs enclosed in the SRv6 L2 Service TLV, and optionally in the SRv6 L3 Service TLV, inside the BGP Prefix-SID attribute get advertised along with the MAC/IP Advertisement route 🌷.
Here are the different types of Route Type 2 advertisements we're going to look at 👑.
6.2.1. MAC/IP Advertisement Route with MAC Only
MPLS Label1: This is associated with the SRv6 L2 Service TLV. This 24-bit field carries the whole thing or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used. Otherwise it gets set to Implicit NULL in the higher-order 20 bits (so it's 0x000030). Either way, the value goes in all 24 bits. When you're using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24, and less than or equal to the FL 🫶.
A Service SID enclosed in an SRv6 L2 Service TLV inside the BGP Prefix-SID attribute gets advertised along with the route 🦋. The SRv6 Endpoint Behavior SHOULD be one of these: End.DX2 or End.DT2U 💅.
6.2.2. MAC/IP Advertisement Route with MAC+IP 💖
okay so MPLS Label1 🦋 is tied to the SRv6 L2 Service TLV. It's a 24-bit field that carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used. If that scheme isn't used, it gets set to Implicit NULL in the higher-order 20 bits, so it reads as 0x000030. Either way, the value is set in all 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
MPLS Label2 🌸 is the same deal, just for the SRv6 L3 Service TLV. It's a 24-bit field with the whole or part of the Function part of the SRv6 SID when the Transposition Scheme (Section 4) is used. Otherwise it's Implicit NULL in the higher-order 20 bits (0x000030), and the value still fills all 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
An L2 Service SID inside an SRv6 L2 Service TLV within the BGP Prefix-SID attribute gets advertised along with the route ✨. An L3 Service SID inside an SRv6 L3 Service TLV within the BGP Prefix-SID attribute MAY also be advertised with the route. The SRv6 Endpoint Behavior SHOULD be one of these: for the L2 Service SID, End.DX2 or End.DT2U; for the L3 Service SID, End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6. 🫶
6.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core 🌈
okay, EVPN Route Type 3 is how you advertise multicast traffic reachability through MP-BGP to all the other PEs in a given EVPN instance 🧚
As a reminder, EVPN Route Type 3 is encoded like this:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
Figure 8: EVPN Route Type 3NLRI encoding over SRv6 core is similar to what's described in [RFC7432] 💅
The P-Multicast Service Interface (PMSI) Tunnel Attribute [RFC6514] is what identifies the Provider tunnel (P-tunnel) used for sending Broadcast, Unknown Unicast, or Multicast (BUM) traffic. Over SRv6 core, the PMSI Tunnel Attribute is encoded like this:
+---------------------------------------+
| Flag (1 octet) |
+---------------------------------------+
| Tunnel Type (1 octet) |
+---------------------------------------+
| MPLS label (3 octets) |
+---------------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------------+
Figure 9: PMSI Tunnel AttributeFlag: This field has a value of 0, as defined per [RFC7432].Tunnel Type: This field is defined per [RFC6514].MPLS label: This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when ingress replication is used and the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set as defined in [RFC6514]. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.Tunnel Identifier: This field is the IP address of egress PE.
A Service SID inside an SRv6 L2 Service TLV within the BGP Prefix-SID attribute gets advertised along with the route. The SRv6 Endpoint Behavior SHOULD be End.DT2M 🍓
- When ESI-based filtering is used for multihoming or Ethernet Tree (E-Tree) procedures, the ESI Filtering Argument (the Arg.FE2 notation introduced in [RFC8986]) of the Service SID carried along with EVPN Route Type 1 SHOULD be merged with the applicable
End.DT2MSID of Route Type 3 advertised by the remote PE by doing a bitwise logical-OR operation to create a single SID on the ingress PE. Details of split-horizon, ESI-based filtering mechanisms for multihoming are described in [RFC7432]. Details of filtering mechanisms for Leaf-originated BUM traffic in EVPN E-Tree services are provided in [RFC8317]. - When "local-bias" is used as the multihoming split-horizon method, the ESI Filtering Argument SHOULD NOT be merged with the corresponding
End.DT2MSID on the ingress PE. Details of the local-bias procedures are described in [RFC8365].
Using multicast trees as P-tunnels is outside the scope of this document. 🙈
6.4. Ethernet Segment Route over SRv6 Core 🎀
As a reminder, an Ethernet Segment route (aka EVPN Route Type 4) is encoded like this:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| Originating Router's IP Address |
| (4 or 16 octets) |
+---------------------------------------+
Figure 10: EVPN Route Type 4NLRI encoding over SRv6 core is similar to what's described in [RFC7432] 🦋
SRv6 Service TLVs within the BGP Prefix-SID attribute are not advertised along with this route. The processing of the route hasn't changed at all -- it's still exactly as described in [RFC7432] ✨
6.5. IP Prefix Route over SRv6 Core 👑
okay so EVPN Route Type 5 is how you advertise IP address reachability through MP-BGP to all the other PEs in a given EVPN instance 🌸 The IP address can be a host IP prefix or any specific subnet.
As a reminder, EVPN Route Type 5 is encoded like this:
+-----------------------------------------+
| RD (8 octets) |
+-----------------------------------------+
| Ethernet Segment Identifier (10 octets)|
+-----------------------------------------+
| Ethernet Tag ID (4 octets) |
+-----------------------------------------+
| IP Prefix Length (1 octet) |
+-----------------------------------------+
| IP Prefix (4 or 16 octets) |
+-----------------------------------------+
| GW IP Address (4 or 16 octets) |
+-----------------------------------------+
| MPLS Label (3 octets) |
+-----------------------------------------+
Figure 11: EVPN Route Type 5NLRI encoding over SRv6 core is similar to what's described in [RFC9136], with this one change:
MPLS Label: This 24-bit field carries the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding (Section 4) is used; otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e., as0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the FL.
The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint Behavior SHOULD be one of these: End.DT4, End.DT6, End.DT46, End.DX4, or End.DX6. 💅
6.6. EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core 🧚
These routes don't need SRv6 Service TLVs to be advertised along with them 🫶 Similar to EVPN Route Type 4, the BGP next hop is equal to the IPv6 address of the egress PE.
7. Error Handling 🚨
In case of any errors encountered while processing SRv6 Service TLVs, the details of the error SHOULD be logged for further analysis 📝
If multiple instances of the SRv6 L3 Service TLV are encountered, all but the first instance MUST be ignored.
If multiple instances of the SRv6 L2 Service TLV are encountered, all but the first instance MUST be ignored.
An SRv6 Service TLV is considered malformed in the following cases:
- The TLV Length is less than 1.
- The TLV Length is inconsistent with the length of the BGP Prefix-SID attribute.
- At least one of the constituent Sub-TLVs is malformed.
An SRv6 Service Sub-TLV is considered malformed in the following case:
- The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.
An SRv6 SID Information Sub-TLV is considered malformed in the following cases:
- The Sub-TLV Length is less than 21.
- The Sub-TLV Length is inconsistent with the length of the enclosing SRv6 Service TLV.
- At least one of the constituent Sub-Sub-TLVs is malformed.
An SRv6 Service Data Sub-Sub-TLV is considered malformed in the following case:
- The Sub-Sub-TLV Length is inconsistent with the length of the enclosing SRv6 service Sub-TLV.
Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because its Type is unrecognized.
Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because of failing any semantic validation of its Value field.
The SRv6 overlay service requires the Service SID for forwarding. The treat-as-withdraw action [RFC7606] MUST be performed when at least one malformed SRv6 Service TLV is present in the BGP Prefix-SID attribute.
⚠️ bestie, this part is serious. The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid when the SID Structure Sub-Sub-TLV transposition length is greater than the number of bits of the label field, or if any of the conditions for the fields of the Sub-Sub-TLV, as specified in Section 3.2.1, is not met. The transposition offset and length MUST be 0 when the Sub-Sub-TLV is advertised along with routes where the Transposition Scheme is not applicable (e.g., for global IPv6 service [RFC2545] where there is no label field). The path having any such Prefix-SID attribute without any valid SRv6 SID information MUST be considered ineligible during the selection of the best path for the corresponding prefix. 💀
8. IANA Considerations ✨
8.1. BGP Prefix-SID TLV Types Registry 🎀
okay so IANA gave out Type values in the "BGP Prefix-SID TLV Types" subregistry for the two brand-new TLVs in this doc 💅
+=======+=====================+===========+
| Value | Type | Reference |
+=======+=====================+===========+
| 4 | Deprecated | RFC 9252 |
+-------+---------------------+-----------+
| 5 | SRv6 L3 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
| 6 | SRv6 L2 Service TLV | RFC 9252 |
+-------+---------------------+-----------+
Table 1: BGP Prefix-SID TLV Types
SubregistryValue 4 used to be the SRv6-VPN SID TLV 🥲 It showed up in earlier draft versions of this doc, and early implementations ran on it. Then it got deprecated and replaced by the SRv6 L3 Service and SRv6 L2 Service TLVs. Glow-up arc, honestly ✨
8.2. SRv6 Service Sub-TLV Types Registry 🌸
IANA made a whole new subregistry called "SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry 🧚 The registration procedures for it, per [RFC8126], are in Table 2:
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Table 2: SRv6 Service Sub-TLV
Types Subregistry Registration
ProceduresIANA filled it in like this. Heads up that the SRv6 SID Information Sub-TLV is defined in this document 🫶
+=======+==============================+===========+
| Value | Type | Reference |
+=======+==============================+===========+
| 0 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
| 1 | SRv6 SID Information Sub-TLV | RFC 9252 |
+-------+------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+------------------------------+-----------+
Table 3: SRv6 Service Sub-TLV Types Subregistry
Initial Contents8.3. SRv6 Service Data Sub-Sub-TLV Types Registry 💜
Same energy here. IANA created a subregistry called "SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry 🦋 Its registration procedures follow Table 4:
+=========+=========================+
| Range | Registration Procedure |
+=========+=========================+
| 1-127 | IETF Review |
+---------+-------------------------+
| 128-254 | First Come First Served |
+---------+-------------------------+
| 255 | IETF Review |
+---------+-------------------------+
Table 4: SRv6 Service Data Sub-
Sub-TLV Types Subregistry
Registration ProceduresThis doc defines just one Sub-Sub-TLV Type for it, which is the SRv6 SID Structure Sub-Sub-TLV 🍓
+=======+================================+===========+
| Value | Type | Reference |
+=======+================================+===========+
| 0 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
| 1 | SRv6 SID Structure Sub-Sub-TLV | RFC 9252 |
+-------+--------------------------------+-----------+
| 255 | Reserved | RFC 9252 |
+-------+--------------------------------+-----------+
Table 5: SRv6 Service Data Sub-Sub-TLV Types
Subregistry Initial Contents8.4. BGP SRv6 Service SID Flags Registry 🌈
IANA created a subregistry called "BGP SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) Parameters" registry ⭐ Registration is by IETF Review, and right now all 8-bit positions of the flags are unassigned. So there's room, bestie 👑
8.5. SAFI Values Registry 🦄
IANA added this document as a reference for value 128 ("MPLS-labeled VPN address") in the "SAFI Values" subregistry, which lives under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry 💖
9. Security Considerations 🔐
okay the security section is serious and I'm not gonna pretend it isn't 😭 This doc extends BGP so it can signal services for SRv6. It leans on existing BGP mechanisms for signaling different service types, and it builds on the SR architecture (mainly SRv6). So this section mostly points you back to the security notes of those existing specs, and also covers the newer security stuff that this doc brings in.
9.1. Considerations Related to BGP Sessions 🛡️
Authentication of BGP sessions still applies, to keep messages between BGP peers secure. You can read about that in the BGP specification [RFC4271] and the BGP security analysis [RFC4272]. The TCP Authentication Option for protecting BGP sessions is covered in [RFC5925], and [RFC6952] digs into BGP keying and authentication issues. This doc doesn't add any BGP session security considerations of its own 🫶
9.2. Considerations Related to BGP Services 🧚
This doc doesn't invent any new services or BGP NLRI types. It just extends how existing ones get signaled for SRv6 ✨ So the security considerations for each BGP service still apply, as covered in their own docs: BGP IPv4 over IPv6 NH [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6 [RFC2545], BGP EVPN [RFC7432], and IP EVPN [RFC9136]. [RFC8669] talks about mechanisms that stop the BGP Prefix-SID attribute, which carries SR info, from leaking outside the SR domain 🙈
As a reminder, a bunch of these BGP services (the AFI/SAFI used to signal them) were first built for one encapsulation mechanism and later extended to others. For example, EVPN MPLS [RFC7432] got extended for Virtual eXtensible Local Area Network (VXLAN) encapsulation and Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC8365]. [RFC9012] lets you use various IP encapsulation mechanisms together with different BGP SAFIs for their services. The existing filters that stop encapsulation info (carried in BGP attributes) from leaking, and that stop prefixes from the provider's internal address space from going out to external peers or the Internet (especially the SRv6 Block, as discussed in [RFC8986]), also apply to SRv6 💅
Specific to SRv6: if there's a misconfiguration or error in those BGP filters, info like SRv6 Service SIDs could get exposed to external peers or other unauthorized entities. Yikes 💀 Trying to exploit that info, or to inject packets into the network (like into customer networks in VPN services), is mitigated by the existing SRv6 data plane security mechanisms, which the next section covers.
9.3. Considerations Related to SR over IPv6 Data Plane 🌸
This section is a quick reminder and overview of SRv6 security, with pointers to the existing specs. This doc doesn't bring any new security considerations of its own from the SRv6 data plane side 🙌
SRv6 works inside a trusted SR domain. Service flow data packets between PE routers get encapsulated (using SRv6 SIDs advertised via BGP) and carried within that trusted domain, like inside a single AS or across multiple ASes in one provider network 🍓
The SR architecture's security considerations are covered in [RFC8402]. For the deeper dive on SRv6 and SRH, [RFC8754] covers SR Attacks (Section 7.1), Service Theft (Section 7.2), and Topology Disclosure (Section 7.3). So an operator deploying SRv6 MUST follow the considerations described in Section 7 of [RFC8754] to set up the infrastructure Access Control Lists (ACLs), and also the recommendations in BCP 38 [RFC2827] and BCP 84 [RFC3704] 🔥
The SRv6 deployment and SID allocation guidelines from [RFC8986] make ACL filters easier to deploy. For example, one ACL for the SRv6 Block on the external interfaces of border nodes is enough to block packets aimed at any SRv6 SID in the domain from external or unauthorized networks 🧱 There's an assumed trust model inside an SR domain, so any node sending a packet to an SRv6 SID is assumed to be allowed to do that. You also have the option of using an SRH Hashed Message Authentication Code (HMAC) TLV [RFC8754] for validation, as described in [RFC8986] 🔐
The SRv6 Endpoint Behaviors that implement the services signaled in this doc are defined in [RFC8986], so that doc's security considerations apply. These considerations don't depend on how the service gets deployed, meaning they're independent of BGP signaling for SRv6 services 🫧
All of this helps protect transit traffic and services like VPNs, so you avoid service theft or traffic getting injected into customer VPNs. Protect your network, periodt 👑
10. References 📚
10.1. Normative References
okay so this is the list of must-read docs the spec leans on, bestie 📚✨ every single one is load-bearing, so no skipping:
- [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. - [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI
10.17487/RFC2545, March 1999,https://www.rfc-editor.org/info/rfc2545. - [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
10.17487/RFC4271, January 2006,https://www.rfc-editor.org/info/rfc4271. - [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. - [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI
10.17487/RFC4456, April 2006,https://www.rfc-editor.org/info/rfc4456. - [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI
10.17487/RFC4659, September 2006,https://www.rfc-editor.org/info/rfc4659. - [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. - [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI
10.17487/RFC6514, February 2012,https://www.rfc-editor.org/info/rfc6514. - [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. - [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI
10.17487/RFC7606, August 2015,https://www.rfc-editor.org/info/rfc7606. - [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. - [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. - [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI
10.17487/RFC8277, October 2017,https://www.rfc-editor.org/info/rfc8277. - [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. - [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI
10.17487/RFC8365, March 2018,https://www.rfc-editor.org/info/rfc8365. - [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. - [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI
10.17487/RFC8669, December 2019,https://www.rfc-editor.org/info/rfc8669. - [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. - [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI
10.17487/RFC8950, November 2020,https://www.rfc-editor.org/info/rfc8950. - [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. - [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI
10.17487/RFC9136, October 2021,https://www.rfc-editor.org/info/rfc9136. - [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., and W. Lin, "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", RFC 9251, DOI
10.17487/RFC9251, June 2022,https://www.rfc-editor.org/info/rfc9251.
10.2. Informative References
these ones are the extra reading that gives helpful background, not required to implement the spec 📖💜
- [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, 18 May 2022,
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20. - [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI
10.17487/RFC2827, May 2000,https://www.rfc-editor.org/info/rfc2827. - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI
10.17487/RFC3704, March 2004,https://www.rfc-editor.org/info/rfc3704. - [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI
10.17487/RFC4272, January 2006,https://www.rfc-editor.org/info/rfc4272. - [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI
10.17487/RFC5925, June 2010,https://www.rfc-editor.org/info/rfc5925. - [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI
10.17487/RFC6513, February 2012,https://www.rfc-editor.org/info/rfc6513. - [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI
10.17487/RFC6952, May 2013,https://www.rfc-editor.org/info/rfc6952. - [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. - [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. - [SEGMENT-ROUTING-POLICY] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-22, 22 March 2022,
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22.
Acknowledgements ✨
the authors wanna give a huge shoutout to Stephane Litkowski, Rishabh Parekh, Xiejingrong, Rajesh M., Mustapha Aissaoui, Alexander Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron Bonica, and Joel Halpern for their comments and review of this document 🫶 they also thanked Document Shepherd Matthew Bocci for his review and AD Martin Vigoureux for his review, which led to helpful comments that made this doc better 💅
Contributors
these are the contributors who helped build this spec 🌸
- Clarence Filsfils, Cisco, Email: cfilsfil@cisco.com
- Satoru Matsushima, SoftBank, Email: satoru.matsushima@g.softbank.co.jp
- Dirk Steinberg, Steinberg Consulting, Email: dirk@lapishills.com
- Daniel Bernier, Bell Canada, Email: daniel.bernier@bell.ca
- Daniel Voyer, Bell Canada, Email: daniel.voyer@bell.ca
- Jonn Leddy, Individual, Email: john@leddy.net
- Swadesh Agrawal, Cisco, Email: swaagraw@cisco.com
- Patrice Brissette, Cisco, Email: pbrisset@cisco.com
- Ali Sajassi, Cisco, Email: sajassi@cisco.com
- Bart Peirens, Proximus, Belgium, Email: bart.peirens@proximus.com
- Darren Dukes, Cisco, Email: ddukes@cisco.com
- Pablo Camarilo, Cisco, Email: pcamaril@cisco.com
- Shyam Sethuram, Cisco, Email: shyam.ioml@gmail.com
- Zafar Ali, Cisco, Email: zali@cisco.com
Authors' Addresses 🦋
and here are the people who wrote it, with all their contact info so you can slide into their inbox if you have questions 💖
- Gaurav Dawra (editor), LinkedIn, United States of America, Email: gdawra.ietf@gmail.com
- Ketan Talaulikar (editor), Cisco Systems, India, Email: ketant.ietf@gmail.com
- Robert Raszuk, NTT Network Innovations, 940 Stewart Dr., Sunnyvale, CA 94085, United States of America, Email: robert@raszuk.net
- Bruno Decraene, Orange, France, Email: bruno.decraene@orange.com
- Shunwan Zhuang, Huawei Technologies, China, Email: zhuangshunwan@huawei.com
- Jorge Rabadan, Nokia, United States of America, Email: jorge.rabadan@nokia.com
the end, bestie!! 🌈👑
📦 where this page comes from
- ietf: rfc9252 2022-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms