There are a lot of ways to transform networks, but the most fundamental way would clearly be to build them differently, meaning not only different vendors but different network architectures. We’ve kicked around a bunch of suggested new approaches but none of them have really gained traction. The best proof of that is that Cisco still turns in what’s probably the best vendor performance, and they’re legendary for changing positioning a lot and product only a little.
The problem with a transformational architecture, of course, is that it’s hard to convince network buyers to make massive changes, particularly to something that’s largely (at this point, surely) untried. When you try to ease into transformation, you run into the problem of balancing the benefits and costs/risks. Each step of a transformation, according to network buyers, has to be justified on its own. Each step has to present either (at the early stages) an avenue for graceful retreat, or (at later stages) an opportunity to hunker down on the current state and stay there.
All of this is complicated by the fact that we’ve been transforming for decades now, but doing so without really planning out a path. In the ‘80s, networking was based on public TDM trunks and user-added nodal devices. By the end of the decade, that single path had divided. We still had trunk-and-node networking, but we added two streams. One was what we could call the “packet services” model that included frame relay and ATM, and the other was the “Internet model” based on IP.
There are a lot of reasons why frame relay and ATM failed, but the biggest reason was that the Internet was a new application that brought its own service model along. The explosion in Internet use created a revenue opportunity and traffic flows that were not only bigger than the old business private-network past, but created a network that could carry that same business VPN traffic. However, part of the problem was that the transformation of the current (then-current, now old private-network) model took too long and didn’t present risk-free and easily justified steps to buyers.
We can see the same sort of thing today. Could you “replace” IP networks with SDN? On the scale of the Internet or even a large VPN, companies and operators agree privately that’s a doubtful proposition. Could you replace routers with hosted instances? The same people say it wouldn’t be possible overall, though for smaller-scale nodes it would work. What can we do then to “transform” networks?
Everyone I talk with believes there are two basic truths. First, you have to separate service networks from transport networks. That offers two benefits. First, traditional technology like fiber and new options like the 5G/FTTN hybrid can be introduced without impacting services themselves, which is critical. Second, service networks are per-tenant or per-mission and smaller in traffic scale than transport, so you could hope to use more hosting and less appliances. Second, you have to make a significant improvement in opex to help fund your changes, and finally you have to link the transformation to new revenue, meaning new services.
Virtualization is a big part of all of these points. Separating service networks from transport is really saying that we need to elevate our notion of transport to subsume some of the features of service networks. Virtualization, meaning the creating of tunnels, “pseudowires” (in memory of my good friend Ping Pan, now passed), or virtual routes, is a way of constructing the underlayment of a service network in a way that’s most convenient for the specific service network mission. If this is extended to include rerouting traffic and resizing paths, then the features of the transport network would improve to the point where simplification of the service network is possible.
Service/transport separation can thus reduce costs by reducing the complexity of the overlay (Level 3 in the current network). You could imagine that a mature virtualization-of-transport strategy could let us build service networks with something very much like SD-WAN technology linked to agile transport paths. These SD-WAN-like nodes would be simpler than today’s routers and also fully hostable, which means they could be done with open technology.
One thing I think would enhance the value of the nodes in this approach is the use of the P4 flow-programming language. The value of P4 is that you can use it to implement a full suite of router features, but also to implement firewall-like forwarding (SD-WAN) and even SDN OpenFlow forwarding. P4 can be adapted easily to custom silicon for accelerating the forwarding process.
Of course, the opex benefits of this approach could also be significant. Application of service automation to the virtual transport layer is fairly easy, and you could use cloud orchestration to deploy the service nodes. That’s because you’re building virtual routes upward from the optical layer, and you have little or no legacy technology in the network to have to co-manage. Instead, you’d simply let legacy stuff continue to use the optical network directly, running in parallel with the new service network.
From an evolution perspective, that means a bottom-up play by optical vendors would be very smart. That’s why I’ve been disappointed in the lack of aggression Ciena has shown in positioning this approach. However, it would also be easy to build to this model starting with the service network at the top, and that may be what’s in store for us if operators like AT&T continue to promote a new cell-node model. Some sort of virtual network is explicit in 5G overall, and if 5G deployment happens on a fast-enough pace we might see enough 5G-virtual influx to establish a top-down path into our preferred model.
Enterprise use of hybrid cloud computing could also create a service-virtual-network top-down opportunity. Again we could look at SD-WAN, which is a simple model for supporting enterprise connectivity without MPLS VPNs. Today, SD-WAN almost always rides on the Internet, but an SD-WAN node could also be connected to agile virtual transport tunnels. Such a move would make it possible for operators to build VPNs that were more than tunnels over the Internet but were also more deterministic and used cheaper infrastructure versus MPLS VPNs.
But with all of this, we’re still missing our last point. Remember that what made IP the ruler of the network world wasn’t good evolutionary planning; we didn’t have any such thing. It was the Internet as a new application, the first and only populist data service. Today, the challenge for “new revenue” or “new services” is that there’s nothing likely to emerge in that category that’s not a service on/over the Internet. That means it’s very likely to be an OTT service, open to all the OTT giants to compete in. Thus, it’s not likely to drive a transformation in network technology.
Absent the radical driver of new revenue, all the other benefits of transforming the network itself would have to step up to fill the gap, and that would require an organized approach to a new way of networking. Vendors are clearly not going to deliver on that, and operators themselves seem (in the end) to be either sitting back and waiting for somebody to propose a new model, or trying to build a “new” model based on old principles. NFV, for example, virtualizes devices and thus tends to sustain the old way of networking.
And that, my friends, is the challenge of fundamental transformation. We have a global Internet, global ISPs, global operators, and all of these rely on traditional IP networks. I firmly believe that a two-tier transport/service model would work better, and that vendors could define a migration path to it that would satisfy operators’ cost/benefit requirements and even provide a fairly safe transition strategy, one that you could fall back from early on if needed. However, I’m fairly certain that incumbent router vendors aren’t interested in rocking the boat. That means it will take another class of vendor to promote the transition. Optical, cloud, virtual-network, 5G…there are plenty of candidates, but is there the will to take a chance, even in one of these groups that has little to lose and a lot to gain? We may find out as 2019 merges into 2020.