Should SDN Start Over Again?

It’s not commonly known that Alfred Hitchcock’s 1956 version of the Jimmy Stewart classic The Man Who Knew Too Much was not his first. He’d originally filmed the story in 1934, but he yearned to do it again, but better. Given that most of us have forgotten the first version, he clearly succeeded.

All artists, perhaps, feel that their works can be improved. But once it’s out there in the world, it’s hard to take it back. With that tenet in mind, it was no surprise a couple of weeks ago when Scott Shenker, who co-created the OpenFlow protocol that underlies SDN, said he’d like to do pretty much the same thing as Hitchcock, only instead of a remake, he’d like to create a sequel to SDN, acknowledging what’s gone wrong and how to make it better.

As reported by Craig Matsumoto at SDN Central, the changes look like this:

  • Software goes to the edge; the core stays dumb
  • “Middleboxes” get included in SDN
  • The network is opened up to third-party services
  • Closed interfaces are not allowed

All good things, moving SDN from a theoretical beginning to a practical reality, taking into account heterogeneous networks, differences between core and edge switches, and more. (For a look at how Shenker originally envisioned SDN, see this presentation from the 2011 Open Net Summit.)

Apparently, there’s a zeitgeist around improving SDN. As Tom Nolle, a consultant with CIMI, noted in a story about Alcatel-Lucent’s entry into the virtual router business (concurrent with an update to the Nuage platform), “The Nuage stuff is good; some of what they did is what Alcatel-Lucent and others should have done from the first with SDN.” (Italics mine.)

It’s odd to think of something that’s still on Gartner’s hype cycle list as needing to start over, and in reality, it doesn’t. Like all technology (and its creators), it yearns to get better. Whenever the industry creates something from theory, like Shenker has, and then sees it in practice, it sees ways it can improve. I’m pretty sure Microsoft would have put networking capabilities into DOS had it realized that users wanted to share information.

It’s not an outrageous analogy, it turns out, because there’s been a lot of talk about making SDN more distributed. The IETF has been discussing it, and Nolle also asked recently on SearchSDN which was better for SDN, a controller or distributed architecture:

“The centralized SDN strategy substitutes computer-hosted software processes to control forwarding behavior while the distributed model adds mechanisms for software (and increasingly cloud) control to traditional IP and Ethernet networks. The distributed model, like the centralized model of SDN, accepts the need to gather information about network status and collect it at a central point where it can be acted on to manage performance. But in the distributed model, the goal of SDN is to offer more controllable behavior, and that goal could be met by leveraging extension protocols like PCC/PCE/PCRF (policy and charging rules function), MPLS and GRE.”

The argument, he notes tellingly, is between purists and pragmatists. It’s interesting to consider, then, that the man who helped create SDN – whom you’d think would be a purist – is actually a pragmatist. He wants to move SDN forward. And let me tell you something from years of covering technology: Pragmatism always wins, because in the real world, everyone from the CIOs to the network techs want stuff that works, not theory.


Copyright © 2014 IDG Communications, Inc.