The End of Network Devices? Not So Fast!The End of Network Devices? Not So Fast!

If SDN and NFV are simply new ways of doing old things, then the router/switch vendors have nothing to worry about.

Chicken Little reputedly panicked everyone by declaring that the sky was falling. You'd think humans would be smarter than chickens, but we get a bit of this same hysteria with the impact of virtualization on network equipment: SDN (Software Defined Networks), or NFV (Network Functions Virtualization), or maybe both in concert, are supposedly going to be the End of Network Gear As We Know It.

Well, if you're looking for little pieces of blue scattered about your feet, forget it. Forget the idea of wading knee-deep through discarded network equipment too...but ankle-deep might be a possibility.

You can obviously host network functionality on a computer; most network devices are special-purpose computers already. It's tempting to say that if you took cloud principles and deployed hostable functions in a vast resource pool, you could get good economies of scale and substitute software (even open-source software) for proprietary hardware. And it's true, to a point. We just have to draw the boundary line, and that's determined by three things. First, relative cost including operations; second, performance of the data path; and finally reliability/availability.

As I write this piece, I can see an 8-port Ethernet hub used for my office network. I think it was on sale for 50 bucks. Now, I suggest that you try to go shopping, find a server with 8 Ethernet ports, get a Linux OS and virtualization software for it, some open switch software, install all that, and pay less than 20 times what I paid. Of course, I could find an Ethernet switch that was 20 times what I paid for mine, too. The point is that all network equipment isn't capital-intensive. Even if some operator figured out how to sell me Ethernet switching as a service, how much profit could there be if my five-year capitalized cost was 10 bucks a year? Don't hold your breath looking for sellers on that deal!

Another cost dimension is management, and we can look at an example here too. I've got a home router that cost me that same 50 bucks. It has a firewall, DHCP, DNS, and NAT. Could I create a virtual function for each of these four capabilities, string those functions out in four VMs, connect them in a service chain, and duplicate the functionality of my home router? Sure, but how much would it cost me just to keep that complex chain running? Probably five times what I'd have spent for my cheap little box. Simple stuff that gets made more complicated by virtualization isn't likely to save anything at all--it's more likely to generate new costs.

Let's now move to performance. I can get copper 1Gbps interfaces on laptops, so we can presume that computers can handle that. Probably they could also handle 10G, and even multiple 10G interfaces. Can we grab a commercial server and stick 100 40G ports on it and expect to run all of them at line rate? I'm doubtful. I think everyone would agree that when you get to pushing a lot of data through top-end fiber interfaces, you're going to swamp commercial servers pretty quickly. So the big boxes, the lower OSI layers that aggregate a ton of traffic in the access/metro network or the core, are not likely to be moving to general-purpose servers any time soon.

Performance issues make it unlikely that you'd be able to substitute servers for dedicated network hardware in pure switch/routing missions anywhere but the network's edge, where traffic is modest. But our last point, reliability/availability, reinforces that restriction.

Purpose-built network hardware can be engineered to the utopian five-nines level. That's not likely to be true for off-the-shelf servers, and most advocates of the servers-eat-networks theory agree, and propose to recover the reliability through redundancy. If one server isn't reliable enough, you spin up two and fail over. OK, but if you fail over a data-plane device, you'll cause a service hit. If you want to avoid the hit, you have to duplicate the traffic flow at the edge, send each path independently through the network, put the two together at the destination, and filter to create an in-order stream.

If all of this sounds like SDN and NFV are useless and won't impact network equipment, that's not true. I estimate that SDN and NFV could impact about 60% of all network spending, in fact. Most of that is near the service edge and in enterprise networks. More significantly, SDN and NFV could pull service-differentiating features out of the network and host them on servers. That could commoditize even the network hardware that's not directly impacted. But none of this will justify mass deployment of either SDN or NFV; it would just drive down switch/router prices. The revolution has to come from issues higher on the food chain, in the cloud.

The cloud, mobility, the Internet of Things, and all the good stuff we see in the future will change the requirements for the networks that host them. To justify SDN or NFV we have to look to how either or both can support these futuristic things better than current network devices. To the extent that they can, both SDN and NFV will then roll out and take a place in a new network, a place that nothing properly fills today. If SDN and NFV are simply new ways of doing old things, then the router/switch vendors have nothing to worry about.

Follow Tom Nolle on Google+!
Tom Nolle on Google+