Thanks Krzysztof, all Let me see if I understand the 'native' proposal. Please amend as necessary :)
On Tue, Mar 16, 2021 at 9:28 PM Krzysztof Klimonda < kklimo...@syntaxhighlighted.com> wrote: > > > On Tue, Mar 16, 2021, at 19:15, Mark Gray wrote: > > On 16/03/2021 15:41, Krzysztof Klimonda wrote: > > > Yes, that seems to be prerequisite (or one of prerequisites) for > keeping current DPDK / offload capabilities, as far as I understand. By > Proxy ARP/NDP I think you mean responding to ARP and NDP on behalf of the > system where FRR is running? > > > > > > As for whether to go ovn-kubernetes way and try to implement it with > existing primitives, or add BGP support directly into OVN, I feel like this > should be a core feature of OVN itself and not something that could be > built on top of it by a careful placement of logical switches, routers and > ports. This would also help with management (you would configure new BGP > connection by modifying northbound DB) and simplify troubleshooting in case > something is not working as expected. > > > > > > > There would be quite a lot of effort to implement BGP support directly > > into OVN as per all the relevant BGP RPCs .. and the effort to maintain. > > Another option might be to make FRR Openflow-aware and enabling it to > > program Openflow flows directly into an OVN bridge much like it does > > into the kernel today. FRR does provide some flexibility to extend like > > that through the use of something like FPM > > (http://docs.frrouting.org/projects/dev-guide/en/latest/fpm.html) > > Indeed, when I wrote "adding BGP support directly to OVN" I didn't really > mean implementing BGP protocol directly in OVN, but rather implementing > integration with FRR directly in OVN, and not by reusing existing > resources. Making ovn-controller into fully fledged BGP peer seems.. like a > nice expansion of the initial idea, assuming that the protocol could be > offloaded to some library, but it's probably not a hard requirement for the > initial implementation, as long as OVS can be programmed to deliver BGP > traffic to FRR. > > When you write that FRR would program flows on OVS bridge, do you have > something specific in mind? I thought the discussion so far was mostly one > way BGP announcement with FRR "simply" announcing specific prefixes from > the chassis nodes. Do you have something more in mind, like programming > routes received from BGP router into OVN? > That's what I had also in my mind, ie. "announcing specific prefixes from the chassis nodes". I'd leave the importing routers part for a later stage if that's really a requirement. For the announcing part, let's say we try to remove the kernel as much as we can based on the discussion on this thread, then we're left with: - Route announcement: - Configure some loopback IP address in OVN per hypervisor which is going to be the nexthop of all routes announced from that chassis - Configuring OVN to tell which prefixes to announce - CMS responsibility and some knob added into OVN NB as Mark suggests - OVN to talk to FRR somehow (gRPC?) to advertise the loopback IP as directly connected and the rest of IPs in the chassis via its loopback IP - Extra resources/flows: Similar to [0] we'd need: - 1 localnet LS per node that will receive the traffic directed to the OVN loopback address - 1 gateway LR per node responsible for routing the traffic within the node - 1 transit LS per node that connects the previous gateway to the infrastructure router - 1 infrastructure LR to which all LS that require to expose routes will attach to (consuming one IP address from each subnet exposed) WARNING: scale!! My question earlier this thread was who's responsible for creating all these resources. If we don't want to put the burden of this to the CMS, are you proposing OVN to do it 'under the hood'? What about the IP addresses that we'll be consuming from the tenants? Maybe if doing it under the hood, that's not required and we can do it in OpenFlow some other way. Is this what you mean? IMO, it is very complicated but maybe it brings a lot of value to OVN. The benefit of the PoC approach is that we can use BGP (almost) today without any changes to OVN or Neutron but I am for sure open to discuss the 'native' way more in depth! [0] https://raw.githubusercontent.com/ovn-org/ovn-kubernetes/master/docs/design/current_ovn_topology.svg - Physical interfaces: The PoC was under the assumption that all the compute nodes will have a default ECMP route in the form of: 0.0.0.0 via nic1 via nic2 If we want to match this, we probably need to add OpenFlow rules to the provider bridge and add both NICs to it. If the NICs are used as well for control plane, management, storage or whatever, we are creating a dependency on OVS for all that. I believe that it is fine to lose the data plane if OVS goes down but not everything else. Somebody may have a suggestion here though. If not, we still need the kernel to do some steering into OVS/OVN. > Krzysztof Klimonda > kklimo...@syntaxhighlighted.com > >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
