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.
Published on , commented on July 9, 2022
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?).
- 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- 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.
#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- 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.
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.
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.
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.
Good enough is good enough. When software manages the complexities of networking, all I need to purchase is an IP transport.
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.
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 ?
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.
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...
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...