Welcome!

Java Authors: Roger Strukhoff, Pat Romanski, Elizabeth White, Mark Cravotta, Liz McMillan

Related Topics: SDN Journal, Java, SOA & WOA, Linux, Open Source, Virtualization

SDN Journal: Blog Post

Changing the Way We Configure and Provision Our Networks

In enterprises we have never really made a big distinction between configuration and provisioning

Some people believe good or bad things always happen in threes. I believe you will always be able to find three (and probably more) things that are good or bad and somewhat related, but sometimes I get surprised by the apparent coincidental appearance of several closely related “things”. Last week the folks at networkheresy.com posted a second installment of their “policy in the datacenter” discussion, Cisco announced the acquisition of tail-f and internal to Plexxi we had several intense architectural discussions around Configuration, Provisioning and Policy management. Maybe we can declare June CP&P month for networking.

It is mostly accepted that configuration deals with the deployment of devices and applications within an infrastructure. For network devices, it covers the portions of creating a fabric, protocols to maintain this fabric, access and control to the device itself, management connectivity etc. Once a network device is configured, it is a functioning element in a network.

Provisioning is more a telco term, focused on creating the customer facing end of a device of applications. For network devices, this would cover ports that are facing customer or end devices, the edge protocols required, VLANs, IP subnets, etc.

Lastly, policy defines a level of communication service that is created across the configured infrastructure through the attached provisioned interfaces. It defines what communication is allowed and not allowed and with what specific service and service levels.

In enterprises we have never really made a big distinction between configuration and provisioning. But with the evolution to a virtualized infrastructure and more rapid client facing changes as a result of VM creation and movement, I believe the two have enough differences that it makes sense to adopt this separation more broadly.

I catch myself using them interchangeably at times, but there are very distinct differences between them, even if all of them end up as a set of instructions to a switch or set of switches, physical or virtual. The types of instructions are different for each type, the folks responsible for their functionality are different, and the rate of change is different.

More importantly though, the mechanism by which we instruct our network components is rapidly changing. The complexity of the configuration and policy components and the sheer volume and rate of change of the provisioning component is driving more automated methods of instructing our network elements what to do. We have long ago adopted centralized database driven CP&P systems in most our world.

Except for networking. A very large majority of instructions for network devices is still hand crafted, or script-assisted hand crafted. And the entirety of the instruction set for these devices lives on the switches itself. For which we have then created systems that capture and archive them for backup purposes and forensics. When something goes wrong with the device, we go find the latest backup we have and attempt to restore the service.

But this is all changing. Finally. Newer network solutions use centralized systems that have real databases behind them to power the information that needs to be stored, shared, backed up, check pointed, logged, replicated and all the other good stuff real databases have solved for many years.

The biggest hump we need to get past is one of control. Regardless of where or how CP&P data is stored, the more important question is who controls the data. Even if this data is stored on a v- or pSwitch, that same switch should not be the master of that information any longer. There are portions of CP&P information that have network wide meaning and should be specified in a network wide manner. Today we manually construct network wide provisioning or policy semantics. We have to get to a point where we define these in network wide terms and let our tools worry about what that means for the individual network elements that create the service.

We started this a few years ago with abstracted policies we call Affinities. Policies that are defined network wide, without any specificity to location or what elements to apply the policy to. In Plexxi Control, similar concepts exist for some of the provisioning: certain types of data we consider global, they are used and applied network wide without you worrying what elements it applies to.

Centralized or federated CP&P provides huge benefits and potential. All the backend tools exist to make this safe, replicated, audited and logged, better so than any legacy network system. If only we can get our minds past the change in control and not expect the element to be the master source of its data. It is one of the many things we need to accept to allow the network to change.

The post Changing the way we configure and provision our networks appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.