>To: Ben Pfaff <b...@ovn.org> >From: Guru Shetty >Sent by: "dev" >Date: 05/18/2016 09:10AM >Cc: ovs dev <dev@openvswitch.org> >Subject: Re: [ovs-dev] Seek information about OVN L3 gateway and NAT > >> >> >> >> There was an in-person meeting yesterday at VMware with Mickey (from >> that thread) and some other IBMers. I couldn't attend the whole meeting >> but I assume that some conclusions were reached. I guess that we'll >> know more soon. >> > >The conclusion of the meeting was that we will go ahead with the "gateway >router" approach for conntrack based NAT and will be used by anyone that >need L3 and L4 based NAT. For the OpenStack case of floating ips (which >does not need L4 ports to be NATed), the idea is to not use conntrack as >much as possible and also to not use the additional gateway router. We >think, there is a workable solution for north-south and south-north cases. >The guys at IBM will work on the east-west case to see how they could >potentially leverage conntrack for that particular use case.
I certainly agree that there are different use cases that lead to different solutions. We need to make a bit more progress on a single (mostly distributed) router proposal for OpenStack, including floating IPs and OpenStack router SNAT (for non-floating IP traffic, which does require L4 ports to be NATed). Most of the complexities that we are working through have to do with a desire to handle some traffic in a distributed manner (including north/south floating IP traffic) while handling other traffic at a centralized gateway port (including north/south SNAT traffic). Once we get to a proposal that holds together better, we will be in a better position to provide guidance on which use cases fit with which approach, "gateway router" or "distributed router with centralized gateway port". One use case that seems to fit better with the "gateway router" approach is the support of Kubernetes inside a collection of VMs from a public cloud provider such as AWS or Azure, running OVN inside the VMs. This use case requires the notion of a collection of gateways. It is clear that the "gateway router" approach can support a collection of gateway routers connected to one distributed router, all for one tenant. I agree that the "gateway router" should move ahead in order to support this use case. I am still thinking about possible changes to terminology around the different gateway approaches, so that we can better distinguish the two approaches as they move forward independently. I will make some proposals in response to Guru's L3 gateway patch. Mickey > >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> >_______________________________________________ >dev mailing list >dev@openvswitch.org >http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
