<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
Salvatore,
<div><br>
</div>
<div>The 80% distinction came from a discussion I had at summit, representing that the majority of features described by the current security groups could be implemented today with OVS without connection tracking. It’s not based on any mathematical calculation…
more of a pseudo-application of Pareto’s principle. :)</div>
<div><br>
</div>
<div>Correct, the OVS tcp_flags feature will be used to implement an emulated statefulness for TCP flows whereas non-TCP flows would use the source-port-range-min, source-port-range-max extended API to implement stateless flows.</div>
<div><br>
</div>
<div>Performance measurements would have to come after implementations are made for the proposed blueprint. Although, benchmarks of the two existing FirewallDriver implementations can be done today. We can measure number of concurrent connections until failure,
overall bandwidth as percentage of line rate, etc. Are there any other specific metrics you would like to see in the benchmark?</div>
<div><br>
</div>
<div>Amir</div>
<div><br>
<div>
<div>On Jun 3, 2014, at 2:51 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">I would like to understand how did we get to this 80%/20% distinction.
<div>In other terms, it seems conntrack's RELATED features won't be supported for non-tcp traffic. What about the ESTABLISHED feature? The blueprint specs refers to tcp_flags=ack.</div>
<div>Or will that be supported through the source port matching extension which is being promoted?<br>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">More comments inline.<br>
<br>
<div class="gmail_quote">On 3 June 2014 01:22, Amir Sadoughi <span dir="ltr"><<a href="mailto:amir.sadoughi@rackspace.com" target="_blank">amir.sadoughi@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>Hi all,</div>
<div><br>
</div>
In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us "80%" of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED
feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20%" difference more explicit to the operator and end user, we have proposed feature configuration to provide security
group rules API validation that would validate based on connection tracking ability, for example.</div>
</blockquote>
<div><br>
</div>
<div>I am stilly generally skeptic of API changes which surface backend details on user-facing APIs. I understand why you are proposing this however, and I think it would be good to get first an assessment of the benefits brought by such a change before making
a call on changing API behaviour to reflect security group implementation on the backend.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include:</div>
<div><span style="white-space:pre-wrap"></span>- marking ovs-firewall-driver as experimental in Juno</div>
<div><span style="white-space:pre-wrap"></span>- What does it mean to be marked as “experimental”?</div>
</div>
</blockquote>
<div><br>
</div>
<div>In this case experimental would be a way to say "not 100% functional". You would not expect a public service provider exposing neutron APIs backed by this driver, but maybe in some private deployments where the missing features are not a concern it could
be used.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><span style="white-space:pre-wrap"></span>- performance improvements under a new OVS firewall driver untested so far (vthapar is working on this)</div>
</div>
</blockquote>
<div><br>
</div>
<div>From the last comment in your post it seems you already have proof of the performance improvement, perhaps you can add those to the "Performance Impact" section on the spec.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><span style="white-space:pre-wrap"></span>- incomplete implementation will cause confusion, educational burden</div>
</div>
</blockquote>
<div><br>
</div>
<div>It's more about technical debt in my opinion, but this is not necessarily the case.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><span style="white-space:pre-wrap"></span>- debugging OVS is new to users compared to debugging old iptables</div>
</div>
</blockquote>
<div><br>
</div>
<div>This won't be a concern as long as we have good documentation to back the implementation.</div>
<div>As Neutron is usually sloppy with documentation - then it's a concern.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><span style="white-space:pre-wrap"></span>- waiting for upstream OVS to implement (OpenStack K- or even L- cycle)</div>
<div><br>
</div>
<div>In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today. </div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>Amir</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a href="http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html</a></div>
<div>[1] <a href="https://review.openstack.org/#/c/89712/" target="_blank">https://review.openstack.org/#/c/89712/</a></div>
<div>[2] <a href="http://openvswitch.org/pipermail/dev/2014-May/040567.html" target="_blank">http://openvswitch.org/pipermail/dev/2014-May/040567.html</a></div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>