Is It Time For SDN 2.0?

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.