The comfortable complexity of Overlays#

Claudiu Captari — Arista

• Why: The "EVPN everywhere" architectural argument, cleanly organized — useful as the current vendor-consensus view on unifying DC/campus/WAN overlays, which the PM touches via DC fabric work.
• What: The case for EVPN as a single service plane across domains, with transport chosen per domain: VXLAN where bandwidth is cheap (DC/campus leaf-spine with ECMP), VXLAN-over-IPsec / Secure-EVPN for branch, SR/SRv6 for bandwidth-constrained or TE-needing WAN — stitched by EVPN gateways (RFC 9014) that re-originate type-2/type-5 routes with new next-hop/encapsulation per domain, providing hierarchical flood-list scaling for BUM traffic and reduced EVPN state churn across domains. Includes the full EVPN RFC map (7432, 8214, 8365, 9135/9136, 9014, 9251, OISM) with ~48 active drafts, EANTC multi-vendor interop testing across six testbeds, high-speed in-flight encryption options (MACSec, IPSec, VXLANsec), and SRv6 use cases including AI-fabric TE where the server NIC computes and applies SRv6 encapsulation and leaf/spine nodes just perform uSID forwarding.
• How: Architecture pitch built on open standards: gateway route re-origination, all-active multi-homing, symmetric/asymmetric/centralized IRB, OISM multicast, FlexAlgo and dynamic SR-TE for the WAN.
• Where applicable: Arista session — an architecture pitch for a consistent operational model, though grounded in open RFCs and EANTC interop rather than proprietary features. Relevant to multi-domain enterprise/DC designers evaluating overlay convergence; the domain-by-transport mapping is the transferable part.