The SDN Chicken and the Standardization Egg

#SDN Which came first?

Pundits, owing to SDN still being very young and not widely adopted, continue to put forth treatise upon treatise as to why organizations should be falling over themselves to go out and get themselves some SDN. Now. Not tomorrow, today.

One of the compelling reasons to adopt is to address a variety of operational issues that arise from complexity and differentiation in network elements. The way SDN addresses this - as do a variety of other options - is standardization. Note this is standardization with a little "s", not the capital "S" that might imply industry-agreed-upon-and-given-an-RFC standardization.

The claim is simple: organizations have a whole lot of various standalone appliances in their network serving a variety of purposes. Load balancing, firewalls, IDS/IPS, application acceleration, and even identity and access control. All these individual appliances are (generally) from different vendors, each requiring their own management console, their own policy formats, their own.... everything.

The argument goes that if you take all those services and deploy them as services on a (common) network operating system, you'll reduce complexity and all the associated management (operational) overhead. Rainbows will sprout from the network and unicorns will dance merrily from node to node while sprinkling happy dust on your engineers and operators.

Okay, maybe the rainbows and unicorns aren't part of the promise, but the nirvana implied by this consolidation on a standardized (common) network operating system is.

Now, I'm not saying this isn't true. It could be*. You can get standardization (theoretically, at least) from SDN at the upper layers of the stack, but it isn't SDN itself that elevates the data center to a level closer to operational nirvana, it's the standardization on a common platform. SDN is (theoretically) just one path to achieve that standardization.

The Layer 4-7 Landscape

The reason achieving this is more difficult than it sounds is that there are far more functions at layer 4-7 that need to be "standardized". Organizations do, in fact, end up with a hodge-podge of appliances deployed to support all the various layer 4-7 services required. Let me illustrate with a diagram (that is itself incomplete. There are a whole lot of services that go in the "layer 4-7 category"):

Are organizations struggling with the proliferation of devices at layer 4-7? Absolutely. I've heard stories of folks with 20 or more different vendors operating at layer 4-7 in their network. Not kidding. And every day, every new challenge brings another new solution to the table. Mobility and cloud - not to mention security - are driving the identification of new problems and challenges which in turn drives the proliferation of new solutions that often (though not always) come in the form of a nice, neat box to deploy in the network.

The way in which this proliferation (and its associated overhead) can be effectively addressed is through standardization. That doesn't require SDN, though SDN may be one way in which such standardization is achieved. Standardization - or more apropos - the consolidation of application (that's layer 4-7) network services onto a common platform is what brings that benefit.

* It could be if we ever figure out how to deploy said services in such an architecture without forcing the controller to be part of the data path.

Published Feb 24, 2014

Version 1.0

management

sdas

sdn

1 Comment

rjhintz_145665
Nimbostratus
Feb 26, 2014
“The argument goes that if you take all those services and deploy them as services on a (common) network operating system, you'll reduce complexity and all the associated management (operational) overhead.”

I’ve been following the SDN discussions, but I haven’t seen much about converging on a common network operating system for network devices. Do you happen to have any references handy?

What I have seen, for example, from Scott Shenker in the YouTube video Software-Defined Networking at the Crossroads, http://youtu.be/WabdXYzCAOU, is an objective to reduce the monolithic nature of network devices by separating the control and data planes and exposing today’s closed interfaces to allow programmatic control.

So, yes, complexity will be reduced since it’s easier to deal with more modular components than a monolithic blog and operational overhead will be reduced with the ability to address many network devices programmatically from a central brain.

The central brain could use orchestration tools widely used in the DevOps world (Chef, Puppet) to allow the same efficiencies people use to manage 1000s of VM instances to manage multiple network devices, instead of banging away on individual devices with the vendor’s CLI interface.

But, as I understand it, there’s no dependency on a common network operating system. If the control planes of SDN controllers exposed appropriate interfaces, they could federate and communicate. In the same way a site can operate with multiple Linux and Windows distros or multiple flavors of hypervisor, multiple network OSes could also be in the mix. Obviously, fewer would reduce complexity.

“Standardization - or more apropos - the consolidation of application (that's layer 4-7) network services onto a common platform is what brings that benefit.“

Would the consolidation of L4-7 services on a common platform really be the usual implementation? I’m not clear how this would look in a typical deployment. Where would the common platform be deployed? At the edge? Somewhere else? Is the common platform resident in an actual physical device, VM, combo?

Perhaps the appropriate implementation would be individual L4-7 services being deployed as hypervisor processes, close to the VM running the application, so that the L4-7 service required by the app wouldn’t have to be in some distant appliance, as today.

Standardization is likely to trail vendor implementations, if history is repeated, unless standardization means minimally interoperable. I’m not clear that there’s a requirement for a common platform.