[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

loy wolfe loywolfe at gmail.com
Tue Aug 12 08:22:25 UTC 2014


Hi Paul,

Below are some other useful GBP reference pages:
https://wiki.opendaylight.org/view/Project_Proposals:Group_Based_Policy_Plugin
http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html

I think the root cause of this long argument, is that GBP core model was
not designed native for Neutron, and they are introduced into Neutron so
radically, without careful tailoring and adaption. Maybe the GBP team also
don't want to do so, their intention is to maintain a unified model across
all kinds of platform including Neutron, Opendaylight, ACI/Opflex, etc.

However, redundancy and duplication exists between EP/EPG/BD/RD and
Port/Network/Subnet. So mapping is used between these objects, and I think
this is why so many voice to request moving GBP out and on top of Neutron.

Will GBP simply be an *addition*? It absolutely COULD be, but objectively
speaking, it's core model also allow it to BE-ABLE-TO take over Neutron
core resource (see the wiki above). GBP mapping spec suggested a nova -nic
extension to handle EP/EPG resource directly, thus all original Neutron
core resource can be shadowed away from user interface: GBP became the new
openstack network API :-) However no one can say depreciate Neutron core
here and now, but shall we leave Neutron core just as *traditional/legacy*?

Personally I prefer not to throw NW-Policy out of Neutron, but at the
perquisite that its core model should be reviewed and tailored. A new
lightweight model carefully designed native for Neutron is needed, but not
directly copying a whole bunch of monolithic core resource from existing
other system.

Here is the very basic suggestion: because core value of GBP is policy
template with contracts , throw away EP/EPG/L2P/L3P model while not just
renaming them again and again. APPLY policy template to existing Neutron
core resource, but not reinvent similar concept in GBP and then do the
mapping.


On Mon, Aug 11, 2014 at 9:12 PM, CARVER, PAUL <pc2929 at att.com> wrote:

>    loy wolfe [mailto:loywolfe at gmail.com] wrote:
>
>
>
> >Then since Network/Subnet/Port will never be treated just as LEGACY
>
> >COMPATIBLE role, there is no need to extend Nova-Neutron interface to
>
> >follow the GBP resource. Anyway, one of optional service plugins inside
>
> >Neutron shouldn't has any impact on Nova side.
>
>
>
> This gets to the root of why I was getting confused about Jay and others
>
> having Nova related concerns. I was/am assuming that GBP is simply an
>
> *additional* mechanism for manipulating Neutron, not a deprecation of any
>
> part of the existing Neutron API. I think Jay's concern and the reason
>
> why he keeps mentioning Nova as the biggest and most important consumer
>
> of Neutron's API stems from an assumption that Nova would need to change
>
> to use the GBP API.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140812/ba2db185/attachment.html>


More information about the OpenStack-dev mailing list