[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward
Mohammad Banikazemi
mb at us.ibm.com
Wed Aug 6 20:34:19 UTC 2014
Jay Pipes <jaypipes at gmail.com> wrote on 08/06/2014 04:09:20 PM:
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Date: 08/06/2014 04:12 PM
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
> and the way forward
>
> On 08/06/2014 03:46 PM, Kevin Benton wrote:
> > >I believe the referential security group rules solve this problem
> > (unless I'm not understanding):
> >
> > 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.
> >
> > 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.
> >
> > Group based policy is trying to move the requests into the declarative
> > abstraction so optimizations like the one above can be made.
>
> So, in short, GBP is an effort to provide an API that substitutes
> generic names for specific names in order to allow custom proprietary
> hardware vendors to wire in their hardware using an API that better
> matches their own internal modelling.
>
> Would that be a good statement of the end-goal of GBP?
>
No. That would be incorrect.
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.
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
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6461196
Best,
-Mohammad
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/0d568225/attachment.html>
More information about the OpenStack-dev
mailing list