Differentiation has always been a challenge, but it seems like the problems vendors and providers face in standing out from the masses is getting worse. Part of that is because there are more and more areas that could offer differentiation, more difficulties making buyers understand the issues in those areas, and more overlap across the areas. What’s a vendor to do, and what might be the result of all this “doing”, or at least trying?
Forty years ago, computing platforms were almost totally proprietary. If you bought a machine from DEC, you bought into the whole DEC ecosystem from hardware up to networking products. Networks are still largely built from proprietary devices that are still monoliths, bundles of everything, but computing has been shifting more to an open model, and networking is starting to move in that direction too. Does everyone surrender to the Will of the Masses here, or are there still spaces where a good iconoclast vendor could stand out?
The obvious one is “what comes next?” If we’re losing network equipment differentiation because of the transformation of networking, then the path of transformation and even the end game might well be differentiators. In fact, they’re probably the first level of selection that will separate the good from the…deceased.
The current view of network transformation threatens traditional vendor positioning. Some call this future transformed state “cloud”, some say it’s “software”, but in either case what we’re really talking about is shifting away from “box networking” meaning routers, to something that hosts network features. Vendors in the network space have grown and prospered selling boxes, but if the future network is cobbled together from a bunch of Lego blocks, what do those vendors sell? A Lego block is a lot less differentiated than a Lego castle, so unbundling network boxes into separate pieces seems to cry out “commoditization” in a loud (and scary) voice. How loud and scary the future will turn out to be depends on exactly how the evolution happens.
The router-vendor vision of the future is simple; yes, hardware and software have to be separated. We separated it by unbundling the router software and making it an annual license, a subscription. In theory you could run other software on our boxes (good luck finding software, and to get support will likely require miraculous intervention). In theory, you could run our software on other hardware (same good wishes). But, hey, we’re trying.
The router-software vision is simple too. A router transforms into a router instance running on a commercial off-the-shelf server (COTS). The server won’t deliver the same performance as a customized hardware platform, but you could claim this was a “cloud-enable” solution because you could run the router software on a VM in the cloud. Expect performance there to be even worse, of course.
White-box people have a germ of a truly new vision. You run generic router software on a custom device, a device that is augmented with the chips and other technology needed to let it at least approach the performance of dedicated routers. This is probably what most people today are seeing as the right path, but it has the disadvantage of leaving the cloud behind. Network operators believe in the cloud, even if they don’t know exactly what it is.
There are some in-the-network differentiation opportunities, of course. White boxes can be differentiated by the chip set included in them, which could make it possible to create a cluster device whose individual elements are optimized to the mission. Some might look like brawny forwarding engines, others like lookup engines, and others like cloud application hosts. Again, leveraging this would require the decomposition of “routing” as a function into abstract elements that could then be hosted where they fit best.
Chips themselves could be differentiators, too. The challenge with creating your own custom chips (which major router vendors do for their systems) is that they can compromise your ability to claim an “open” architecture. A dispersed cluster of routing elements like the one I just described could still be fully open if it exposed the proper APIs to permit customization, and of course, generic white boxes are inherently open. Stick a custom chip in a white box and it’s open only to the extent that the chip is generally exploitable, and if it is, then it’s not differentiating.
The P4 language and the ONF Stratum architecture model could offer a way to maintain an open claim while using custom silicon nobody else could get. P4 is a flow-management language, an API and “driver” that harmonizes different chips to a common programming language. That means that you could support a standard flow manipulation approach with custom, differentiable, silicon. It would also mean that other stuff could be run on your box, and that your stuff could be run on other boxes, providing that everything used P4.
So far, all of these options come with plusses and minuses, but a big minus for them all is that they’re really tweaking the old router model. It’s not enough to just run a monolithic control plane and a monolithic data plane on either the same device or tightly coupled devices. The future network disaggregates right down to the feature level. You separate the control, management, and data planes and you host the former two on the cloud, using cloud-native techniques. The data plane gets mapped to specialized white-box devices. We get the best of the white-box world without the performance risks, and we make the cloud the centerpiece.
The common thread in network operator transformation discussions is “the cloud”. There’s an implicit belief that if cloud principles were to be applied to building networks, the cloud could transform networks as it’s transformed IT. If every operator believes that, then every differentiating position has to be somehow tied back to the cloud. That’s the big failing of so many of the approaches to differentiation I’ve outlined above. They don’t end up with a cloud, and that’s where every operator thinks they have to be heading. But how do you apply cloud-think to networks?
There have been criticisms of the IP routing process, elements of the process that relate primarily to what would be called the “control plane” for about two decades now. Things like MPLS, Next-Hop Resolution Protocol, and more recently the various area-routing approaches, are all based on refinements to the adaptive routing process. SDN proposed to replace all of this with a central routing instance, a place that collected topology and status and sent out updates to all the forwarding tables impacted by changes. Could the essential piece of uniting cloud and network be the replacement of the traditional IP control plane with something else? SDN without the centralization risk?
You could surely pull the control plane out of a single box and create a cluster that lets control and data plane evolve in cloud-native form, but as separate as the two would need to be, given the extreme differences in control and data plane requirements. DriveNets, who won a Light Reading startup award, does this, and they’ve recently claimed a PoC that illustrates some pretty profound benefits. The story suggests that they could extend this separate control plane multi-dimensionally, upward to climb toward actually making the network experience-aware, and horizontally across multiple devices/clusters to create a distributed form of SDN’s central controller. Forwarding, in this vision, is simply a kind of transport layer, controlled from above via the cloud.
That new model is what I think is the ultimate differentiator. The biggest minus (or plus, depending on your perspective) is that traditional router vendors surely see this as being differentiating via total disruption. If you change everything, then you’re telling customers that they might as well look at other alternatives than you, as long as they’re starting fresh. Can a router vendor develop an evolutionary revolution? I have to wonder why, if they could, they haven’t done it already, when it’s so clear that buyers are eager for something truly transformational.
The smart thing for router vendors, then, would be to accept what’s happening and begin a transformation of their own approach. I can already pull forwarding (the data plane) and the control plane of routing apart. If I were a router vendor, I could then implement that cloud-ready control plane, support my current product line, and evolve myself toward cheaper, simpler, “white-box-like” (or even white-box) devices.
It’s not going to be as good a business, though, because it can’t be. You can’t make buyers spend more on a transformation when their primary transformation goal is to spend less. Router vendors will have to accept that their sales, and their organizations, are inevitably going to get smaller. “Shrinkage” is tough to sell as a mantra in growth-driven Silicon Valley, but it’s preferable to vanishing. Mainframe computers and even minicomputers once drove the IT market, and neither do that today. DEC, Data General, Perkin-Elmer, RCA, CDC, and others all had to learn that success is riding the wave of change, not being drowned by it. So do today’s network vendors, and just because past initiatives aimed at this radical sort of transformation failed, it doesn’t mean that eventually, even accidentally, someone won’t get it right.