Going Large: Extended Route Targets or Extended Confusion?#

Robin Christ

• Why: A concrete protocol design proposal addressing a real gap in EVPN-VXLAN route target encoding that large eBGP-only fabrics hit. Signals a potential IETF work item — relevant to the PM's BGP/EVPN protocol internals interest.
• What: Identifies that a 32-bit ASN + 24-bit VNI (56 bits) doesn't fit into the 48-bit payload of standard Route Targets (based on BGP Extended Communities). Current vendor behavior is inconsistent: Cumulus doesn't auto-generate RTs, Juniper truncates to the 2 least-significant ASN bytes. Proposes "Extended Route Targets" based on BGP Large Communities (RFC 8092, 96-bit total): reserve ASN 0xFFFFFFFF for IANA-managed Large Communities, add an 8-bit type field, leaving exactly 56 bits — a perfect fit for 32-bit AS + 24-bit VNI.
• How: The proposal has two steps: (1) introduce IANA-managed BGP Large Communities by moving AS 0xFFFFFFFF from "not recommended" to "reserved for IANA managed" in an update to RFC 8092, and (2) define the Extended Route Target type using the IANA-managed Large Community space. This fits 32-bit ASN + 24-bit VNI exactly (56 bits ≤ 56 bits available after the 8-bit type field).
• Where applicable: EVPN-VXLAN fabric designers using eBGP-only designs with 4-byte ASNs — the situation where RT encoding ceiling is actually hit. The proposal is a discussion-starter, not yet an IETF draft; its value is in naming the problem precisely and offering a workable path forward.