I just got some interesting information from operators on the business case implications of early NFV tests and trials. I’d been trying to harmonize a series of lets-face-it inconsistent stories on what was going on. The results perhaps explain some of the disconnect between the CIO and the CTO, and perhaps even some of the coverage of NFV stories. It certainly brings some clarity to what might happen in NFV deployment.
The most important point operators made was that their early NFV activity was not designed to prove a broad business case for NFV, but rather to prove out the technology and perhaps (yes, that word again) get some insight into low-apple opportunities for actual field deployments. With very few exceptions, operators said that they didn’t yet have a service lifecycle process in place into which they could integrate NFV, and that limited where it could be used.
That turns out to be an important point. A large majority of operators (outside the CTO area) believe that the primary attribute associated with advancing NFV out of lab trials and PoCs is contained impact. That’s why things like virtual CPE have advanced, but more specifically why the CPE-hosted version has advanced.
According to operators, those low-apple NFV opportunities have two specific attributes. First, they involve static deployment of functions not dynamic deployment and function migration, and second they are almost always going to involve something at the customer demarcation—CPE on the customer premises. These attributes help operators avoid dependence on broader lifecycle management and exposure to large first costs.
The first dynamic, cloud-hosted, virtual-function-based application could cost a fortune because it’s the only thing dipping in the resource pool. Given that full-service lifecycle management isn’t available, there’s little to be gained from a lot of cloud-hosting-generated agility either. In fact, it’s not clear that you could even onboard a service-chained virtual element, much less manage it. If, however, you stuck a commodity general-purpose box on premises, you solve your problems in a stroke. You have no resource pool to manage—a customer’s features get dumped into the customer’s box. You have no complicated management problem because it would be possible to place management agents in the box, which would make managing it little different from managing any other device.
Where things get a little complicated here is the question of what specific functions are in the box. Operators who are incumbent providers of business services note that their customers stabilize on the features they want fairly quickly, and so there’s not a lot of real value in dynamic changes. The corollary to that is that the biggest benefit you’ll reap is the reduction in capex you might experience. You’d like a function that’s pervasive and has a high appliance price.
What operators are really interested in is replacing edge routing functions for VPNs, meaning that they’d host the router in a generalized box on prem, and then perhaps evolve to hosting it in an edge office server. You can see that this approach has benefits to both customers (who could dodge all the MPLS VPN management) and operators (who could dodge expensive routers in favor of software routers). The downside is that this model starts to look a lot like SD-WAN, which operators are trying to come to terms with.
The problem SD-WAN presents is that it’s an overlay technology, meaning that OTTs could build VPNs on top of some other service, including the Internet, and compete with expensive operator VPN offerings. As is always the case, the threat is double-sided. If operators jump into the space, they cannibalize their own service base. If they don’t, somebody else cannibalizes it, but perhaps later on. But the big question with SD-WAN is broader than that, which is whether that model could obsolete a lot of SDN and NFV notions completely, meaning that maybe operators need to think more about its long-term impact.
If an SD-WAN model, or even an approach to one, is in the air, network technology would shift from a service mission to a transport mission. This is generally what the MEF has envisioned (and positioned badly) in its Third Network model. Such a network would have a lower cost base for business services, both in capex and opex, and so adopting it would defuse some of the other initiatives aimed at cost reduction. I’ve said in prior blogs that if you were to conceptualize the optimum way of doing networking based on all available technologies, you’d do an overlay SDN.
Overlay SDN doesn’t address all the issues, though. Just because something might be more agile at the infrastructure level doesn’t mean that agility will be realized in the service lifecycle delays and costs. What the operators’ initiatives in NFV tell me is that they are implicitly reacting to that long-standing separation of service operations (OSS/BSS, under the CIO) and network operations (the physical network and NMS).
With proper support from the ETSI ISG, from the TMF, or even from vendors who had the full solution to service automation, we could have advanced infrastructure and operations in lockstep. It now seems to me that we’re defaulting to separate evolutions, that network technology and those in the operator organizations that support it will not be able to influence service automation much. It may have to be a CIO move.
Does this delay transformation? It depends on how the transitions are timed. SD-WAN coupled with a strong service automation and orchestration story could realize nearly all the goals that have been set for SDN, NFV, and everything else at the infrastructure level. Realize them, in fact, at a lower investment and risk. If CIOs were to see (or be made to see) this, they could become the drivers of the new age. If not, then we would have to see coordinated benefits from two largely discontinuous activities in order to get the optimum outcome. Given that we’ve not seen either of the activities take off to date, that could be a problem.
I said in a recent blog that in theory the optimum place for orchestration aimed at service automation benefits was a boundary layer that overlaps infrastructure and management below and service management via OSS/BSS above. Either OSS/BSS types could play in this, or full-spectrum service-automation NFV vendors could take a shot. However, what operators are telling me today is that they aren’t pushing NFV initiatives that drive broader operations automation. I believe that’s because they can’t socialize the solution the NFV vendors would present with their operations counterparts.
The role the TMF could and should play here, then, looms large. If operations needs to transform separately, it’s difficult to see how that can happen when the mouthpiece organization for the CIOs isn’t playing their best game. The TMF just dumped their CEO, but they still have a lot of people who were there through the current stagnation. Can they find momentum now? If they don’t then transformation probably stalls until they do.