Open Stack

Hi,

I've made my way through the group based policy code and blueprints and I'd
like ask several questions about it.  My first question really is what is
the advantage that the new proposed group based policy model buys us?


Bobs says, "The group-based policy BP approved for Juno addresses the
> critical need for a more usable, declarative, intent-based interface for
> cloud application developers and deployers, that can co-exist with
> Neutron's current networking-hardware-oriented API and work nicely with all
> existing core plugins. Additionally, we believe that this declarative
> approach is what is needed to properly integrate advanced services into
> Neutron, and will go a long way towards resolving the difficulties so far
> trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
> model."

My problem with the current blueprint and that comment above is it does not
provide any evidence or data of where the current neutron abstractions
(ports/networks/subnets/routers) provide difficulties and what benefit this
new model will provide.

In the current proposed implementation of group policy, it's implementation
maps onto the existing neutron primitives and the neutron back end(s)
remains unchanged. Because of this one can map the new abstractions onto
the previous ones so I'm curious why we want to move this complexity into
neutron and not have it done externally similarly to how heat works or a
client that abstracts this complexity on it's own end.

>From the group-based policy blueprint that was submitted [1]:


The current Neutron model of networks, ports, subnets, routers, and security
> groups provides the necessary building blocks to build a logical network
> topology for connectivity. However, it does not provide the right level
> of abstraction for an application administrator who understands the
> application's details (like application port numbers), but not the
> infrastructure details likes networks and routes.

It looks to me that application administrators still need to understand
network primitives as the concept of networks/ports/routers are still
present though just carrying a different name. For example, in
ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
that you use to describe a l2_network and contains an attribute
l3_policy_id which is used to describe an L3 network. This looks similar to
the abstraction we have today where a l2_policy (network) then can have
multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
how the GBP abstraction really provides a different level of abstraction
for application administrators.


 Not only that, the current
> abstraction puts the burden of maintaining the consistency of the network
> topology on the user. The lack of application developer/administrator
> focussed
> abstractions supported by a declarative model make it hard for those users
> to consume Neutron as a connectivity layer.

What is the problem in the current abstraction that puts a burden of
maintaining the consistency of networking topology on users? It seems to me
that the complexity of having to know about topology should be abstracted
at the client layer if desired (and neutron should expose the basic
building blocks for networking). For example, Horizon/Heat or the CLI could
hide the requirement of topology by automatically creating a GROUP  (which
is a network+subnet on a router uplinked to an external network)
simplifying this need for the tenant to understand topology. In addition,
topology still seems to be present in the group policy model proposed just
in a different way as I see it.

>From the proposed change section the following is stated:


This proposal suggests a model that allows application administrators to
> express their networking requirements using group and policy abstractions,
> with
> the specifics of policy enforcement and implementation left to the
> underlying
> policy driver. The main advantage of the extensions described in this
> blueprint
> is that they allow for an application-centric interface to Neutron that
> complements the existing network-centric interface.


How is the Application-centric interface complementary to the
network-centric interface?  Is the intention that one would use both
interfaces at one once?

More specifically the new abstractions will achieve the following:
> * Show clear separation of concerns between application and infrastructure
> administrator.
>

I'm not quite sure I understand this point, how is this different than what
we have today?


> - The application administrator can then deal with a higher level
> abstraction
> that does not concern itself with networking specifics like
> networks/routers/etc.
>

It seems like the proposed abstraction still requires one to concern
themselves with networking specifics (l2_policies, l3_policies).  I'd
really like to see more evidence backing this. Now they have to deal with
specifies like: Endpoint, Endpoint Group, Contract, Policy Rule,
Classifier, Action, Filter, Role, Contract Scope, Selector, Policy Label,
Bridge Domain, Routing Domain...


> - The infrastructure administrator will deal with infrastructure specific
> policy abstractions and not have to understand application specific
> concerns
> like specific ports that have been opened or which of them expect to be
> limited to secure or insecure traffic. The infrastructure admin will also

have ability to direct which technologies and approaches used in rendering.
> For example, if VLAN or VxLAN is used.
>

How is this different from what we have now? Today in neutron the
infrastructure administrator deals with infrastructure specific policy
abstractions i.e external networks (networks that uplink to the physical
world) and do not have to understand any specific connectivity concerns of
the application as mentioned is provided in this model. Since the beginning
neutron has always given the ability for infra admins to decide which
back-end technologies are used VXLAN/VLAN/etc which are abstracted away
from the tenant.

- Allow the infrastructure admin to introduce connectivity constraints
> without the application administrator having to be aware of it (e.g. audit
> all traffic between two application tiers).
>

