What SDN is and Why it will Fail

What does “software” mean in SDN?

SDN is a nonsense term.  Let me ask you this question, if you have a computer with no software loaded on it, what does that computer do other than suck up power?  Nothing.   “Nothing” is the correct answer.  The idea of software is somewhat fuzzy these days as it can be code loaded on some kind of ROM that is pushed onto an FPGA or some other thing at boot.  Some people decided to call this kind of thing “firmware.”  Its not.  Its just software stored on something other than a traditional disk.

Without software (be it “firmware” or not) your network node does nothing useful.  It sits there.  This is a fundamental concept in Computer “Science” and it goes all the way back to when software was contained on punch cards.  A network node is really just a computer with specialized hardware.  It needs software to tell the hardware to do something useful.  Thats what IOS or JUNOS does.  As it turns out, IOS and JUNOS are quite large these days.  I have never considered IOS or JUNOS to be “firmware.”  It is clearly software.

The difference between IOS and JUNOS and what is referred to as SDN is that intelligence isn’t distributed across some number of nodes cooperating to form a network.  With SDN the intelligence is centralized and from this central entity network state is created and communicated to network nodes or even hosts.  As has been pointed out numerous times, there is already a fairly long list of network technologies that have done this in the past and do this now.  Are all those things considered SDN then?

What is SDN with respect to OpenFlow?

Consider the ONF’s definition of SDN:  SDN consists of the ability to program the forwarding-plane of the network through an open interface.  OpenFlow could be such an interface.

The OpenFlow pipeline is modeled somewhat after how traditional forwarding works.  Borrowing from “Network Processors:  Architecture, Programming, and Implementation” a forwarding path pipeline has the following stages:  (1) Framing, (2) Parsing/Classification, (3) Search/Lookup, (4) Modification, (5) Compression/Encryption, (6) Queueing and then ultimately transmission.  OpenFlow, loosely speaking, covers Steps 2 through 4 and then 6.

As it turns out, Openflow v1.1 through the current candidate version v1.3 have challenges being fully implemented in existing forwarding hardware.  One could argue that Openflow adoption beyond v1.0 (and even this is not fully supported everywhere by all vendors) is, for the time being, hindered by this fact.  Isn’t it strange that OpenFlow, which is thought of by many as the cornerstone of Software Defined Networking, is having adoption issues due to hardware limitations?

We could just run OpenFlow to a host running OVS right?  There are hardware limitations there as well.  If you want meaningful performance, apparently, you need a “TOE.”  TOE’s do not currently support anything but a single VLAN tag in the frame header.  So forget about MPLS or Q-in-Q.  In fact, forget about any kind of overlay or tunneling except ones that are TCP based.

It seems its not possible to separate software from hardware.

What, then, is SDN and why will it fail?

More hype-bubbles have grown and popped in Silicon Valley than anywhere.  The next big thing rarely sees mass adoption.  SDN is a Silicon Valley hype-bubble.  OpenFlow covers a narrow slice of what networking is.  Central control of network functionality and networking on general-purpose hosts are old hat and, again, cover a narrow slice of what networking is.  In short, SDN concepts are not sufficient to really be a revolution in networking.  They’re just more pieces.

Delivering applications through the infrastructure is already immensely complex.  Encapsulating that complexity and selling a product that manages it for the user ultimately means less flexibility.  Networks need to be flexible.   This is why networking has evolved the way it has.  We have many smaller abstractions to work with, lego blocks if you will, to build the infinite variety of networks that exist today in support of the infinite variety of applications, and built in accordance with an infinite variety of business and security policies and budgets.

Certain highly repeatable patterns in networking could be automated with network programmability such as service-insertion,  networking in support of virtual-compute, and even real-time management of QoS.  In this case, network engineers will not be writing their own software:  They will buy third-party products that solve specific problems on top of existing network deployments.  What network engineers need to build and operate their networks are clearly defined and tested mechanisms for dealing with specific problems.

Its not clear at all what SDN is or what makes it “software defined.”  Networking has always been software defined because hardware does nothing without software.  In turn, software does nothing without the hardware to run it on.  I’m not trying to be sophistic here at all.  What I’m driving towards is that maybe SDN is just networking.  Thats all it is.  Do we care if there is a TCAM, or if the software runs on an x86 host?  Whichever algorithms and hardware are used and how state is communicated to nodes doesn’t matter:  the end-state is that we have achieved networking.

SDN can not sustain distinguishing itself from just “networking,” and without an identity of its own how can it be anything other than another tech hype bubble?  What will come of SDN, ultimately, is twofold:  (a) Improved programmatic control of the network for third-party applications that solve specific problems and (b) increased network functionality of hosts.  What we are really witnessing in this and the DC fabric wars is the inevitable reconciliation of virtual-compute and networking.

As networking adapts and these concepts evolve and become clearly defined, SDN will fade.  The apocalypse is not coming.

Fail Toad

Fail Toad

FailToad disagrees with you. FailToad thinks you are all morons. If you have something to say to FailToad then write it down, crumple it up, and throw it in the garbage. FailToad doesn't care. Have a nice day.
Fail Toad

