I doubt anyone would disagree if I said that we had a strong tendency to oversimplify the impacts of changes or new concepts in networking. It’s a combination of the desire by network users to focus on what they want not how to get it, and the desire of the media to turn every development into a one-liner. The problem is that the tendency can result in under-appreciation of both issues and opportunities.
Network connectivity at its core is pretty simple. You squirt a packet into the network and based on addressing it’s delivered to the correct destination. If you look at this level of behavior, it seems pretty easy to convert this to “virtual switching and routing” or “white box” or “OpenFlow”. The problem is that the real process of networking is a lot more complicated.
To start with, networks have to know where that correct destination is. That’s done today through a discovery process that involves a combination of finding users at the edge and then propagating knowledge of where they are through the network so each device knows where to send stuff. In theory I could eliminate discovery completely but if I do that then I have to tell “the network” the exact location of every user and work out how to reach them. The more users and the more routes, the more difficult it would be.
Discovery is part of what’s usually called “control plane processes”, which means it’s supported by protocols that communicate with the network rather than with users. There are a decent number of other control-plane processes out there. “Ping” and “traceroute” are common examples. If we were to eliminate control-plane processes then these protocols wouldn’t work if users exercised them. If we don’t eliminate them then we have to spoof in some way what the protocol would do. Do we let users discover “real” routes in an SDN/OpenFlow network using traceroute or do we show them a virtual route? And whatever choice we make we have to introduce a process somewhere that delivers what’s expected.
Then there’s management. At a simple level, users would typically expect to have some management access to network elements, something like an SNMP port. So now what do we give them in the world of SDN or NFV? The “real” network element they expect, like a fully functioning router/switch or a firewall, isn’t there. Instead we have a collection of distributed functions hosted on computers that the user has no idea are in place, connected by virtual links or chains that used to be internal data paths on a device, and representing shared facilities that the user can’t be allowed to control even if they knew how.
If we look at the implications of this on “virtual routing” we see perhaps for the first time the difference between two solutions we hear about all the time but never seem to get straight. “SDN” virtual routing using OpenFlow doesn’t have real routers. There are no embedded features to provide control-plane responses or management features. It forwards stuff, and if you want more you have to use almost-NFV-like function hosting to add the capabilities in. Non-SDN virtual routing (Brocade’s Vyatta stuff is a good example) is a virtualized, hostable, router. It’s a real router, functionally, and you can build networks with it just like you’d do with router devices. You have no issues of control or management because your virtual router looks like the real thing—because it is.
The first important conclusion you can draw from this is that the more you expect to have virtualized network elements represent every aspect of the behavior of real devices, the more you need a hosted software version of the real device and not a “white-box” or forwarding-level equivalent. Rightfully, the Brocade virtual routers are neither SDN nor NFV. They’re software routers and not software-defined routers. That, I’d assert, is true with NFV too. If we have to present a virtual CPE element exactly like real CPE would look at all control and management levels, then we need to have an agile box on the premises into which we can load features, not a cloud-distributed chain of features.
This might sound like I’m saying that SDN and NFV are intrinsically crippled, but what I’m really saying is that we’re intrinsically crippling them. The fallacy in our thinking is that we have to “represent every aspect of the behavior of real devices.” If we toss that aside we could imagine a lot of interesting things.
Suppose we had a network with no control-plane packets at all. Suppose that any given network access port was disconnected until we sent an XML message to a management system that provided ownership credentials and the address mechanism to be used there. Suppose that a user who wanted NaaS simply provided the network with an XML manifest of the points to be connected using logical addresses, real addresses, any addresses. We can now define a NaaS on the basis of completely managed connectivity.
Suppose that we define management processes as a data relationship set that binds the status of real resources to the status of the NaaS services these resources support. We can now find out what the state of a network service is without ever giving direct access to the devices, and we can use the same MIBs and processes to manage hosted software elements or real appliances.
Network protocols have created those velvet ribbons that tie us to stuff without our realizing it, and the way that we use these protocols in the future will have an enormous impact on the extent to which we can optimize our use of SDN or NFV. We should be able to define services in every respect in a virtual world, and our changes in definition shouldn’t have an enormous impact on cost or operations efficiency. IP should not be the underlying connection/forwarding fabric—that should be the simple OpenFlow-like packet forwarding based on a mystical forwarding table. We should be able to build IP, or Ethernet, or any arbitrary collection of network services, equally well on this agile base.
Why can’t we? Because it’s complicated, and so everyone focuses on making something far more trivial work quickly. That generates little islands or silos, but it doesn’t build a network and networks are what we’re supposed to be doing. I think that both SDN and NFV can do a lot more for us than we think, if we start thinking seriously not only about what networks do but how they do it.