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

Kevin Benton blak111 at gmail.com
Fri Feb 20 02:38:46 UTC 2015


Yes, if there is an action similar to the 'RELATED' and 'ESTABLISHED'
keywords, then that should be adequate to replace the iptables solution
that we have now.

You are correct about the reason behind the explosion of rules. In security
groups, we allow the source/dest field to be a reference to a security
group. That was resulting in one security group rule turning into N
iptables rules, where N was the number of IPs in the security group. This
was resolved using IP sets. If OVN supports the set syntax you described,
that should achieve parity on that front as well.


On Thu, Feb 19, 2015 at 2:15 PM, Kyle Mestery <mestery at mestery.com> wrote:

> [Adding neutron tag to subject, comments below.]
>
> On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <blp at nicira.com> wrote:
>
>> [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?
>>
>> This all sounds really good to me Ben. I look forward to seeing the
> connection tracking code land and some design details on the security
> groups aspects of OVN published once that happens!
>
> Thanks,
> Kyle
>
>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150219/8c8c37bc/attachment.html>


More information about the OpenStack-dev mailing list