Thanks a lot for your reply Lajos! On 29.04.24 9:32 AM, Lajos Katona wrote:
Hi Christian, I suggest to open a launchpad bug for this, perhaps even mark it as an RFE (Request for Enhancement, kind of lightweight blueprint for Neutron).
DONE via https://bugs.launchpad.net/neutron/+bug/2064120
The Neutron drivers team discuss these topics on Fridays 1400 UTC if there's open agenda (open RFEs :-))
Do you expect / want me to join in? This Friday then? Could you kindly point me (and others interested) to the Etherpad / conferencing info?
If I understand well the technical bottleneck here is os-ken, am I right?
Maybe. Let me rephrase my 1) and 2) options towards fixing this a little ... 1) If you can only run one BGP speaker per dragent (due to os-ken only supporting one BGP session), one option would be to allow this BGP session to be multi-protocol BGP (so carrying IPv4 and IPv6 routes). os-ken already has MP-BGP support, so it's about selecting and exporting IPv4 and IPv6 routes within the same, single session. 2) The second option is to enable dragent or somehow have two BGP speakers scheduled to it. a) extend os_ken (as you suggested) to support more than one BGP session (two should be enough if we are talking about one for IPv4 and another one for IPv6). There has to be some consideration for HA [1] to now schedule two sessions that are redundant to each other to one agent. But when only accepting one IPv4 and one IPv6 session this should not be an issue. b) if extending os_ken is not an option, maybe the whole dragent can be built to run multiple instances of a single driver (os_ken) to then accept more than one bgp speaker scheduled to it. Somewhat of the worker pattern with the drivers being the workers. [1] https://docs.openstack.org/neutron/latest/admin/config-bgp-dynamic-routing.h... Regards and thanks again! Christian