Nuage Networks recently participated in the Software Defined Infrastructure showcase at Interop Tokyo, and I had the privilege of giving a Keynote address on a Policy Driven Approach to Software Defined Networking (https://bit.ly/sdn-policy-abstraction). It was a very enjoyable experience, and through my conversations I found that customers are very interested in Software Defined Networking and Network Virtualization solutions (duh!). But as we start to move past the hype of SDN, customers are pushing for a clear message of why SDN matters, and what new approaches to networking are really enabled by taking advantage of Network Virtualization and SDN.
We at Nuage have been talking about the concept of Policy Driven networking since the beginning of our adventure in this space. What is “Policy Driven Networking,” you ask? I think the following bullets from the OpenStack “Group Based Policy Abstractions for Neutron” blueprint are a good definition:
- An Application-centric approach to networking
- Moving away from traditional network constructs (ports, subnets, routers, etc)
- Aiming for a highly abstracted interface for application developers to express desired connectivity of application components and express high-level policies governing that connectivity
- Without imposing constraints on the underlying implementation
So at a high level, the idea is that we remove the burden of the “network design” from the actual instantiation of a network service.
Let’s take a look at how a network is viewed in OpenStack Neutron. Today, an OpenStack user has many of the building blocks available to them to create logical network topologies. You can define things like Networks, Ports, Subnets, Routers, and Security Groups through simple calls to the OpenStack Neutron engine. This is very good, as I can then define a network topology to match my application’s requirements. This logical topology would look something like this:
But who is the user in a typical OpenStack (or any other cloud) environment? Well normally it’s a DevOps engineer, not a network architect. The DevOps teams are very smart system and application designers and admins, but they’re not necessarily experts in network architectures. So when I hand off these network “building blocks” to the DevOps team, I’m actually burdening them with far more detail then they may want to deal with. I’m not abstracting the network topology into a simple, consumable network service.
What the DevOps teams do understand is their applications, and how the components of their applications need to communicate. They understand how they want to group servers together, and how like applications need to be isolated from other elements. But they don’t necessarily care how that grouping and segmentation is accomplished. Their view is more like this:
So a Policy approach to networking is the concept of providing network templates (or Policies) that are designed by network and security teams, through collaboration with the DevOps team. These templates are then deployed in an automated fashion when the application is deployed into the infrastructure. There is manual process when the templates are defined and created (obviously). Then these templates are assigned to cloud users, groups, or applications. When the DevOps team deploys an application, that DevOps user identity is evaluated and matched to one of these previously defined templates (without human intervention), is converted into a specific network configuration (including IP addressing, security rules, routes, etc), and is automatically deployed into the network to create the required network services to support that application. This network service provides all of the required connectivity without forcing the DevOps team to manage all of then networking details each time they deploy an application.
This model of pre-defining a template is actually analogous to how we write applications. In an app development world we…
- Create source code that defines the application
- Map that source code to machine code by compiling the source into an executable application
- Bind that executable application onto a compute platform at runtime, only then assigning the specific compute attributes (memory registers, CPU’s, etc)
So in a Policy based networking model we would
- Create a template that defines the application’s network service requirements and business rules
- Map that template into a network service definition
- Implement that service definition onto the network, assigning the specific network attributes (IP addresses, ACL’s, routes, etc) when the application is deployed
Nuage Networks has been delivering on a Policy Driven approach to networking all along, and truly believe that this is the right way to approach the delivery of network services. And because the delivery method of network services is often through a cloud system such as OpenStack, we are committed to the community efforts happening in this area. We are actively involved in the OpenStack Neutron project, and are participating in the development of the “Group Based Policy Abstractions for Neutron” that I mentioned earlier. You can read all about this blueprint and the associated development activity here. We’re excited to report that this functionality will be available in the OpenStack Juno release, and look forward to working with the community to enhance these features in the future.
Reach me on Twitter: @ssneddon
Thanks for reading!