<div style="font-family: Helvetica; font-size: 14px;"><span style="color: rgb(160, 160, 168); font-size: 13px;">On Friday, 20 de February de 2015 at 17:06, Ben Pfaff wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Fri, Feb 20, 2015 at 12:45:46PM +0100, Miguel Ángel Ajo wrote:</div><blockquote type="cite"><div><div>On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote: </div><blockquote type="cite"><div><div>On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <blp@nicira.com (<a href="mailto:blp@nicira.com">mailto:blp@nicira.com</a>)> wrote:</div><blockquote type="cite"><div><div>My initial reaction is that we can implement security groups as</div><div>another action in the ACL table that is similar to "allow" but in</div><div>addition permits reciprocal inbound traffic. Does that sound</div><div>sufficient to you?</div></div></blockquote></div></blockquote><div>Yes, having fine grained allows (matching on protocols, ports, and</div><div>remote ips would satisfy the neutron use case).</div><div><br></div><div>Also we use connection tracking to allow reciprocal inbound traffic</div><div>via ESTABLISHED/RELATED, any equivalent solution would do.</div><div><br></div><div>For reference, our SG implementation, currently is able to match on</div><div>combinations of:</div><div><br></div><div>* direction: ingress/egress</div><div>* protocol: icmp/tcp/udp/<raw number></div><div>* port_range: min-max (it’s always dst)</div><div>* L2 packet ethertype: IPv4, IPv6, etc...</div><div>* remote_ip_prefix: as a CIDR or * remote_group_id (to reference all other IPs in a certain group)</div><div><br></div><div>All of them assume connection tracking so known connection packets will</div><div>go the other way around.</div></div></blockquote><div><br></div><div>OK. All of those should work OK. (I don't know for sure whether we'll</div><div>have explicit groups; initially, probably not.)</div></div></div></span></blockquote><div><span style="font-size: 14px;">That makes sense.</span></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><div><div>Is the exponential explosion due to cross-producting, that is, because</div><div>you have, say, n1 source addresses and n2 destination addresses and so</div><div>you need n1*n2 flows to specify all the combinations? We aim to solve</div><div>that in OVN by giving the CMS direct support for more sophisticated</div><div>matching rules, so that it can say something like:</div><div> </div><div> ip.src in {<a>, <b>, <c>, ...} && ip.dst in {<d>, <e>, <f>, ...}</div><div> && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})</div></div></blockquote></blockquote><div><br></div><div>That sounds good and very flexible.</div><blockquote type="cite"><blockquote type="cite"><div><div> </div><div>and let OVN implement it in OVS via the "conjunctive match" feature</div><div>recently added, which is like a set membership match but more</div><div>powerful. </div></div></blockquote></blockquote><div>Hmm, where can I find examples about that feature, sounds interesting.</div></div></blockquote><div><br></div><div>If you look at ovs-ofctl(8) in a development version of OVS, such as</div><div> <a href="http://benpfaff.org/~blp/dist-docs/ovs-ofctl.8.pdf">http://benpfaff.org/~blp/dist-docs/ovs-ofctl.8.pdf</a></div><div>search for "conjunction", which explains the implementation. </div></div></div></span></blockquote><div><span style="font-size: 14px;">Amazing, yes, it seems like conjunctions will do the work quite optimally</span></div><div><span style="font-size: 14px;">at OpenFlow level.</span></div><div><br></div><div><span style="font-size: 14px;">My hat off… :)</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div> (This</div><div>isn't the form that Neutron would use with OVN; that is the Boolean</div><div>expression syntax above.)</div><div><br></div></div></div></span></blockquote><div><span style="font-size: 14px;">Of course, understood, I was curious about the low level supporting the</span></div><div><span style="font-size: 14px;">high level above.</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><div><div>It might still be nice to support lists of IPs (or</div><div>whatever), since these lists could still recur in a number of</div><div>circumstances, but my guess is that this will help a lot even without</div><div>that.</div><div> </div></div></blockquote></blockquote><div>As afar as I understood, given the way megaflows resolve rules via hashes</div><div>even if we had lots of rules with different ip addresses, that would be very fast,</div><div>probably as fast or more than our current ipset solution.</div><div><br></div><div>The only caveat would be having to update lots of flow rules when a port goes</div><div>in or out of a security group, since you have to go and clear/add the rules to each</div><div>single port on the same security group (as long as they have 1 rule referencing the sg).</div></div></blockquote><div><br></div><div>That sounds like another good argument for allowing explicit groups. I</div><div>have a design in mind for that but I doubt it's the first thing to</div><div>implement.</div></div></div></span></blockquote><div><span style="font-size: 14px;">Of course, 1 step at a time. I will do a 2nd pass on your documents, looking a bit</span></div><div><span style="font-size: 14px;">more on the higher level. I’m very happy to see that the low level is very well tied</span></div><div><span style="font-size: 14px;">up and capable.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">Best regards,</span></div><div><span style="font-size: 14px;">Miguel Ángel.</span></div><div> </div>
<div>
<br>
</div>