Open Stack

Hi all,

Do we have plan to implement it in Liberity? I am really interest in and want to join it.

/Yalei

From: Miguel Ángel Ajo [mailto:majopela at redhat.com]
Sent: Saturday, February 21, 2015 12:31 AM
To: Ben Pfaff
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ovs-dev] [PATCH 8/8] [RFC] [neutron] ovn: Start work on design ocumentation.

On Friday, 20 de February de 2015 at 17:06, Ben Pfaff wrote:
On Fri, Feb 20, 2015 at 12:45:46PM +0100, Miguel Ángel Ajo wrote:
On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:
On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <blp at nicira.com (mailto:blp at nicira.com)> wrote:
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?
Yes, having fine grained allows (matching on protocols, ports, and
remote ips would satisfy the neutron use case).

Also we use connection tracking to allow reciprocal inbound traffic
via ESTABLISHED/RELATED, any equivalent solution would do.

For reference, our SG implementation, currently is able to match on
combinations of:

* direction: ingress/egress
* protocol: icmp/tcp/udp/<raw number>
* port_range: min-max (it’s always dst)
* L2 packet ethertype: IPv4, IPv6, etc...
* remote_ip_prefix: as a CIDR or * remote_group_id (to reference all other IPs in a certain group)

All of them assume connection tracking so known connection packets will
go the other way around.

OK. All of those should work OK. (I don't know for sure whether we'll
have explicit groups; initially, probably not.)
That makes sense.


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})

That sounds good and very flexible.
and let OVN implement it in OVS via the "conjunctive match" feature
recently added, which is like a set membership match but more
powerful.
Hmm, where can I find examples about that feature, sounds interesting.

If you look at ovs-ofctl(8) in a development version of OVS, such as
http://benpfaff.org/~blp/dist-docs/ovs-ofctl.8.pdf
search for "conjunction", which explains the implementation.
Amazing, yes, it seems like conjunctions will do the work quite optimally
at OpenFlow level.

My hat off… :)
(This
isn't the form that Neutron would use with OVN; that is the Boolean
expression syntax above.)

Of course, understood, I was curious about the low level supporting the
high level above.

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.
As afar as I understood, given the way megaflows resolve rules via hashes
even if we had lots of rules with different ip addresses, that would be very fast,
probably as fast or more than our current ipset solution.

The only caveat would be having to update lots of flow rules when a port goes
in or out of a security group, since you have to go and clear/add the rules to each
single port on the same security group (as long as they have 1 rule referencing the sg).

That sounds like another good argument for allowing explicit groups. I
have a design in mind for that but I doubt it's the first thing to
implement.
Of course, 1 step at a time. I will do a 2nd pass on your documents, looking a bit
more on the higher level. I’m very happy to see that the low level is very well tied
up and capable.

Best regards,
Miguel Ángel.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150402/129d60fb/attachment.html>