This is tracking the upstream effort needed to deliver the feature request described below.

What's the bug?

When a logical router is configured to learn dynamic routes (LR.options:dynamic-routing=true) it currently learns all the non-OVN routes that are present in the VRF table it monitors.

It's actually problematic if routes in the VRF are a combination of:

• ovn installed routes
• FRR (BGP/OSPF/etc) installed dynamic routes (these have rtm_protocol > RTPROT_STATIC)
• user configured static routes

OVN(-controller) will also learn the latter as static routes.  Arguably this is a bug because the OVN feature is about "dynamic-routing".  Moreover, if a user shares the VRF with OVN and wishes OVN to use the static routes it could just explicitly configure them in the NB database as Logical_Router_Static_Route records.

ovn-controller should filter routes it learns and only learn those that were externally learned (likely through a dynamic routing protocol) and are marked as such in the VRF table (rtm_protocol > RTPROT_STATIC)

Why is it needed?

To enable the CMS (ovn-kubernetes) to share the VRF OVN monitors and updates when dynamic routing is configured.

Who will benefit? 

ovn-kubernetes transitioning to use OVN's native BGP support.  Potentially neutron-ovn too.