[openstack-dev] [ovs-dev] [PATCH 8/8] [RFC] ovn: Start work on design ocumentation.

Ben Pfaff blp at nicira.com
Thu Feb 19 21:55:45 UTC 2015


[moving this conversation to openstack-dev because it's more
interesting there and that avoids crossposting to a subscribers-only
list]

On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:
>    I specially liked the VIF port lifecycle, looks good to me, Ionly miss some  
> ???port_security??? concepts we have in neutron, which I guess could have been  
> deliberately omitted for a start.
> 
>    In neutron we have something called security groups, and every port
> belongs to 1 or more security groups.  Each security group has a list of
> rules to control traffic at port level in a very fine grained fashion (ingress/egress
> protocol/flags/etc???   remote_ip/mask or security_group ID)
> 
> I guess we could build  render security_group ID to multiple IPs for each port,
> but then we will miss the ingress/egress and protocol flags (like type  of protocol,
> ports, etc.. [1])
> 
> Also, be aware, that not having security group ID references from neutron,
> when lot???s of ports go to the same security group we end up with an exponential
> growth of rules / OF entries per port, we solved this in the server<->agent
> communication for the reference OVS solution by keeping a lists of IPs  
> belonging to security group IDs, and then, separately having the  
> references from the rules.

Thanks a lot for the comment.

We aim to fully support security groups in OVN.  The current documents
don't capture that intent.  (That's partly because we're planning to
implement them in terms of some new "connection tracking" code for OVS
that's still in the process of getting committed, and partly because I
haven't fully thought them through yet.)

My initial reaction is that we can implement security groups as
another action in the ACL table that is similar to "allow" but in
addition permits reciprocal inbound traffic.  Does that sound
sufficient to you?

Is the exponential explosion due to cross-producting, that is, because
you have, say, n1 source addresses and n2 destination addresses and so
you need n1*n2 flows to specify all the combinations?  We aim to solve
that in OVN by giving the CMS direct support for more sophisticated
matching rules, so that it can say something like:

        ip.src in {<a>, <b>, <c>, ...} && ip.dst in {<d>, <e>, <f>, ...}
        && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})

and let OVN implement it in OVS via the "conjunctive match" feature
recently added, which is like a set membership match but more
powerful.  It might still be nice to support lists of IPs (or
whatever), since these lists could still recur in a number of
circumstances, but my guess is that this will help a lot even without
that.

Thoughts?



More information about the OpenStack-dev mailing list