> On Feb 5, 2016, at 1:30 PM, Russell Bryant <russ...@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.
> I'm happy to work on the OVN implementation of this approach assuming no
> alternative supplants it. It sounds fun. :-)
I haven't had a chance to do any coding lately, so if you want to look at it,
that'd be great!
--Justin
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
