[ovs-dev] [OVN] Applying ACL changes to existing connections

[Russell Bryant]

On Mon, Feb 22, 2016 at 7:25 PM, Joe Stringer <joe at ovn.org> wrote:

> On 19 February 2016 at 06:53, Russell Bryant <russell at ovn.org> wrote:
> > On 02/18/2016 07:37 PM, Joe Stringer wrote:
> >> On 17 February 2016 at 18:12, Justin Pettit <jpettit at ovn.org> wrote:
> >>>
> >>>> On Feb 5, 2016, at 1:30 PM, Russell Bryant <russell at ovn.org> wrote:
> >>>>
> >>>>
> >>>> Thank you for the write-up!  This approach sounds great to me.  Some
> >>>> small questions...
> >>>>
> >>>> 1) If we're only using 1 bit for now, is there any reason to use
> >>>> ct_label over ct_mark?  The docs in ovs-ofctl(8) seem to suggest
> they're
> >>>> identical other than being 32-bit vs 128-bit.  Would using the 32-bit
> >>>> ct_mark be beneficial in any way instead?
> >>>
> >>> I think ct_label is intended more for this bit-level twiddling,
> whereas ct_mark is usually treated as a single 32-bit number.  Clearly,
> this doesn't really matter in practice, since OVS interfaces with them the
> same.  Also, I figure that we're going to need to identify the ACL rule at
> some point, and I've been thinking ct_mark is what we'd use for that.
> >>>
> >>>> 2) One thing not explicitly addressed in this write-up is traffic
> marked
> >>>> as related.  I think the proposal means just adding a match on
> >>>> ct_label=0x1 where we match ct_state=+rel today and we just rely on a
> >>>> packet in the request direction of the main connection to set
> ct_label.
> >>>> That seems fine, but I wanted to clarify that point.
> >>>
> >>> That's a good point.  Do you know if the existing OpenStack
> integration handles related flows?
> >>>
> >>> Jarno or Joe, do you know how the connection tracker handles children
> of deleted flows?  There's the following comment in nl_ct_flush() in
> lib/netlink-conntrack.c:
> >>>
> >>>     /* Expectations are flushed automatically, because they do not
> >>>      * have a master connection anymore */
> >>>
> >>> If we delete a specific entry, will its children get removed, too?  If
> that's true, this problem shouldn't be that difficult--although it is a
> little ugly.  I think we just need to have ovn-controller periodically
> sweep through the connection tracking entries looking for that bit, and
> blowing them away.
> >>
> >> No. The parent connection holds a list of expected connections, and
> >> when it is cleaned up, those expectations are cleaned up as well.
> >> However, once an expectation has been fulfilled by packets matching
> >> the expectation, if you commit that connection then it has a life of
> >> its own. I don't see any link from parent to child connections in the
> >> conntrack structures, so it seems unlikely that this is possible with
> >> current APIs.
> >>
> >> I think the way to do this currently is to uniquely identify
> >> connection families with a ct_mark, and delete connections based on
> >> this identifier.
> >
> > Right now, I don't think we ever do ct(commit) for a packet with the
> > related state bit set.  In that case, if we set ct_mark/ct_label on the
> > parent connection, will we see that value set when we see another
> > related packet?  I think that will result in the behavior we're looking
> > for ...
>
> The mark is inherited from the initial connection down to the
> related/child connection, but the label is not.
>

Is it inherited only at the start of the related/child connection, or at
any time?  If we set the mark on the parent connection after a
related/child connection has also been allocated, will the mark still be
inherited?

It would be good to document these minor details for ct_mark and ct_label.

-- 
Russell Bryant