Jay Pipes <jaypi...@gmail.com> wrote on 08/06/2014 04:09:20 PM:
> From: Jay Pipes <jaypi...@gmail.com>
> To: email@example.com
> 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
> > 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
> > 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
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
> OpenStack-dev mailing list
OpenStack-dev mailing list