Poorly-Defined Networking is hindering SDN's evolution

There’s nothing software-defined about your network!
Every time I see the term ‘software-defined network’ I cringe. A network isn’t software-defined. Sure, it can be operationalized – virtualized, made more intelligent, agile – but that’s the result of an “architectural approach” called software-defined networking. Repeat for effect: SDN is an architectural approach towards which one may design and implement. It doesn’t create a software-defined network. It creates agility through programmability.

Why is this important?
Much of the confusion around SDN is driven by improper use of the term. Imagine if the people of Cat World began referring to their much-loved felines as dogs. That sounds ridiculous now but only because cats and dogs are well defined. What if you’d never seen a cat or a dog before? Let that one sit for a moment…Neo! Unfortunately, and I blame this for the slow uptake in enterprise data centers, the term SDN has been used for far too many things: encapsulation protocols, management API’s, orchestration tools, deep packet inspection (DPI) technologies, to name just a few. How can any one term be all these things, you ask? It can’t!

Before I get too carried away and embark on a rant that serves no more purpose other than portraying myself as a grumpy old man in search of a soapbox, lets visit the ONF. No, not Ozark Natural Foods of Fayetteville Arkansas (thanks Google), I’m talking about the Open Networking Foundation.

So, what is software-defined networking?
“The Open Networking Foundation (ONF) is a user-driven organization dedicated to the promotion and adoption of SDN, and implementing SDN through open standards…”. That’s straight from their website, and backed by an impressive, credibility-building list of members. According to the ONF, Software-Defined Networking is an “emerging architecture”, which usually means rapid change/evolution, and that an SDN architecture must have the following attributes:

• Directly programmable
• Agile
• Centrally managed
• Programmatically configured
• Open standards-based and vendor-neutral

Now we reach the bit where the ONF and I slightly disagree. The ONF states that, “The OpenFlow™ protocol is a foundational element for building SDN solutions.”. Is it really? I think the attributes above can be achieved without the OpenFlow™ protocol. That’s not to say that OpenFlow™ is bad or wrong, but that OpenFlow™ is just one method. And I must say, I'm down with the ONF crew, we've had calls and everything! :)

For a brief period, to be more inclusive, Software "Driven" Networking was thrown about and with it a looser definition, but it didn’t stick. "Defined" had gained momentum.

Want to form your own opinion?
Despite my views on OpenFlow™, if you want to know more about SDN architecture I recommend you take a look at the ONF’s SDN Architecture Overview. Fear not! Unlike many docs from standards-setting groups its only 8 pages long (4 pages with words!). If you do give it a read, let me know your thoughts. This article is my interpretation of such, I’d love to hear yours.

And don’t get me started on Hybrid…

Originally post on LinkedIn Pulse