<html><body>
<p><tt><font size="2">Jay Pipes <jaypipes@gmail.com> wrote on 08/06/2014 04:09:20 PM:<br>
<br>
> From: Jay Pipes <jaypipes@gmail.com></font></tt><br>
<tt><font size="2">> To: openstack-dev@lists.openstack.org</font></tt><br>
<tt><font size="2">> Date: 08/06/2014 04:12 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy <br>
> and the way forward</font></tt><br>
<tt><font size="2">> <br>
> On 08/06/2014 03:46 PM, Kevin Benton wrote:<br>
> > >I believe the referential security group rules solve this problem<br>
> > (unless I'm not understanding):<br>
> ><br>
> > I think the disconnect is that you are comparing the way to current<br>
> > mapping driver implements things for the reference implementation with<br>
> > the existing APIs. Under this light, it's not going to look like there<br>
> > is a point to this code being in Neutron since, as you said, the<br>
> > abstraction could happen at a client. However, this changes once new<br>
> > mapping drivers can be added that implement things differently.<br>
> ><br>
> > Let's take the security groups example. Using the security groups API<br>
> > directly is imperative ("put a firewall rule on this port that blocks<br>
> > this IP") compared to a higher level declarative abstraction ("make sure<br>
> > these two endpoints cannot communicate"). With the former, the ports<br>
> > must support security groups and there is nowhere except for the<br>
> > firewall rules on that port to implement it without violating the user's<br>
> > expectation. With the latter, a mapping driver could determine that<br>
> > communication between these two hosts can be prevented by using an ACL<br>
> > on a router or a switch, which doesn't violate the user's intent and<br>
> > buys a performance improvement and works with ports that don't support<br>
> > security groups.<br>
> ><br>
> > Group based policy is trying to move the requests into the declarative<br>
> > abstraction so optimizations like the one above can be made.<br>
> <br>
> So, in short, GBP is an effort to provide an API that substitutes <br>
> generic names for specific names in order to allow custom proprietary <br>
> hardware vendors to wire in their hardware using an API that better <br>
> matches their own internal modelling.<br>
> <br>
> Would that be a good statement of the end-goal of GBP?<br>
> <br>
</font></tt><br>
<tt><font size="2">No. That would be incorrect. </font></tt><br>
<tt><font size="2">If you have the time, please see the following article. Even though it is more than a year old, it may help in clarifying the intent of the policy work.</font></tt><br>
<br>
<tt><font size="2">M. Banikazemi, D, Olshefski, A. Shaikh, J. Tracey, G. Wang, "Meridian: an SDN platform for cloud network services", IEEE Communications Magazine, vol. 51, no. 2, February 2013</font></tt><br>
<br>
<a href="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6461196"><tt><font size="2">http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6461196</font></tt></a><br>
<br>
<tt><font size="2">Best,</font></tt><br>
<br>
<tt><font size="2">-Mohammad</font></tt><br>
<tt><font size="2"> </font></tt><br>
<br>
<tt><font size="2">> -jay<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>