[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? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev