[RFE] Integrate OVN BGP capabilities into Neutron OVN driver
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| neutron |
New
|
Wishlist
|
Unassigned | ||
Bug Description
There is the ovn-bgp-agent project [1] that is a part of the Neutron stadium. The goal of the project is to leverage FRR as a BGP speaker to advertise routes for the OpenStack workloads. Starting OVN 25.03 [2] core OVN supports dynamic routing that can replace the existing ovn-bgp-agent project offering the same featureset.
This is an RFE to introduce new functionality to Neutron, so Neutron can configure OVN norhtbound database with BGP capabilities. The goal is to reach parity with ovn-bgp-agent with having no BGP related agent running on the compute nodes. This will offer smoother integration of BGP and Neutron and introduce less complexity, as all the BGP work will be lifted by OVN.
As the solution is quite complex, this RFE will likely require a spec where we can discuss implementation details.
[1] https:/
[2] https:/
| tags: | added: rfe |
| Changed in neutron: | |
| importance: | Undecided → Wishlist |
| tags: | added: l3-bgp |
| tags: | added: ovn |
| tags: | added: rfe-approved |

> Starting OVN 25.03 [2] core OVN supports dynamic routing that can replace the existing ovn-bgp-agent project offering the same featureset.
>
> This is an RFE to introduce new functionality to Neutron, so Neutron can configure OVN norhtbound database with BGP capabilities. The goal is to reach parity with ovn-bgp-agent with having no BGP related agent running on the compute nodes. This will offer smoother integration of BGP and Neutron and introduce less complexity, as all the BGP work will be lifted by OVN.
OVN 25.03 did indeed introduce native dynamic routing capabilities, but in the above statement there are some incorrect assumptions about what it does and does not provide.
One of the main design goals [0][1] was to avoid re-implementing the BGP protocol in OVN, as such the solution relies on an external to OVN daemon to take care of the actual BGP sessions.
Other important design goals for native support is the ability to use the same solution across multiple CMSs, and as such we expect parts of this to be implemented in downstream deployment tooling.
There was also a design goal to make consumption of the feature for existing CMS implementations as low touch as possible, so I think the focus of the work in OpenStack Neutron should be what adjustments needs to be made to allow for the use of the native OVN route exchange support with BGP.
We have done some initial experimentation with this [2] which can be viewed both in upstream [3] test cases and downstream experimental implementations [4].
> As the solution is quite complex, this RFE will likely require a spec where we can discuss implementation details.
This work definitively calls for a spec, and we’d be happy to participate in its creation!
0: https:/ /docs.google. com/document/ d/1luzYUlzk0tur 5OixJL5fTkP8nbh kf0PJrh5GS5rngB 0 /docs.google. com/presentatio n/d/1RKX8UE1VyF wbo9fub_ 7KFjNNws- XslRNpvT9dMGVHm E /docs.google. com/drawings/ d/e/2PACX- 1vQcCFwu1lUB0Zk ferQnexaVopcrhZ oNISnuEjMDfjGbf j8B7ImFPFjORPzv tuc27gXEFc_ 9W76gl0sJ/ pub?w=960& h=720 /patchwork.<email address hidden>/ /github. com/canonical/ microovn/ blob/experiment al/bgp/ tests/test_ helper/ bats/bgp_ data_plane. bats
1: https:/
2: https:/
3: https:/
4: https:/