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