Open Stack

On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> Assigning a distinct ct zone to each port sounds more scalable. This should
> keep the number of zones per host

Agree that zones could be a good solution to this problem.  +1 to zone
/ port for scalability.  Though it will take a bit more code and
complexity to kill the right connections than it would with zone /
rule.

> Once we identify the ports, and therefore the ct zones, then we'd still need
> to find the connections matching the rules which were removed. This does not
> sound like being too difficult, but it can result in searches over long
> lists - think about an instance hosting a DB or web server.

Are you thinking of listing all connections and then iterating over
the list with some code to match it to a security group rule being
removed/updated?  Or, map the security group rule to conntrack filter
arguments to send to a call to conntrack -D?

This could be problematic.  What if security group rules were
redundant and an update or removal of a rule should not really affect
any existing connections?  If all connections were compared instead
against the set of *remaining* security group rules then this wouldn't
be a problem.  This sounds non-trivial to me.  I'm probably thinking
too hard about this.  ;)

> The above two considerations made me suggest the idea of associating ct
> zones with rules, but it is probably true that this can cause us to go
> beyond the 2^16 limit.

I agree we'd hit this limit.

Carl