Parent folderOpen Confluence

RWS Architecture article

OVN-Kubernetes OKEP-5088 EVPN Support (Summary)

Summary of OKEP-5088 design material for EVPN support in OVN-Kubernetes, including UDN integration, FRR interaction, and implementation constraints.

  1. Typesource
  2. Statusactive
  3. Domainnetwork
On this page
  1. Source - OVN-Kubernetes OKEP-5088 EVPN Support
  2. Overview
  3. Context
  4. Decisions
  5. Current State
  6. References
  7. Future Work
  8. Related

Source - OVN-Kubernetes OKEP-5088 EVPN Support

Overview

Summary of OKEP-5088 design material for EVPN support in OVN-Kubernetes, including UDN integration, FRR interaction, and implementation constraints.

Context

The proposal describes a path to expose UDN networks through EVPN/VXLAN using FRR and Linux VRF/bridge/VXLAN constructs, with explicit limits and non-goals.

Decisions

  • Treat OKEP-5088 as roadmap and design input, not as an automatic production baseline.
  • Keep current datacenter EVPN profile (Nexus + NX-OS + intent automation) as the authoritative baseline until target OpenShift release supportability is validated.
  • Evaluate alternatives (including OpenPERouter) only behind lab gates and supportability checks.

Current State

  • Proposal goals include EVPN for Layer 2 (MAC-VRF) and Layer 3 (IP-VRF) primary UDNs, FRR-based control plane, and EVPN multi-homing/mass-withdraw support.
  • Scope is constrained to local gateway mode and on-prem deployment in the documented proposal.
  • FRR integration relies on Linux netdevices and an OVN-managed workflow; API extensions are proposed for VTEP, CUDN EVPN configuration, and route advertisements.
  • [Inference] Route-target handling is modeled per VNI; route leaking behavior is treated as policy-driven and requires strict governance.
  • The design notes operational complexity and version-skew risks; interoperability and support lifecycle remain explicit concerns.
  • OpenPERouter is discussed as an alternative pattern but with trade-offs (management complexity, integration constraints, and supportability uncertainty for the OVN roadmap).
  • [Inference] Primary UDN behavior maps one UDN to one Linux VRF in the proposal model; inter-UDN reachability therefore requires explicit route leaking and policy controls.
  • The proposal distinguishes two Linux netdevice realization patterns: MVD (multiple VXLAN devices) and SVD (single VXLAN device with VLAN-to-VNI mapping).
  • [Inference] SVD is treated as the preferred scale-oriented pattern in proposal discussions, but introduces explicit platform constraints (for example VLAN-space limits and FRR support-level dependencies).
  • [Inference] When EVPN support is enabled for targeted UDN paths, Geneve is no longer assumed for those paths; migration must still validate MTU and mixed-mode edge cases during transition.

References

Future Work

  • Validate feature and support posture against the target OpenShift release train before adopting OVN EVPN as a platform baseline.
  • Build a lab matrix for Nexus fabric interoperability (Type-2/3/5 behavior, RT policy, BFD failover, and rollback evidence).
  • Track FRR and OVN release prerequisites for MVD/SVD behavior explicitly in adoption gates.
  • Publish an operations checklist for UDN-to-VRF mapping, route-leak governance, and rollback from direct EVPN integration to the current FRR route-import baseline.

Related