Cloud policy – Congress and Opflex

Recently, I saw a lot of press on Cisco’s Opflex protocol that allows a declarative policy model to control a physical or virtual device. There were discussions around if the Opflex protocol would replace Ovsdb and Openflow. Within Openstack, there is a new project called Congress that allows for creating a policy framework within Openstack. This blog is my attempt to get into more details on Congress and Opflex and explain the relationship between them. This is mostly information gathered from different references that I have listed in the end.


Congress is a new Openstack project that is used to enforce compliance within the cloud environment. The end goal would be to integrate Congress with other cloud orchestration software as well. Compliance could be needed because of Government regulations, contracts between organizations, SLA enforcement etc. Following picture illustrates the need for Congress.


The policy needs to be applied across different cloud resources like Compute, Network and Storage. In the current scheme of things, policies are applied by breaking the policy into smaller constructs and applying the policy in different layers separately. Since the policies are applied using low level constructs with different entities and not in a centralized location, it is difficult to maintain the policies. The goal of Congress is to specify the policy using a high-level language and create translation layer to the different constructs in Nova, Neutron, Keystone etc.

Following picture illustrates high level block diagram of Congress:


Policies are stored in Policy file and Congress takes the policies from Policy store and enforces them across the Cloud components. There is also a feedback loop from the different cloud components so that Congress can take dynamic decisions on the fly. There could be different approaches for dealing with violations. Following are some use cases provided in the Congress wiki page:

  • Application A is only allowed to communicate with application B.
  • Virtual machine owned by tenant A should always have a public network connection if tenant A is part of the group B.
  • Virtual machine A should never be provisioned in a different geographic region than storage B.


Opflex is a protocol proposal from Cisco, Citrix, IBM, Microsoft and few other companies that describes the language of communication between the policy management engine and the policy element. Currently, its a IETF proposal. Opflex is based on a declarative model where the policy specifies the end goal but does not specify how the end goal needs to be established. This is in contrast to the imperative model where the policy controller specifies how the end goal needs to be established in detail. As I understood, declarative model allows for a scalable approach.

Following picture from the blog illustrates the Opflex model.


In the above figure, Opflex is used between the Policy authority and Opflex policy agent. Opflex policy agent resides within physical or virtual device. As explained in the blog, Opflex does not remove the need for Openflow or ovsdb since these protocols are needed to breakdown the policy into a language that the host can understand.

There are currently 2 projects ongoing in Openstack, Opendaylight related to Opflex. First is the group policy model that allows for specifying application’s networking requirements using a policy based model. This is the core of Cisco’s ACI model. The second is the Opflex protocol implementation that will integrate with Open vswitch. Following block diagram illustrates the overall project detail.


Following are some notes regarding the picture above:

  • In the group based policy model, application is split into different groups and the policies between the different groups are represented as contracts. For example, a 3 tier application can be split into web, application and database groups and the policies between these groups can be represented as contracts. Contracts can be enforced using hardware or software appliances like firewall, load balancer etc.
  • Openstack will pass the group based policy information through Neutron to Opendaylight and Opendaylight will use Opflex to send the policy to physical or virtual devices.
  • Opflex agent on the device will use Openflow, Ovsdb to program the Open vswitch.

Comparing Opflex with Congress:

  • Congress aims at creating policy for the complete cloud infrastructure that includes compute, storage and networking. Opflex on the other hand seems to be more focussed on the networking aspects of the cloud.
  • Initial focus of Congress seems to be targeted at Compliance enforcement policy model while Opflex along with Group based policy seems like a new way of configuring application networking requirements.
  • Opflex uses a declarative model, not clear about Congress.
  • How Congress and Opflex will work together in the long run is not clear. 1 possibility is Congress enforcing policies for the complete cloud infrastructure while Opflex enforces policies at the networking level. This model of separation already exists today where Openstack manages complete cloud infrastructure and Openstack using Opendaylight through Neutron layer to manage the Networking aspects.


Pictures used in the above blog are from the references.

One thought on “Cloud policy – Congress and Opflex

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s