Latest posts by Fail Toad (see all)

  • http://twitter.com/nkrypted Brandon Mangold

    Agreed to a point. SDN will probably never be fully implemented as some people think as the nirvana of central intelligence networking. I am pretty certain however that we will see “pods” of centrally controlled, programmable network devices that will flow up to a common orchestration tool.

    This is also why I think Cisco is on the right track with their explanation of SDN as just a piece. Programmable networking and northbound API is where it’s at.

    • http://twitter.com/blinken_lichten Jon Langemak

      Agree with Brandon. I don’t think SDN will change the face of networking as we know it (who believed that to start with?). However, I do think that this will be another ‘way’ to get things done.

      Some places will fully embrace the extremes of SDN and OpenFlow. Google with their specialized hardware for the DCI and smaller companies with ‘dumb’ (read cheap) switches that need the controller to work. But those are outliers in my opinion. I don’t see enterprise’s fully adopting either extreme.

  • Techkid

    Well said!

  • Matthew Stone

    Really practical take on it. Time will ultimately tell, but I think you’re spot on. “SDN” will put one more tool in our tool belt to get stuff done.

  • drl

    The most relevant point you make is that SDN is a poor name for the evolution that is taking place. Most labels given to tech concepts are goofy or worse so this isn’t worth getting upset about. The thing that is going on here is that the scale of big networks has increased by multiple orders of magnitude in recent years due to trends such as virtualization, xAAS, big data, etc. The paradigm for managing and monitoring networks (telnet to every switch and type weird stuff using 1970’s green screen syntax) does not scale cost effectively, if at all. Operators need a way to automate the batch control of huge numbers of switching devices and to interact with networks at a higher, service layer of abstraction. Applications need new service level responsiveness implemented instantaneously across huge numbers of network elements. If you think of SDN as an (inaccurate and confusing) acronym that describes the fact that this automation is not optional and is being developed and deployed as rapidly as the industry is capable of, there is no possible conclusion except that this is happening and will be huge from a commercial perspective. So far the incumbent vendors have demonstrated that they will aggressively defend status quo with FUD like Cisco ONE, while startups, entrepreneurs and the operators themselves are aggressively building out what the industry now requires. SDN is name fail on a typically grand scale, but to suggest that the hyperscale automation revolution will fail would be to ignore the fact that it is the only way forward and inevitable. As Bill Koss pointed out in his blog (
    http://siwdt.com/2012/06/26/sdn-what-it-means-max-hype-level-achieved-and-code-words/ ) recently, (I’m paraphrasing) SDN is the expression of a need for a technical solution to exploding OPEX. Fortunes will be made solving this problem and the status quo will be disrupted. Count on it.

    • coolbomb

      I agree with you…

      The name is irrelevant… the fact is that this is probably going to drive the future of networking. Maybe in the future, with a “better” name.

  • http://About.Me/RonnyLam Ronny Lam

    The name SDN is IMO wrong, or to say it nicer, not very well chosen. I have always preferred NOS, for Network Operating System. But I am also the first to agree that that name doesn’t cover it all either. Programmable Networks as Cisco calls it is also wrong. Weren’t we programming until now? Or was that configuring? Let’s stick with SDN for now, until it means everything and therefore nothing, like Cloud.

    What is good about the SDN concept is building a software overlay with central intelligence. This can be as “simple” as a central configuration server like you mention, or it can be a centralized Controlplane like OpenFlow is offering.

    I see a trend that CPU’s and memory in routers, and switches, need to expand just to cope with all the software features being built into them. Especially with monolithic software like IOS. In the end all this software does is trying to build a Forwarding Information Base from all the various inputs. I can really see that we can separate this controlplane from the forwarding dataplane. Effectively making hardware and software cheaper.

    I agree that SDN will fade, but the solutions for the problems it is trying to solve will stay. If this hype brings us better northbound API’s and a better way to centrally control or orchestrate networks than just CLI, we have won.

  • networker

    Well written article !

  • http://www.facebook.com/leehosan8 Lee Ho Šan Grayson

    I’m afraid that I cannot agree with you. And I have no particular affinity or reason to back Cisco. I’ve been studying the CCNA and did advanced research at Queens’ Cambridge/ Engineering Dept., in field of Artificial Neural Nets., Hidden Markov Models etc. C/Java/Python/Prolog etc., etc. I think that the SDN paradigm is a paradigm shift (Kuhn, Structure of Scientific Revolutions, 2e, Harvard Univ. Press). It opens up a network programming paradigm previously unavailable. I don’t think it merely hype. Personally I’m going to try to leverage the access to switches as high-processing devices to act as nodes in an Artificial Neural Network Model… eg., Kohonen self-organizing ANN, Boltzmann Machine, Multi-Layer Perceptron. The high processing power of switches will allow for some very power, distributed, massively-parallel, concurrent processing and I believe the the resultant parallel, distributed software running on optimized parallel hardware infrastructure will lead to some very interesting applications/emergent behaviour. It will be a case of thinking outside of the box, if you’ll forgive the pun.

  • Craig Becker

    All this VM ware and fabric path we are building small then letting it grow by adding more and more hardware to it is just doing what we have already done and are still doing…MAINFRAME