Skip to content

RFC 9819 - Argument Signaling for BGP Services in SRv6

Field Value
Title Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)
Authors K. Talaulikar, K. Raza, J. Rabadan, W. Lin
Date July 2025
Status Proposed Standard
Updates RFC 9252
Link datatracker.ietf.org/doc/rfc9819

Summary

Some SRv6 behaviors take an argument in the low-order bits of the SID. The case that matters for BGP services is End.DT2M (EVPN BUM flooding), whose argument Arg.FE2 tells the egress PE which local Ethernet Segment to exclude — the split-horizon (ESI filtering) needed for EVPN multihoming and E-Tree leaf filtering.

RFC 9252 split the signaling: the egress PE advertises the LOC:FUNC part of its End.DT2M SID in the Inclusive Multicast Ethernet Tag route (Type 3) and the argument in the Ethernet A-D per ES route (Type 1), and the ingress PE combined them with a bitwise OR. Interop testing showed this was ambiguous and only works if both routes use identical SID structures. RFC 9819 replaces the OR with an explicit procedure: the ingress PE inserts the argument at the offset given by the SID Structure (LBL + LNL + FL) of the Type 3 route.

The rules are written for End.DT2M but apply to any argument-carrying SRv6 behavior signaled in BGP, and they cover the compressed (NEXT-C-SID) End.DT2M flavors from RFC 9800 as well.

Key Sections

Section Topic Description
2 Advertisement of SID and Arguments SID Structure sub-sub-TLV is mandatory; AL = 0 means "no argument accepted"
3.1 Ethernet A-D per ES route Carries the ESI filtering argument (or :: with AL = 0)
3.2 Inclusive Multicast Ethernet Tag route Carries only LOC:FUNC; AL announces the argument size
3.3 Ingress PE processing How to build the data-plane SID and what to do on inconsistent AL
4 Backward compatibility When the RFC 9252 bitwise-OR still works

Signaling Rules

Route SID field Argument Length (AL)
Type 1 (A-D per ES), no ESI filtering :: (End.DT2M), structure still included 0
Type 1 (A-D per ES), ESI filtering Argument value placed at LBL+LNL+FL offset Argument size (SHOULD be a multiple of 8)
Type 3 (IMET), no ESI filtering LOC:FUNC only 0
Type 3 (IMET), ESI filtering LOC:FUNC only Must equal the AL in the Type 1 route

Ingress PE Decision

Condition Result
Type 3 AL = 0 Use LOC:FUNC only; ignore any Type 1 argument
Type 3 AL ≠ 0, no matching Type 1 SID or Type 1 AL = 0 No usable argument; use LOC:FUNC only
Both AL ≠ 0 but different Configuration error — do not forward BUM from that ES to avoid loops; log it
Both AL ≠ 0 and equal Insert the Type 1 argument at offset LBL+LNL+FL of the Type 3 SID

Example from the RFC: Type 3 2001:db8:1:fbd1:: (structure 32/16/16, AL 16) plus Type 1 argument aaaa gives the data-plane SID 2001:db8:1:fbd1:aaaa::. With a 32-bit function on another bridge domain, the same argument lands one hextet further right — something a plain OR could not express.

Common Pitfalls

  • Older RFC 9252-only implementations that OR the two SIDs interoperate only when both routes advertise the same SID structure. Mixed structures require RFC 9819 support on the ingress PE.
  • An egress PE must use the same AL for all local Ethernet Segments in a broadcast domain.
  • Do not "simplify" the Type 1 encoding by zeroing LBL/LNL/FL — it breaks backward compatibility with RFC 9252 receivers.
  • ESI filtering is not needed with the "Local Bias" method (RFC 8365), without multihoming, or without E-Tree leaf BUM traffic.
Document Relationship Description
RFC 9252 Updated by this RFC BGP overlay services over SRv6
draft-ietf-bess-bgp-srv6-args Draft lineage Draft that became RFC 9819

References

  1. RFC 9819 - Argument Signaling for BGP Services in SRv6
  2. RFC 9252 - BGP Overlay Services Based on SRv6
  3. RFC 7432 - BGP MPLS-Based Ethernet VPN (route types, split horizon)
  4. RFC 8317 - Ethernet-Tree (E-Tree) Support in EVPN