This Feature groups all OVN enhancements required to enable OVN-Kubernetes to transition from its current external BGP integration to OVN's native BGP support. These changes were identified during discussions with the OVN-Kubernetes team at the OVS+OVN 2025 Conference. OVN-Kubernetes will be the primary beneficiary of this gap closure. OpenStack Neutron, other OVN consumers might benefit from it as well.

The work will:

• Eliminate the need for external BGP tooling in OVN-Kubernetes, reducing operational complexity
• Allow BGP routing configuration to be managed through OVN NB database, providing a single source of truth
• Enable migration from existing non-native EVPN implementations to OVN-native support
• Allow granular control over route advertisements per object (NAT, LB, LSP, LRP)

More context:

OVN 25.09 introduced native BGP and BGP-EVPN support (experimental). For OVN-Kubernetes to adopt this native support and deprecate its external BGP integration, several gaps need to be addressed:

1. Interface Naming Compatibility: OVN-K already has EVPN integration with specific interface naming conventions. Configurable names enable migration without breaking existing setups.

2. VRF Sharing: OVN-K needs to share the VRF with the host for traffic forwarding, requiring explicit next-hop configuration rather than blackhole routes.

3. Route Learning Hygiene: When sharing VRFs, OVN should only learn dynamically-advertised routes (BGP/OSPF), not static routes manually configured by users.

4. Selective Advertisement: OVN-K needs fine-grained control over which IPs are advertised (e.g., only specific NAT entries, not all).

5. Advertise-Only Mode: In multi-router topologies, OVN-K needs to configure some routers to only advertise routes (no learning) while others only learn (no advertising). This enables proper separation of concerns in complex network designs.