With the exception of Huawei, network equipment vendors are facing tightening spending by operators. The reason, obviously, is that compression in profit-per-bit that I’ve been talking about—the compression that’s led to operator support for “transformation” and their interest in SDN and NFV. Since SDN and NFV have not evolved fast enough and far enough to generate the kind of radical improvements in cost and revenue operators had hoped for, their only response is to slow capital spending. The impact is greatest in wireline, because wireless is too competitive for anyone to skimp on improvements. Vendors like Juniper with little credible wireless contribution to make suffer, obviously, but nearly every vendor who isn’t a price leader is feeling the pinch.
So what’s to be done? While I might be (and am) confident that there’s a way out of the compression problem, I’m not the guy who’s going to be stuck with an enormous technical albatross if the method doesn’t pan out. Operators have long capital cycles and so they’re unusually risk-adverse with respect to writing down failures. They either have to reduce the risk you’re doing the wrong thing, or they have to do nothing—or more precisely they have to do nothing different and risk-building in terms of architecture, just build with cheaper components. Hence, Huawei.
Vendors across the board have failed to deal with this resistance to failure, and some add insult to injury by promoting the OTT notion of “fast fail” as a model the operators need to adopt. There is no way of fast-failing a trillion-dollar infrastructure. What operators need, and have always needed, is a set of new-approach hypothesis that link directly to a benefit, and that can be proven out in a modest-scale trial. The biggest casualty of bottom-up specifications is the potential to fulfill this need. The early work has no business context in which it can prove either benefits or realization.
But OK, we’re here and it’s now. AT&T and Verizon have both issued papers describing an architecture model and these should resolve a lot of the issues, right? Not so fast.
What AT&T has done is set goals, which can define benefits. What Verizon has done is frame a solution set inside an architecture. You can do a lot with these two, particularly if you could somehow combine them, but guess what? Vendors are singularly unimpressed with, perhaps even unhappy with, the two approaches. “Selling” has become not a fitting of your product plans to the demands of your buyers, but rather a coercion or manipulation of your buyers to accept what you’ve decided to produce. The reason, of course, is that vendors want to make money and their fondest wish is that operators just suck it up and buy stuff and forget all this newfangledness.
What we need now is recognition that resolving the problem of cost reduction without killing vendor support for your initiatives must lie in focusing on costs other than equipment costs, and in achieving transformation on a large scale without making infrastructure changes on a large scale. As I’ve said in past blogs, this means focusing on opex reductions that can be achieved by a higher layer of orchestration, one that accommodates both legacy and new SDN/NFV technologies. That would let you test and realize benefit-based changes without forcing you to commit to major infrastructure upgrades that could only be justified if you were sure they’d work.
The problem getting to that (happy?) goal is a combination of the fact that when you do a bottom-up spec you don’t get to the top till the end of the process (if at all) and that same old issue of vendor self-interest. Network equipment vendors are reluctant to embrace top-down abstraction-based operations because it anonymizes network equipment and threatens incumbencies. IT vendors in the SDN/NFV space are similarly reluctant because these top-down approaches don’t sell servers right away. And everyone is reluctant because, in the main, they don’t have the top-layer tools in place.
One of the most important developments in this area is the emergence of operator-driven initiatives to define holistic SDN/NFV architectures. Verizon, in particular, has emphasized the notion of a layered orchestration model that would allow a higher-level orchestrator to harmonize not only legacy and emerging network technologies but also multiple vendor-specific implementations. This overcomes the fact that neither SDN nor NFV standards include modernizing operations practices or incorporating or evolving future networks from legacy deployments.
Another potential solution is the use of a generalized orchestration model, championed by some of the six vendors who have complete NFV solutions (ADVA, Ciena, and HPE in particular). This approach could in theory be applied two ways—a top-to-bottom orchestration architecture and a selective architecture. With the former, the vendors’ solutions would be accepted as the only orchestration approach, and this seems to run afoul of the current service-specific SDN/NFV evolution trends. With the latter, you’d adopt the generalized orchestration model where there’s no competing implementation, and use a stub/adapter to incorporate the competing models by supporting abstractions that represent them.
It’s this last approach that shows the most promise, but vendors have not been enthusiastic in promoting it. Part of the reason is that most still hope to achieve their own “lock-in” of early NFV deployments, and fear that embracing an open model would hurt them as often as help them. Part is the fact that you have to implement the stubs to represent “foreign” models, which of course means that there has to be some foreign model structure to represent. At this point, absent any specific intent-model requirement for NFV or SDN (SDN’s is coming along), that could be challenging. In particular, it would leave the top-level orchestration vendor at risk to changes made by vendors below.
That problem, unfortunately, can happen in any multi-layer orchestration approach, and that’s why in the end the operator models may be the only hope. Verizon or another Tier One could compel vendors to open and stabilize their models so that lower-level service-specific implementations would fit inside an end-to-end orchestration model. Other vendors almost surely could not.
Everything comes back to the point I made about vendor differentiation and model-based abstraction. If operators think of equipment as simply a realization of a given abstract model, then it’s harder for vendors to differentiate. Operator-driven models would probably not include special differentiating features from vendors, given operator demands for an open approach. Vendors need to somehow support open-network goals and retain some opportunity to exploit their own special sauce.
The first-quarter slump in operator spending (which vendors want to believe is just a blip on an otherwise untroubled horizon of spending growth despite ROI compression) argues for taking decisive action. A vendor could develop an operations-savings approach that would at least mitigate the problem of loss of differentiation. For example, they could develop their own models to link their lower-level management systems to EEO tools, which could then exploit their own differentiation. As long as their models only enabled these special capabilities and didn’t mandate them, would operators refuse them? Probably not, and they might even use the features if they were valuable, even at the cost of openness.
Remember too that Verizon and AT&T are emphasizing a shift to white-box products, which means products non-differentiable at the data plane level. Verizon has also explored the notion of displacing physical routers with software instances, recognizing that hardware acceleration may be required for the hosting. I think that widespread use of router instances will also require “virtual-wire” partitioning of traffic at L1/L2 to eliminate large L3 aggregation missions that servers are never likely to be able to support efficiently.
I said early on that if vendors did not find a way to secure significant non-capex benefits through SDN and NFV, operators would re-architect networks to reduce spending on switching and routing, and also achieve opex savings through L2/L3 simplification. I think that’s happening. I think that everything happening in the network market today demonstrates a need for vendors to push an operations-savings approach, and to take control of the way their own orchestration and management tools integrate with emerging high-level EEO tools. In fact, I think that vendors have already lost millions by not having this capability, money operators would have spent on infrastructure had the profit compression pressure been relieved by operations savings. Not losing any more should be a priority.