Open Stack

Thanks for both of those bits of information.

I've added an "allow-related" action for v3.

On Thu, Feb 19, 2015 at 06:38:46PM -0800, Kevin Benton wrote:
> 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