On Tue, Aug 30, 2016 at 03:04:44PM -0700, Guru Shetty wrote: > On 30 August 2016 at 14:50, Ben Pfaff <b...@ovn.org> wrote: > > > On Tue, Aug 30, 2016 at 01:42:06PM -0700, Guru Shetty wrote: > > > On 30 August 2016 at 13:03, Ben Pfaff <b...@ovn.org> wrote: > > > > > > > On Tue, Aug 23, 2016 at 02:46:17AM -0700, Gurucharan Shetty wrote: > > > > > Currently ct_lb() logical action is only added for a logical switch > > and > > > > > we use the conntrack zone allocated for the logical port. A future > > > > commit > > > > > will use ct_lb() for a logical router too. In that case, use the > > > > allocated > > > > > DNAT zone. > > > > > > > > > > Signed-off-by: Gurucharan Shetty <g...@ovn.org> > > > > > > > > Can you help me to understand why the desired behavior is different in > > > > each of these cases? > > > > > > > > > > Currently we do the following conntrack zone allocations. > > > 1. A conntrack zone for each logical port. This has to be unique only per > > > hypervisor. We use this zone to do both firewall and east-west > > > load-balancing. > > > > > > For firewall, we send the packet to conntrack to defragment it and track > > it > > > and figure out whether it is invalid, new, established etc. Invalid > > packets > > > are dropped. new connections are committed. > > > > > > For load-balancing, defragmented packets are DNATed into one of the > > > possible endpoints. We do the load-balancing at the endpoint (instead of > > > say in a router) because of the asymmetric nature of OVN router pipeline > > > handling for east-west. > > > So when we see ct_lb() action on a switch, we can just use the conntrack > > > zone allocated for that logical port. > > > > > > > > > 2. Two conntrack zones per gateway router. > > > A gateway router only resides in a particular chassis. We have one > > > conntrack zone for DNAT and another for SNAT. > > > > > > Now when I want to add ct_lb() action for the gateway router, I want to > > use > > > it as part of the gateway router pipeline. Since load-balancing is > > nothing > > > but a DNAT using one of the chosen endpoint, the conntrack zone has to > > be a > > > DNAT zone allocated to that gateway router. > > > > > > Did I give the answer to your question? Or was it something else that you > > > were looking an explanation for? > > > > One underlying question I'm trying to understand is whether this > > difference is something inherent in the definition of logical switches > > and logical routers, and thus the approach taken here of automatically > > choosing a strategy is appropriate, or whether this is just what we > > happen to be doing now, in which case it might be better to make how to > > select the zone a parameter to ct_lb. > > > > I see the question now. I don't have a good answer. One way to look at it > would be that a "zone" is an internal implementation detail and should not > be seen in a action of logical flow. But we can then say that we could > rename "zone" as "datapath" in the logical action. But, then we would be > limiting it to 2 anyway (datapath=lswitch or datapath=lrouter), because > that is all that I can think about - in which case we are inferring it with > the current patch anyway. I did start with passing this as an argument to > ct_lb, but could not think about a good name. I then decided that for a > stateful OVS action, you probably cannot make a very general purpose > logical action. Do you have an opinion? I will go with that.
I think I understand now. Let's take what you've done. Please consider whether any of your explanation here is worth putting into comments or documentation or the commit log. Acked-by: Ben Pfaff <b...@ovn.org> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
