“White boxes in the network” sounds like a bit like “Red Sails in the Sunset” (at least to my generation), but it’s not just about a nice appearance. White-box switching and routing are critical for network operators, and increasingly so for enterprises. I blogged about some initiatives in the space last week, and today I want to look at two more ambitious and cloud-centric developments, and see how they might play in the space.
In my last blog, I talked about two initiatives that could be considered variants on the software router or white-box router theme. DANOS and P4 is an AT&T-sponsored approach to building a routing appliance. 6WIND’s virtual router is a hosted-router-software commercial offering that is often server-hosted but could be appliance-based. Both these approaches fit a software router model more than what I’d call a virtual router model, in that both would likely be deployed in place of a physical device and would, like a physical router, stay where it was put unless it broke.
There are other approaches, of course. One is, like DANOS, a white-box appliance approach, but unlike DANOS it aims at providing a kind of “white-box resource pool” on which virtual routers are deployed according to the service topology requirements. The other is one that focuses not just on virtual routers but virtual cloud networks.
Because it’s a nice transition from the first part of this series, let’s do our white-box solution first. DriveNets, a just-out-of-stealth startup, also has a cloud network solution, designed this time for white-box deployment and so less focused on the “virtual” network than the real one. As I noted above, DriveNets is virtual in the sense that like the cloud it presumes a resource pool, this time of white boxes. Instances of routers are then deployed on that pool.
The foundation of this approach is the DriveNets Network Operating System (DNOS), which is the software platform that combines with white boxes to create the network cloud resource pools. DriveNets presumes these would be distributed in a hierarchy from edge to core, with deeper pools being larger than those at the edge. Thus, toward the edge, the router instances would be more fixed in assignment, and would become more cloud-like as things go deeper. I interpret their material to say that they are able to assign a hot-standby instance of routing processes for resiliency and quick failover.
DNOS can run either on bare metal or in a VM, so you could integrate it with a broader carrier cloud concept if VMs were compatible with your plans. DriveNets makes a lot of container-friendly comments but there’s no detail on whether the implementation is actually based on containers, or whether container orchestration is used.
All this requires an element of coordination, which is provided by the DriveNets Network Orchestrator (DNOR). This does the provisioning and lifecycle management for DNOS-equipped nodes, and plays the same overall role that a cloud orchestrator would play. There’s little technical detail provided on DNOR, other than that DriveNets say it’s microservice-based.
The cloud-centric initiative is from SnapRoute, who has what they call the Cloud-Native Network Operating System, or CN-NOS. CN-NOS is a “disaggregated white-box switch” tool, one that’s integrated into Kubernetes and microservices. Thus, it’s really a kind of a mixture of virtual networking, orchestration, containers, microservices, and the cloud. CN-NOS is, most of all, about cloud virtual networking, a kind of networking where network connectivity and application deployment and lifecycle management are tightly coupled.
You read a lot about containers and continuous integration and development (CI/CD) in the SnapRoute material, which I think shows that the product is focused on making networking a part of the cloud rather than something glued on from the outside. You still need some transport networking, of course, but you build dynamic virtual networks as part of building applications, and then follow that tie-in through the rest of traditional Application Lifecycle Management (ALM), CI/CD, and operational lifecycle management.
From an implementation perspective, SnapRoute is a load image for “disaggregated white-box switches” (to quote their term), one that includes a Linux distro and the specialized CN-NOS integrated-Kubernetes and other tools for lifecycle monitoring and management. Switches so equipped become container hosts for the virtual-switch functionality that is then deployed, using the switches as a resource pool. Since network services are containerized, they can be updated/redeployed like any other container application, and the automation/orchestration for lifecycle management is handled by Kubernetes itself.
Which brings us to another term you see a lot in the SnapRoute material is “NetOps”, a term becoming popular as a description of the need to deploy virtual networks in an automated way following the same basic “declarative” principles as Kubernetes follows for container deployment. Services are made very much equivalent to applications, in that you can deploy them and remove them explicitly, and you can link network services to applications to specificizes the connectivity to the governance/security requirements.
You can see similarities in these last two examples of white-box/virtual networking, as well as similarities between these two models and the two I covered in my prior blog. I think the best way to look at them is to say that DANOS and 6WIND are more “transport” or “network-independent” in their approach, while DriveNets and SnapRoute start to shift more to the virtual, and to a very cloud/container-centric model in the case of SnapRoute.
The challenge for prospective buyers here is that while everyone understands the basic principles of “router networking” and these apply as well to white-box and virtual router approaches, nobody really understands the virtual models nearly as well, and probably not even well enough to be confident. The documentation for both DriveNets and SnapRoute is difficult to navigate; the former doesn’t provide enough information and the latter provides perhaps too container-Kubernetes-centric a picture, lacking a good overview of the architecture and how NetOps and applications would relate to each other.
The question that I think these two offerings pose is that of the relative importance of virtual networks versus “transport networks”. In a cloud data center, in an enterprise using Kubernetes and containers, and for network operators and carrier cloud, I would submit that virtual networking is more important. We can in theory overlay virtual connectivity on any set of transport infrastructure. That was the MEF’s message (not particularly strongly stated) in its “Third Network” story, and it was true then and remains true now. The problem of course is that a virtual network is whatever you make of it, and it’s thus hard to pin down.
One approach to cutting the cost of routers is white-box, of course. Another is the subduction theory of dumbing down Level 3 by absorbing some of its features in an SDN-over-optical approach, something like Ciena sometimes seems to be advocating. Another is the “Third Network” overlay of SD-WAN and virtual networking on top of arbitrary transport. The four products I’ve highlighted in the two blogs on the topic show a lot of this range of options, and more are likely to come along as the industry looks longer at the problem and starts to show a preference.
One thing I think is clear is that simple box-for-box replacement of routers is only a transitional approach. The long-term model has to be more virtual in nature, which favors the two approaches I’ve talked about here. But DANOS and P4 could in theory be used to build a white-box that’s not strictly a router at all, and of course 6WIND could add virtual-network-specific features to its own product. There are any number of possible futures, and only time will tell which unfolds. Remember, Cisco had a great quarter, so routers aren’t dead yet.