I think this is a good point and see how this works in the Group Based
Policy abstractions that are proposed. That said, I think there are other
ways to provide this type of interface rather redefining the current
abstractions. For example, providing additional attributes on the existing
primitives (ports/networks/router) to get this information. Or similarly
how the LBaaS/Security Group API was implemented providing a grouping
concept.



> * Allow for independent provider/consumer model with late binding and
> n-to-m
> relationships between them.
>

Same points as above. I still don't understand how changing this model
provides us anything different (or advantage) that we already have/(or can)
today. Also, reading through the current model it seems like it ties the
bindings to endpoint-groups (networks) rather than endpoints (ports) which
seems like a restriction we'd like to avoid. What I mean by this is it
looks like security groups are now mapped to networks rather than ports
requiring one to break an application up on to different networks (which we
do not require today).


> * Allow for automatic orchestration that can respond to changes in policy
> or
> infrastructure without requiring human interaction to translate intent to
> specific actions.


I'd be curious to hear more about this and how changing the abstractions
today makes this easier. How does the automatic orchestration work? There
is actually a heat blueprint that talks about getting infrastructure to
desired state without human interaction (which is able to do this without
changing any of the abstractions in neutron/nova)  -
https://review.openstack.org/#/c/95907/

 Another concern is that the new API provides several new constructs I
think users will have difficultly understanding:

The following new terminology is being introduced:
> **Endpoint (EP):** An L2/L3 addressable entity.
> **Endpoint Group (EPG):** A collection of endpoints.
> **Contract:** It defines how the application services provided by an EPG
> can be
> accessed. In effect it specifies how an EPG communicates with other EPGs. A
> Contract consists of Policy Rules.
> **Policy Rule:** These are individual rules used to define the
> communication
> criteria between EPGs. Each rule contains a Filter, Classifier, and Action.
> **Classifier:** Characterizes the traffic that a particular Policy Rule
> acts on.
> Corresponding action is taken on traffic that satisfies this classification
> criteria.
> **Action:** The action that is taken for a matching Policy Rule defined in
> a
> Contract.
> **Filter:** Provides a way to tag a Policy Rule with Capability and Role
> labels.
> **Capability:** It is a Policy Label that defines what part of a Contract a
> particular EPG provides.
> **Role:** It is a Policy Label that defines what part of a Contract an EPG
> wants
> to consume.
> **Contract Scope:** An EPG conveys its intent to provide or consume a
> Contract
> (or its part) by defining a Contract Scope which references the target
> Contract.
> **Selector:** A Contract Scope can define additional constraints around
> choosing
> the matching provider or consumer EPGs for a Contract via a Selector.
> **Policy Labels:** These are labels contained within a namespace hierarchy
> and
> used to define Capability and Role tags used in Filters.
> **Bridge Domain:** Used to define a L2 boundary and impose additional
> constraints (such as no broadcast) within that L2 boundary.
> **Routing Domain:** Used to define a non-overlapping IP address space.



I was also not able to find out how policy labels, selector, capabilities,
filters, and roles are used and how they work (I haven't found patches yet
that use these either).

Lastly, I believe the neutron API was built with the desire of simplicity
and providing an abstraction that represents how networks works (similar to
nova for servers). It provides the basic building block to allow one to
implement any networking concept or orchestration they desire on top of it.
I think this speaks to the point that the API we have today is flexible
enough for the concept of group policy to be mapped directly on top of it.
 I do see the benefit for a higher level abstraction though I don't really
understand the benefit that this new model buys us. I look forward to
continuing this discussion.

Best,

Aaron

[1] -
https://github.com/openstack/neutron-specs/blob/master/specs/juno/group-based-policy-abstraction.rst

On Wed, Aug 6, 2014 at 11:04 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/06/2014 04:30 AM, Stefano Santini wrote:
>
>> Hi,
>>
>> In my company (Vodafone), we (DC network architecture) are following
>> very closely the work happening on Group Based Policy since we see a
>> great value on the new paradigm to drive network configurations with an
>> advanced logic.
>>
>> We're working on a new production project for an internal private cloud
>> deployment targeting Juno release where we plan to introduce the
>> capabilities based on using Group Policy and we don't want to see it
>> delayed.
>> We strongly request/vote to see this complete as proposed without such
>> changes to allow to move forward with the evolution of the network
>> capabilities
>>
>
> Hi Stefano,
>
> AFAICT, there is nothing that can be done with the GBP API that cannot be
> done with the low-level regular Neutron API.
>
> Further, if the Nova integration of the GBP API does not occur in the Juno
> timeframe, what benefit will GBP in Neutron give you? Specifics on the
> individual API calls that you would change would be most appreciated.
>
> Thanks in advance for your input!
> -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/401d4709/attachment.html>