BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
updated by
- rfc-9819 — Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)
Extracted elements (29)
The SRv6 Service SID SHOULD be routable within the AS of the egress PE and serves a dual purpose: it provides reachability between ingress and egress PE (via the Locator prefix) while simultaneously encoding the SRv6 Endpoint Behavior. This allows the underlay to require only plain IPv6 forwarding (RFC 8200) without MPLS.
The Transposition Scheme is introduced to achieve efficient packing of BGP update messages. For services requiring per-prefix SID allocation (e.g., EVPN VPWS with End.DX2), encoding the full 128-bit SID in every NLRI is wasteful; instead, the common Locator part is placed in the SRv6 Services TLV and the variable Function or Argument part is transposed into the existing MPLS Label field, reusing space already present in the NLRI encoding.
When a PE determines (using the SRv6 SID Structure) that the Service SID belongs to the same SRv6 Locator as the last SRv6 SID in an SR Policy segment list, it MAY exclude the last segment-list SID and instead use <S1, S2, S3-Service-SID> directly, avoiding double-encapsulation while achieving policy steering.
BGP speakers that do not support RFC 9252 may misinterpret the part of the SRv6 SID encoded in MPLS Label fields as MPLS label values for MPLS-based services. Implementations MUST therefore provide per-neighbor and per-service controls to gate advertisement of SRv6-based BGP service routes to peers known to support this specification.
EVPN Route Type 4 (Ethernet Segment route) does not carry any SRv6 Service TLVs; its processing remains unchanged from RFC 7432. Similarly, EVPN Route Types 6, 7, and 8 do not require SRv6 Service TLV advertisement, and their BGP next hop equals the IPv6 address of the egress PE.
BGP speakers 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, because BGP speakers that do not support this specification may misinterpret the SRv6 SID encoded in MPLS Label fields as MPLS label values.
Bits transposed out of the SRv6 SID value into an MPLS Label field MUST be set to 0 in the SID value field of the SRv6 SID Information Sub-TLV, so the receiver can reconstruct the full SID by OR-ing the transposed bits back at the correct offset.
The Argument Length (AL) MUST be set to 0 for SIDs where the Argument is not applicable to the SRv6 Endpoint Behavior. A receiver MUST ignore SRv6 SIDs with a non-zero AL when the SRv6 Endpoint Behavior is unknown to it. For known behaviors, the receiver MUST validate that AL is consistent with the specific Endpoint Behavior definition.
The ingress PE MUST perform a resolvability check for the SRv6 Service SID (evaluated per RFC 4271) before considering the received prefix for BGP best path computation, for both L3 services (Section 5) and EVPN services (Section 6).
The sum of Locator Block Length (LBL), Locator Node Length (LNL), Function Length (FL), and Argument Length (AL) MUST be less than or equal to 128 and greater than the sum of Transposition Offset and Transposition Length. When Transposition Length is 0 (nothing transposed), the Transposition Offset MUST also be set to 0.
The treat-as-withdraw action (RFC 7606) MUST be performed when at least one malformed SRv6 Service TLV is present in the BGP Prefix-SID attribute. A path with a Prefix-SID attribute containing no valid SRv6 SID information MUST be considered ineligible during best path selection.
When an egress PE signals an SRv6 L3 or L2 Service TLV, the BGP ingress PE receiving the route MUST perform IPv6 encapsulation and insert an SRH (RFC 8754) when required for SRv6-policy-based steering.
When propagating a route with SRv6 Service TLVs and the BGP next hop is unchanged, the SRv6 Service TLVs (including unrecognized Sub-TLV and Sub-Sub-TLV types) SHOULD be propagated; all Reserved fields MUST be propagated unchanged. When the next hop changes, unrecognized Sub-TLVs and Sub-Sub-TLVs MUST be removed and the TLVs SHOULD be updated with locally allocated SRv6 SID information.
For EVPN Route Type 1 (Ethernet A-D per ES) over SRv6 core, the 24-bit ESI Label field of the ESI Label extended community carries the whole or a portion of the Argument part of the SRv6 SID (Transposition Length ≤ 24 ≤ AL) when ESI filtering is used; otherwise set to Implicit NULL (0x000030). The Service SID SHOULD use End.DT2M behavior and signals the Arg.FE2 SID Argument.
For EVPN Route Type 2 (MAC/IP Advertisement) over SRv6 core, MPLS Label1 (24-bit) carries the Function part of the SRv6 L2 Service SID and MPLS Label2 (24-bit, optional) carries the Function part of an SRv6 L3 Service SID when the Transposition Scheme is used (Transposition Length ≤ 24). When not using transposition, both labels are set to Implicit NULL in the higher-order 20 bits (0x000030).
For EVPN Route Type 3 (Inclusive Multicast Ethernet Tag / BUM traffic) over SRv6 core, the PMSI Tunnel Attribute MPLS label field carries the whole or a portion of the SRv6 SID Function part when ingress replication and the Transposition Scheme are used (Transposition Length ≤ 24). The Service SID SHOULD use End.DT2M behavior. When ESI-based filtering is used, the Arg.FE2 from Route Type 1 SHOULD be merged with the End.DT2M SID via bitwise OR.
For IPv4 VPN over SRv6 core (Section 5.1) and IPv6 VPN over SRv6 core (Section 5.2), the MPLS label field of the VPN NLRI carries the whole or a portion of the SRv6 SID Function part when the Transposition Scheme is used (Transposition Length ≤ 20 for 20-bit label field); otherwise it is set to Implicit NULL. Expected Endpoint Behaviors are End.DX4/End.DT4/End.DT46 for IPv4 and End.DX6/End.DT6/End.DT46 for IPv6.
SRv6 Endpoint Behaviors are encoded in the SRv6 SID Information Sub-TLV as a 2-octet codepoint from the IANA 'SRv6 Endpoint Behaviors' subregistry (RFC 8986). The opaque behavior value 0xFFFF MAY be used by an advertising router to abstract its locally instantiated SRv6 SID behavior. Unrecognized behaviors MUST NOT be considered invalid (except those involving arguments with non-zero AL).
The SRv6 SID Information Sub-TLV (Sub-TLV Type 1) carries a single SRv6 SID and its properties: RESERVED1 (1 octet), SRv6 SID Value (16 octets), SRv6 Service SID Flags (1 octet, currently all zero), SRv6 Endpoint Behavior (2 octets, codepoint from RFC 8986 registry), RESERVED2 (1 octet), and variable SRv6 Service Data Sub-Sub-TLVs.
Two new TLVs of the BGP Prefix-SID attribute are defined: SRv6 L3 Service TLV (Type 5) encodes Service SID information for SRv6-based L3 services (equivalent to MPLS label for L3VPN), and SRv6 L2 Service TLV (Type 6) encodes Service SID information for SRv6-based L2/EVPN services. Each TLV contains a 1-octet Type, 2-octet Length, 1-octet RESERVED, and variable-length SRv6 Service Sub-TLVs.
IANA assigned two new values in the 'BGP Prefix-SID TLV Types' subregistry: Type 5 (SRv6 L3 Service TLV) and Type 6 (SRv6 L2 Service TLV). Type 4 is deprecated (it previously corresponded to the SRv6-VPN SID TLV from earlier draft versions used by early implementations).
IANA created a new 'BGP SRv6 Service SID Flags' subregistry under BGP Parameters, with IETF Review as the registration procedure. All 8-bit positions are currently unassigned; the flags octet MUST be set to 0 by senders and unknown flags MUST be ignored by receivers.
IANA created a new 'SRv6 Service Data Sub-Sub-TLV Types' subregistry under BGP Parameters with the same registration procedure ranges as the Sub-TLV registry. Initially populated with: 0 (Reserved), 1 (SRv6 SID Structure Sub-Sub-TLV), 255 (Reserved).
IANA created a new 'SRv6 Service Sub-TLV Types' subregistry under BGP Parameters. Range 1-127 requires IETF Review; 128-254 is First Come First Served; 255 requires IETF Review. Initially populated with: 0 (Reserved), 1 (SRv6 SID Information Sub-TLV), 255 (Reserved).
Existing BGP session authentication mechanisms (TCP-AO per RFC 5925, and keying/authentication analysis per RFC 6952) apply without modification. This document introduces no additional BGP session-level security considerations.
Misconfiguration of BGP filtering may expose SRv6 Service SIDs to external peers; however, exploitation is mitigated by SRv6 data plane security (infrastructure ACLs, SRH HMAC TLV per RFC 8754) which prevents unauthorized packet injection into the SR domain and protects against service theft in VPN scenarios.
Operators deploying SRv6 MUST follow the infrastructure ACL recommendations in RFC 8754 Section 7 (and BCP 38/BCP 84) to prevent packets destined to SRv6 SIDs from entering the SR domain from external/unauthorized networks. A single ACL matching the SRv6 Block applied at border nodes suffices to block all SRv6 SID-destined packets from outside.
The SRv6 Service TLV is encoded as: TLV Type (1 octet), TLV Length (2 octets), RESERVED (1 octet, MUST be 0), followed by variable-length SRv6 Service Sub-TLVs. Type 5 is the SRv6 L3 Service TLV; Type 6 is the SRv6 L2 Service TLV.
The SRv6 SID Structure Sub-Sub-TLV (Sub-Sub-TLV Type 1, fixed length 6 octets) encodes the lengths in bits of: Locator Block, Locator Node, Function, Argument, Transposition Length (bits shifted into MPLS Label field), and Transposition Offset (bit position of transposed bits). This allows the receiver to reassemble the full SRv6 SID when split-encoding is used.