11:17 AM
Connect Directly
Repost This

Is It Time For SDN 2.0?

Software-defined networking has become a meaningless buzzword. Let's start fresh with a new term that has strict requirements before vendors can label their products with it.

The term "software-defined networking" has finally run its course. Originally, it was used for the noble goal of trying to explain how introducing concepts like automation and orchestration could help network engineers. It also was intended as a way to describe how protocols like OpenFlow could lead to a bigger picture of the network for planning and architecture.

Today, SDN has been reduced to a buzzword that gets attached to anything a vendor is trying to sell. It's also a popular way for vendors to highlight a function that they want to sell you. Perhaps it's an application programming interface (API) to their equipment. Or maybe it's a series of scripts or macros in the operating system that auto-magically execute commands. The last straw for me came late last year when Ivan Pepelnjak wrote about using Perl to automate configuration for dial-up users and described it as SDN in 1993.

Maybe it's time we declare SDN a relic of the past and move onto a term that has meaning again. In lieu of a different word, I'm just going to call it "SDN 2.0."

SDN 2.0 isn't going to be a nebulous idea that tries to incorporate anything that people think will sell to a customer. It won't be YANG or NETCONF scripts pushing configuration to dumb devices. It won't be a monolithic operating system with a basic interface to the rest of the world that no one will write for. SDN 2.0 is going to have three hard requirements in order for a vendor to get the SDN 2.0 logo on the box:

1. Automated. You need intelligence built into the network to do SDN 2.0. Not scripts. Not dumb APIs. You must have some kind of controller or orchestration device thinking for the network. Your network devices need to integrate with that controller in some fashion. If the management platform can't talk to your devices, you aren't SDN 2.0 compliant.

2. Programmable. No more CLI. Move on from scraping SSH screens to populate configuration databases. If you can't automate it, generate an interface on the fly with REST APIs. Better yet, only allow interfacing from the management console. If people are bent on keeping their CLI, then it must go away in favor of programmability.

3. Open. If your solution is closed-source or poorly documented, it's not SDN 2.0. Too much in networking is cloistered behind proprietary implementations. SDN 2.0 needs to open and visible to the world. Being unable to troubleshoot strange behavior because only a handful of vendor programmers understand how things actually work is unacceptable. If OpenDaylight and OpenContrail can see the light, maybe it's time for everyone else to see it too.

[Read how customers will face the fallout from networking vendors' internal conflict as they try to integrate SDN into their products in "SDN Vendors' Internal Tug-of-War Doesn't Bode Well For Customers."]

Getting rid of the term SDN in favor of something new isn't going to solve all of our problems as customers. Vendors are still going to try and convince us that their vision of software definition is right, even if it's nothing of the sort.

But making a new term with strict guidelines can help. By making vendors enumerate all the features of their product that adhere to the "SDN 2.0" standard, it gives customers a better basis for comparison. It keeps the shady vendors from selling something that isn't up to par and highlights those that are doing it right.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
1/22/2014 | 9:53:28 PM
re: Is It Time For SDN 2.0?
I hope SDN evolution fairs better than 802.11 ended up. We're flooded with Wi-FI "certified" devices and it's an absolute joke at times- great fragmentation of capabilities and requirements, and a definite reflection of the "profit first" mentality that is the backdrop of any technology. I get that you gotta make money off of this stuff, but tight interoperability specs and common sense need to be there all the way through or SDN is doomed to be just another mishmash of proprietary methods that you have to read the fine print on to understand. Pfffft, says I.
Drew Conry-Murray
Drew Conry-Murray,
User Rank: Apprentice
1/22/2014 | 2:12:51 PM
re: Is It Time For SDN 2.0?
I like your definition of SDN 2.0. Unfortunately, unless you take out a trademark on it, and then sue the bejeezus out of any vendor that applies the 2.0 label incorrectly, we'll just end up in the same situation as SDN today.
User Rank: Apprentice
1/22/2014 | 10:17:45 AM
re: Is It Time For SDN 2.0?
I think it's a bit too early for "retiring" the current SDN and calling it "SDN 2.0". Maybe when there are some actual large scale deployments. Also, the term 2.0 generally refers to a more "personalised" experience. Give it a couple of more years Tom.
User Rank: Apprentice
1/18/2014 | 8:40:49 AM
re: Is It Time For SDN 2.0?
I share your frustration Tom. It's getting tiresome to see yet another round of food throwing wars that vendors engage in on SDN subject. But I just don't see that changing anytime soon. You write of getting the vendors checked by forcing a new set of requirements across the industry. That sort of pressure must come from consumers and I just don't see it coming in right amount. SDN is too much of culture shock for most - too new and weird, too demanding for our comfort zone. We like our horses too much :) We like/used to choose from the menu rather than say - "I want that included in the menu".
User Rank: Apprentice
1/18/2014 | 12:41:31 AM
re: Is It Time For SDN 2.0?
Do readers agree that the term SDN needs to be retired? What would you replace it with?
More Blogs from Commentary
Infrastructure Challenge: Build Your Community
Network Computing provides the platform; help us make it your community.
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Hot Topics
IT Certification Exam Success In 4 Steps
Amy Arnold, CCNP/DP/Voice,  4/22/2014
Edge Devices Are The Brains Of The Network
Orhan Ergun, Network Architect,  4/23/2014
Heartbleed Flaw Exploited In VPN Attack
Mathew J. Schwartz 4/21/2014
White Papers
Register for Network Computing Newsletters
Current Issue
Twitter Feed