OpenStack Series: Part 20 - Group-based Policy for Neutron

Group-based Policy is a new feature in OpenStack and is still in its infant state.  There is a page on this subject in the OpenStack wiki but not much information on what this feature is about. 

For 4 years I have developed and enhanced a feature on the Alcatel-Lucent Enterprise switch for a policy based network access control for network traffic.  I have with 3 other engineers submitted a patent in this area waiting for approval.  This is why I am particular interested to look into this Group-base Policy that is in OpenStack.  Actually, this also made it way into the SDN Controller OpenDaylight project.

This feature is supported by quite a few IT equipment vendors such as Cisco, Alcatel-Lucent (unfortunately I am not with this division such that I can work on this interesting project), Big Switch Network, Juniper, IBM, Red Hat and even Intel.

The main goal for Group-based policy is to provide support and abstraction for the application that is running on the OpenStack Infrastructure.

The whole idea is to provide an abstraction layer for the application so that it does not need to know the detail of the how the infrastructure that it is running on.   It is to use a declarative language to capture the intent of the application.  At this time the Group-based Policy is mainly for Neutron but it can also be developed to be applied to compute and storage.

Note: Declarative is an important concept. It is to defined the desired end state of a server or an infrastructure.  The popular Configuration Management Tool Puppet is a declarative language.  I have talked about OpenStack Congress and it is also a declarative model.

Currently the Neutron API is powerful in providing an abstraction to provide a logical network.  However, there is one drawback - it is very network-centric and user has to be very knowledgeable in networking.  The API may be a set of powerful API for network engineer but it may be too much for an application developer or operator to handle.

According to the OpenStack Documentation, Group-base Policy is to provide a intent-driven declarative policy model that presents simplified application-oriented interfaces to the user.

Application-oriented - Does this sound familiar?  For me I immediately think of the Cisco version of SDN (Software Defined Network) - Application Centric Infrastructure (ACI).  Of course, the APIC driver is part of Neutron's ML2 mechanism module.  ACI by itself is a big topic to be discussed.  I will most likely look into this in the near future as part of my quest to the cloud related technology.  When I look into this subject of Group-based Policy, I find the most informative information comes from Cisco's blog and/or white paper.  I think Cisco contribute to this Group-based policy feature and is driving the advancement of this feature as well.

While I think even Cisco is driving the advancement and acceptance of Group-based Policy, it has it value and is not a feature that is pushed by a vendor for their sole benefits in this case Cisco and ACI.

Group-based Policy Architecture

image source: http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-733126.doc/_jcr_content/renditions/white-paper-c11-733126_0.jpg

I found that this Cisco white paper is a very good description of the Group-base Policy's architecture.  There are 4 main concepts that are essential to Group-based Policy:

• Groups: network endpoints are put together in a group and the properties of the endpoints are treated as a whole.
• Policy Rule Set: This describe how the groups are connected together
• Policy Layering: Policy can be layered on top of each  other forming a new/combined policy.
• Network Service Chaining: This is an important concept in NFV (Network Function Virtualization). Group-base Policy allows applications to define their requirements on how the packet flows.

According to the Cisco white paper, this Group-base policy has the following advantages:

• Automation and security are much easier to implement through Group-Based Policy.
• Offers a naturally flexible and extensible framework for capturing the requirements of a virtual machine in a single location.
• Makes consistency easier to achieve because only one step - becoming a member of the group - is required to inherit multiple policies 
• Easy for application developers to use and offers them a simple way to describe application requirements 
• Offers a means for allowing operator and user requirements to coexist cleanly 

Group-based Policy and OpenStack

image source: http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-733126.doc/_jcr_content/renditions/white-paper-c11-733126_2.jpg

Also, according to the same Cisco white paper, Group-based policy is supposed to fit into OpenStack in a "non-disruptive" layer.  I take it as not or minimum changes is need in OpenStack.  When we look at the diagram above Group Policy is the orange layer and conceptually this is how it fits into the OpenStack.  We can see the Horizon and Heat module along with the OpenStack CLI sitting on top for configuration (manual or via a Heat Template).  The next layer is the application in which all our focus are in to making the deployment of application as easy as possible without have to "worry" about the supporting infrastructure.  Below the Group Policy layer are the other various OpenStack projects. At this time it is mainly focused on Networking.

Group-based Policy and OpenStack Congress
On the SDN front, we see that VMware and Cisco are going the opposite direction.  OpenStack Congress is heavily driven by VMware while Group-based Policy is heavily driven by Cisco.  Will the same thing happen here where the 2 technologies are competing with each other?

It seems that Congress covers governance and compliance while Group-based policy is to capture the application's intent and to provide an abstraction layer.  These 2 things compliment each other and is providing different services to the OpenStack users.


Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 17: Congress - Policy Service  
OpenStack Series Part 18: Network Function Virtualization in OpenStack 
OpenStack Series Part 19: Storage policies for object storage

Reference:
"GroupBasedPolicy." - OpenStack. N.p., n.d. Web. 09 Nov. 2014.