[ovs-dev] [PATCH 1/2] ovn-controller: Datapath based conntrack zone for load-balancing.

[Ben Pfaff]

On Tue, Aug 30, 2016 at 03:04:44PM -0700, Guru Shetty wrote:
> On 30 August 2016 at 14:50, Ben Pfaff <blp at 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 <blp at 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 <guru at 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 <blp at ovn.org>