SRv6 Workshop#

Chair: Stefano Salsano (Univ. of Rome Tor Vergata), with Cisco, Ericsson contributors

Why: The counterpart to the MRC talk, and the more actionable one: SRv6 is the mechanism by which host-decided pathing and VXLAN replacement both become possible in mainline Linux, and this session covers exactly the gaps that still block that.

What: Three threads — source-routed AI backends (deterministic, congestion-aware path placement decided at host/NIC rather than by ECMP hashing); SRv6 L2 services beyond the current End.DX2 cross-connect; and a provider-grade end-to-end design on Linux + FRR with a new observability tool.

How: On L2: RFC 8986 defines End.DX2/DT2U/DT2M and RFC 9252 the EVPN-over-SRv6 overlay, but the kernel only implements the End.DX2 cross-connect with no native L2 endpoint netdevice; a recent netdev RFC series adds End.DT2U plus an sr6 Ethernet pseudowire device, which is what would make a VXLAN-like deployment model (and therefore replacing VXLAN in Kubernetes CNIs, OVN, Neutron) viable. The provider thread adds tablesnoop, a lookup-level tracer sitting between tcpdump and pwru/retis that traces PBR, v4/v6 route lookups, SRv6 head-end/endpoint behaviors and MPLS label ops, plus SRv6 Redundancy Protection (a new R-SID format from draft-ietf-spring-sr-redundancy-protection) with 802.1CB FRER extended to SRv6 encapsulation via XDP. (From abstract and agenda.)

Where applicable: Broadly applicable and mostly upstream-track: Linux has had SRv6 for 9 years, FRR 5 years, with SONiC/Cilium/VPP in the ecosystem. The L2 pseudowire work is RFC-series-stage, so treat the VXLAN-replacement story as a direction, not a shipping option.