Hello,
On Tue, Jun 25, 2024 at 6:04 PM Dumitru Ceara <dce...@redhat.com> wrote:
>
> Hi,
>
> Thanks to everyone who attended the OVN meeting yesterday!
>
> The recording is available here:
> https://www.youtube.com/watch?v=bonLhUj2oGg
>
> Transcripts:
> https://drive.google.com/file/d/1ioVXcHiuD-xr5RQTh5OSGbpmhUtIDiO_/view?usp=sharing
>
> Notes:
> https://docs.google.com/document/d/1dG4GwcYOSs4uArPGtOoaP5tH4KCto-GH_C3tIXSnZZ8/
Thank you for organizing, it was a good discussion! As promised I also
sent out an e-mail detailing some of the points we spoke about, I
suggest we continue the discussion there [0].
> The main discussion topic was BGP integration in OVN and mostly about
> where to run the BGP control plane (e.g., FRR on the side vs an in-tree
> BGP implementation) and how to get packets to it. I'll try to list some
> points here:
>
> Frode suggested a "L2 load balancer" feature to be added to OVN to
> "sniff" BGP control packets reaching a logical router and send them out
> (through a VIF?) to FRR running alongside OVN on the host.
>
> Ilya also provided an alternative of using a new type of logical router
> port, similar to a loopback interface and bind BGP configuration to that
> one.
>
> I had an off-list discussion with Tim Rozet (in CC) from the OpenShift
> networking team in Red Hat and he shared an idea that might be
> interesting because it kind of combines the two above. That is:
>
> - configure a TCP load balancer on the logical router we want FRR to run
> BGP for
> - this load balancer will "balance" (DNAT) traffic to a single backend
> IP which can be any tenant internal IP reserved for FRR to bind to
> - this IP could be configured on a regular OVN VIF that's further
> plugged into the namespace/container/VM where FRR runs
>
> Frode, would this be a good alternative for your use case?
Using a loopback address is indeed common in many configurations,
however as I see it there are two requirements that conflict with
that. One being the goal of minimizing configuration overhead through
the use of IPv6 LLA ("BGP Unnumbered ''), which inherently are point
to point, the other being support for BGP authentication, which is at
odds with NATing the BGP connection. An indirect blocker for this
would also be how popular BGP implementations do not allow setting a
next hop for routes transmitted over a IPv6 LLA.
See more detail in [0].
> In any case, if we end up having to add a new feature to explicitly
> handle BGP configuration (the "L2 load balancer" discussed in the
> meeting), I think my preference would be in the end to have an explicit
> "bgp" configuration in the northbound database. We already do that for
> other features: DHCP, IGMP, multicast routing.
Ack, thank you for stating your preference here!
> Finally, I'd like to propose a new technical meeting instance in
> approximately 5 weeks. I'm looking at:
>
> Monday, July 29th, 3PM UTC.
>
> I'll wait a few days before sending out the invite in case people raise
> objections.
Works for me!
0: https://mail.openvswitch.org/pipermail/ovs-dev/2024-June/415033.html
> Best regards,
> Dumitru Ceara
>
> On 6/21/24 11:05, Dumitru Ceara wrote:
> > Hi everyone,
> >
> > Just a small reminder for anyone interested in joining the next OVN
> > technical meeting. It's scheduled to happen next week on Monday June
> > 24th at 3PM UTC.
> >
> > Meeting details:
> > Date/Time: Monday, June 24th, 3PM UTC
> > Link: meet.google.com/zns-gqsd-jdn
> > Agenda:
> > https://docs.google.com/document/d/1dG4GwcYOSs4uArPGtOoaP5tH4KCto-GH_C3tIXSnZZ8/edit?usp=meetingnotes
> >
> > Please feel free to add any items you'd like to discuss to the agenda.
> > I added some of the things I'm aware of there already.
> >
> > Best regards,
> > Dumitru
>
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
