EVPN - One control plane to rule them all#

Patrick Prangl, Arista Networks

• Why: Consolidating all L2/L3 VPN service delivery onto one BGP control plane across DC and WAN is exactly the PM's DC/WAN interconnect space, and this maps the RFC landscape, the SR-MPLS→SRv6 migration tiers, and the gateway designs that make it real.
• What: The case for EVPN as the single service control plane: EVPN-VPWS (RFC 8214) for E-LINE, EVPN-L2VPN (RFC 7432) for E-LAN, EVPN-L3VPN Type-5 (RFC 9136), and EVPN multicast (RFC 9625 OISM) — replacing LDP/BGP-VPLS, MC-LAG, Draft-Rosen/NG-MVPN, and per-service signaling protocols. Transport strategy: SR-MPLS reusing existing MPLS hardware and BGP control plane (TI-LFA for 50 ms FRR, FlexAlgo for controller-less macro-TE, controller-based micro-TE), with three SRv6 maturity tiers — SR-MPLSv4 (no hardware change), SR-MPLSv6 (IPv6 forwarding plane, possible HW upgrade), SRv6 uSID (likely HW upgrade, new control plane). EVPN gateway design per BESS RFCs/drafts (8365, 9014, draft-ietf-bess-evpn-ipvpn-interworking): VXLAN↔MPLS interworking where Type-⅖ routes are re-advertised across domains with re-encapsulation while Type-⅓/4 stay local; gateway next-hop chaining so leaves only learn local next-hops; D-PATH attribute for inter-domain loop prevention. Forward-looking pieces: Unknown MAC Route (MAC=0 + gateway ESI) to bound MAC scale in multi-domain fabrics, and the multicast gateway family (MEG, PEG, EEG).
• How: One BGP AFI/SAFI across all service types; gateways translate encapsulation and own inter-domain next-hop re-advertisement, containing control-plane state per domain; D-PATH domain-ID tagging prevents route loops across gateway meshes.
• Where applicable: Explicitly covers greenfield build-outs and brownfield MPLS/SR coexistence with interop gateways; transport per use case (VXLAN in DC/campus, MPLS-SR/SRv6 in WAN, VXLAN-over-IPSec for SD-WAN). Arista vendor session, but anchored in IETF standards — the architecture applies to multi-vendor EVPN deployments.