The BGP Fork in the Road: A Tale of Two Implementations#

Jaime Caamaño Ruiz (Red Hat), Patryk Diak (Red Hat), Surya Seetharaman (Red Hat)

• Why: Two BGP implementations were built in parallel — OVN's native dynamic routing and OVN-Kubernetes' FRR-k8s integration — and whether they converge determines how K8s clusters exchange routes with the provider network. BGP internals are squarely in the PM's interest set.
• What: A side-by-side anatomy. OVN: BGP-daemon-agnostic ("bring your own FRR"), routes exchanged through kernel VRFs over NetLink, with Advertised_Route / Learned_Route tables in the OVN DB; by default the VRF carries control-plane traffic only and the host routing table is untouched; dynamic-routing-vrf-id frees the VRF table ID from the datapath tunnel key. OVN-Kubernetes: a RouteAdvertisements CR generates FRRConfiguration for FRR-k8s; in Local Gateway mode a VRF is in the data plane, in Shared Gateway mode BGP-learned routes are copied into OVN gateway routers. Then the gap list for adopting OVN's native BGP: table-ID collisions, distinct vs shared VRFs, default VRF support, filtered learning, real next hops instead of blackhole routes, and per-LSP/per-LB /32 advertisement.
• How: Concrete merge path proposed: CMS-managed table IDs (already landed in controller/northd), shared VRFs as the more efficient but harder option needing extra OVN support (filtered learning, actual next hops on advertised routes).
• Where applicable: OVN-Kubernetes / OpenShift clusters peering with provider networks. The merge is a proposal, not a done deal — this is an honest gap analysis, not an announcement.