SDN and the idea of centralized control plane were hotly debated in the early 2010s, and we tried to bring at least some sanity into the discussion. The so-called “industry press” couldn’t be bothered – here’s my response to a particularly misleading article written in November 2013.

Fun fact: while HP did have a few interesting SDN/OpenFlow-based solutions, they never managed to get any reasonable foothold beyond cheap optimally-priced campus networking, and finally resorted to acquisitions to stay in that business.

Two and a Half Years after OpenFlow Debut, the Media Remains Clueless

If you repeat something often enough, it becomes a “fact” (or an urban myth). SDN is no exception, industry press loves to explain SDN like this:

[SDN] takes the high-end features built into routers and switches and puts them into software that can run on cheaper hardware. Corporations still need to buy routers and switches, but they can buy fewer of them and cheaper ones.

That nice soundbite contains at least one stupidity per sentence:

SDN cannot move hardware features into software. If a device relies on hardware forwarding, you cannot move the same feature into software without significantly impacting the forwarding performance.

SDN software runs on cheaper hardware. Ignoring the intricacies of custom ASICs and merchant silicon (and the fact that Cisco produces more custom ASICs than all merchant silicon vendors combined), complexity and economies of scale dictate the hardware costs. It’s pretty hard to make cheaper hardware with the same performance and feature set.

However, all networking vendors bundle the software with the hardware devices and expense R&D costs (instead of including them in COGS) to boost their perceived margins.

Does the above paragraph sound like Latin to you? Don’t worry – just keep in mind that software usually costs about as much (or more) as the hardware it runs on, but you don’t see that.

Corporations can buy fewer routers and switches. It can’t get any better than this. If you need 100 10GE ports, you need 100 10GE ports. If you need two devices for two WAN uplinks (for redundancy), you need two devices. SDN won’t change the port count, redundancy requirements, or laws of physics.

Corporations can buy cheaper [routers and switches]. Guess what – you still need the software to run them, and until we see price tags of SDN controllers, and do a TCO calculation, claims like this one remain wishful thinking (you did notice I’m extremely diplomatic today, didn’t you?).

