<div dir="ltr">By working at the port level you have already eliminated your ability to implement the filtering at different components of the network. They now need to be implemented in stateful rules at the port level and the device has to support security groups.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen <span dir="ltr"><<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">I believe the referential security group rules solve this problem (unless I'm not understanding): </span><div>


<span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>

</span></div></div><div>I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference implementation with the existing APIs. Under this light, it's not going to look like there is a point to this code being in Neutron since, as you said, the abstraction could happen at a client. However, this changes once new mapping drivers can be added that implement things differently.</div>




<div><br></div><div>Let's take the security groups example. Using the security groups API directly is imperative ("put a firewall rule on this port that blocks this IP") compared to a higher level declarative abstraction ("make sure these two endpoints cannot communicate"). With the former, the ports must support security groups and there is nowhere except for the firewall rules on that port to implement it without violating the user's expectation. With the latter, a mapping driver could determine that communication between these two hosts can be prevented by using an ACL on a router or a switch, which doesn't violate the user's intent and buys a performance improvement and works with ports that don't support security groups.</div>




<div><br></div><div>Group based policy is trying to move the requests into the declarative abstraction so optimizations like the one above can be made.</div></div></blockquote><div><br></div></div></div><div>Hi Kevin, </div>

<div><br>
</div><div>Interesting points. Though, let me ask this. Why do we need to move to a declarative API abstraction in neutron in order to perform this optimization on the backend? For example, In the current neutron model say we want to create a port with a security group attached to it called web that allows TCP:80 in and members who are in a security group called database. >From this mapping I fail to see how it's really any different from the declarative model? The ports in neutron are logical abstractions and the backend system could be implemented in order to determine that the communication between these two hosts could be prevented by using an ACL on a router or switch as well.</div>

<div class="">
<div><br>Best, </div><div><br></div><div>Aaron</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div><br></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><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>