Latest blog posts in The OpenFlow/SDN Hype series


  1. +1
    - Lock-ins will get wider. Prices will get higher (naturally,their is a tight dependency between the two)
    - On the de-coupling aspect between HW and SW i do anticipate white boxes to appear and the market to go through similar process the server market went through. Current vendors will be much more "SW vendors". but read again bullet #1 :)
  2. 1- SDN can move the higher level functionality of network to x86 hardware. Load balancing, firewalling, optimization, etc.

    2- If network hardware is only responsible for simple forwarding you don't need those custom ASICs which will bring the cost of hw down.

    3- You need as many ports as you need, but you won't need any middle boxes anymore.
    1. #1 - And where do you think they run today? Open any L4-7 device and check what's inside ;)

      #2 - If you think hardware shall do only simple L2/L3 forwarding, you can buy cheaper hardware today. What's stopping you? Buy Mikrotik.

      #3 - Think again. It doesn't matter whether the middle boxes run on white-label x86 servers or teal-colored boxes, if your architecture requires them, you'll have to use them one way or the other.
    2. 1- But that is the point. Why run it on a network device when I can run it on x86? (also see #3)

      2- Because those cheap devices aren't able to do higher level functions at all or as efficiently as their ASIC-based, more expensive counter parts. If we move those functions to standard computing resources cheaper devices might become more viable (of course enterprises would still want enterprise level support, etc which might be a problem with some of those manufacturers.)

      3- True, but the point is not to run them on a physical device, but on virtual computing resources, where it can be provisioned and managed just like any other vm.
  3. I agree with all of the points in the original post.

    1) I don't consider that functionality SDN, that functionality is NFV. SDN may enable things like service chaining of those functions, etc. but virtualization of those functions on COTS isn't SDN. Some of the load balancer market appliances from companies like A10 don't even have custom ASICs, they are just x86 servers with custom software... Most of the the LB/FW market has already come to grips with the virtualized marketplace anyways and released VMs of their products, even Cisco.

    2) Higher speed forwarding and aggregation still requires dedicated hardware. The stuff in the newer switches from Cisco, Arista, and Juniper (Trident-2) is pretty close to a white-label switch and you aren't going to save much buying one from some other vendor and then using a 3rd party control plane. The reality is all those boxes do is pretty simple forwarding already...

    x86 servers use way more power and resources than dedicated network hardware like ASICs and NPUs, it just doesn't make any sense really for high bandwidth applications. People have been running x86 firewalls/routers/etc. for decades now, and the bar has been raised on throughput so where I needed a Cisco router in the past maybe now I don't. I think Cisco/Juniper realize that and is why they are coming out with virtualized versions of their OS.
  4. "SDN software runs on cheaper hardware."

    Well some manufacturers may sell their hardware at a much larger premium than other manufacturers; if your network is controlled using a SDN protocol, then hardware vendors have less leverage in negotiations, and less ability to charge you a premium, if you can switch to any vendor for new equipment, and still use the same SDN protocols to manage the devices.

    "Corporations can buy fewer routers and switches. It can’t get any better than this. If you need 100 10GE ports, you need 100 10GE ports."

    If you have 100 workstations yes; it depends on how you are using those 100 GE ports.

    You might reduce your needed port count, if you can eliminate the requirement for some internal routers, and implement this functionality on switches instead, using a SDN protocol.

    You might reduce your required number of VLANs, or eliminate requirements for additional physically separated switches.

    "Corporations can buy cheaper [routers and switches]. Guess what – you still need the software to run them"

    Yes; what SDN controllers will cost, in terms of capital, AND the additional complexity and operating expenses to run them, and the additional risks that SDN controllers will fail, etc, etc, will surely be important.

    Routers may become cheaper, if SDN strips away manufacturers' ability to command a premium for their product, because routers from all manufacturers seem more and more the same; commodities, with increased competition enabled by SDN, prices may eventually drop.

    1. "Routers may become cheaper ..."

      Yeah, that's why prices of BMW dropped when Kia entered the market. There's a good reason people are willing to pay more for a Cisco box than for a Mikrotik or Pica8 box.
    2. Not Kia buy Hyundai. Notice the lower 1 series and CLA.

      Good enough is good enough. When software manages the complexities of networking, all I need to purchase is an IP transport.
  5. I agree with almost everything you say here except that I think allowing for the control plane to operate separately from the hardware (and vendors) means that we have a better chance at using the hardware resources we buy more efficiently. That is while you might still need 100 10GE ports at the edge, you may need far fewer switches and ports in the core to get the same real performance out of your network.
    1. And why would that be? Because:

      A) Vendors are clueless
      B) Vendors ensure we can't squeeze most out of their boxes
      C) We know so much better what to do than people who have been doing it for years if not decades
      D) All of the above

      Getting a control plane to work reliably is hard work. Google can pull it off (and probably a few others), but that's it.
  6. Fewer was kinda funny, I know what they mean, but it's still funny to read it. Just like the person mentioned above you might be able to use a little less hardware because of it, especially if your utilization is low.

    Buying cheaper switches ? Hmm, I actually think overlays can be a good solution.

    But I don't think I want unmanaged switches, I want to be able to get at least some basic information out of the switches. And I've not seen cheap managed switches with less features from any major vendor.

    So what choice do we have but to buy expensive switches ?
  7. SDN by itself may not yield these results independently, but is part of vision wherein the physical network becomes an IP bus and the virtual network implements the controls segmentation, firewalling, inspection, etc.

    Some are as progressive as to design something with a pair of routers, a pair of switches (Arista 7000 series), and 1,000 virtual servers. 2-3 routed VLANs in hardware and the rest is done in software. Edge firewalls, DMZ, application firewalls, load balancing, VPN, and IPS are all done within software overlays.

    I may require "100 ports" for my datacenter, but they are now in a one hop physical network with local firewalling and routing per application bundle.
    1. We're in total sync, but you could have done that years ago (should you so desire), and nobody was calling that SDN or SDDC ;))
    2. True, but you had to manage those components individually. With "SND/SDDC" the technology is not the focus, rather the management and orchestration of the environment such that I can deploy an application, with network segments, with firewall policy, and IPS.

      I believe the "virtual" world has shown what management of IT technology should look like and now networking is being asked to do the same. Imagine a visual interface whereby you could draw the traffic flows (from host A to point B on port C), receive visual feedback, and then implement by pressing the "easy" button. I would love to manage the network from a large map view...
  8. I've seen the fancy multi-service provisioning stuff done in practice for years now. I see the change in the ability to spin up those resources on demand using COTS boxes instead of virtualized network appliances.

    I don't think you want to draw anything really, the network should know where the application endpoints live via some other means. The whole point of SDN is for the application to drive the network, not the other way around. Cisco at least has that part of it correct, when you provision through the ACIP it's driven by an application need. If I'm provisioning 10 new VMs for an application and they need a FW for a gateway, the orchestration system needs to spin up resources, figure out where the app lives, where the fw lives, and then program the network. If you have a 1-hop network via leaf/spine or two really dense switches, there are no alternate traffic paths between two endpoints...

  9. And how will the control plane talk to data plane? via a OOB network..but thats also a network.....will have all the inherent qualties of a regular prodcuton network...and even to this day,we do have cheaper vendors for routers and switches, we have sticked to one vendor..its US...NET ENGG who decided to go with cisco and of course Cisco also supported us in advancing tech in whichever way they could..meaning we allowed ourselves to be vendor locked..just like microsoft....and we will do the same in case of SDN too and hence in due course, the cost benefit would not remain will be back to square one....
Add comment