The next two weeks are going to be very important for network functions virtualization (NFV), and also for the evolution of operations practices overall. Next week, the TMF launches its Team Action Week activity, which will include the presentation of a number of “Catalyst” demonstrations on NFV management. The following week is the quarterly meeting of the ETSI NFV ISG, and there are sure to be many discussions around the growing field of proof-of-concept demonstrations of elements of NFV implementation.
The reason this is all so important for NFV is that the concept is evolving in a mission sense even as it’s developing in a specification sense. Operators, as I’ve noted, are no longer seeing reductions in capex as being the primary drivers behind NFV deployment. Instead they see reductions in opex and improvements in service agility as the benefits they’ll try to reap, and the challenge is that both these are likely at least in part if not largely out-of-scope to the ISG’s work.
It’s not that the ISG doesn’t want to manage services or create them quickly. The ISG’s focus is on how to deploy services by instantiating virtual functions on servers instead of connecting physical devices. This necessarily includes how you would define services based on network functions and how you’d organize and deploy the software components that make up the virtual functions in the first place. It also includes how virtual network functions are managed, and how existing network features become “virtual network functions” to be deployed. All this is in the original ISG mission statement; replace purpose-built appliances by software running on commercial-off-the-shelf (COTS) servers.
The challenge is that most services, even in the long term, will include many legacy components, and the management and deployment of the service as a whole are part of this “out-of-scope” stuff. The smaller the contribution of virtual functions to a given service, the less impact ISG work can have on overall service operations—both cost and agility. You can make the NFV part of a service as cheap to operate and as agile as you like, but if you can’t deal with the majority of service elements then they anchor your practices and costs and you don’t reap much overall benefit. In the critical period of transition to NFV, when virtual-function-based service components are minimal, the orchestration and management tools designed to facilitate their deployment would have minimal impact on operations overall. That could mean little or no early benefit, making it harder to roll out NFV.
What makes this month so interesting is that juxtaposition of TMF and NFV ISG activity, a coincidence in timing that seems to cry out for a unity of purpose. The TMF is normally the standards-setter for management, and among the Catalyst proposals for the June TMF meeting in Nice are some proposals that include the melding of NFV management with TMF principles. Unlike the ISG, the TMF has the broad responsibility for service operations and agility so everything that represents the current goals of NFV is within TMF’s charter. However, the TMF’s turf is rooted in current OSS/BSS systems, and the practices here have traditionally moved at a pace that makes “glacial” seem downright speedy. So what we have going on at the end of February is the intersection of two activities that have a common goal but different missions and different practices.
There is a liaison between the two bodies, but it’s not clear how the traditional liaison process could drive the kind of almost-interlocking cooperation needed. The operationalization of networking depends, in my view, on the creation of a series of functional-system models that might then decompose into lower-level systems. For example, the function “firewall” should be modeled and managed uniformly regardless of implementation, but when you look at the function closely, it could decompose into the provisioning of a device or into the deployment of some number of NFV VNFs. This is the process I’ve always called derived operations, and the model I’m describing is an evolution of the TMF’s GB942 contract-mediated operations. TMF, then, has defined the high-level future of operations, and the ISG is working on the application of (unspecified) operations principles to virtualization, the latest problem to be faced.
The cooperative challenge, I think, derives from this TMF-top-down, ISG-bottom-up decoupling. The logical place for the two to meet (in the middle, hint! hint!) is somewhere neither are assured of getting to any time soon, if at all. I think that it would have been pretty easy to have set TMF-evolved frameworks for the higher-layer functional-system modeling and then let the ISG define the dissection of the NFV side of the implementations. It might not be as easy to harmonize to that vision at this point, either technically or politically.
Operators for sure think that the ISG is more theirs to control than the TMF, so they may well see the ISG work as the preferred path. However, the whole contains all of the parts and not the other way around, so the fact that the TMF does have the scope to present a total solution could be the deciding factor. That’s particularly true if the ISG doesn’t shed its tendency to narrow its focus to accelerate its process. The media likely doesn’t care much as long as they can say somebody is losing big, so you’ll likely read about that point as winter turns to spring.
I think the best answer would be to somehow combine the activities in a constructive way. Orchestration principles, management principles, could be applied to the NFV work in particular, but to networks in general too. Everyone who’s read my blog here knows that I architected such a model of derived operations, basing it on GB922/GB942 principles and the ETSI ISG E2E architecture. As the homepage of the CloudNFV website declares, “Tom Nolle, the original Chief Architect, contributed the entire design for open publication and use without restrictions.” There are likely other models that would also serve at least as well, but just the fact that there is one proves that technical unity is possible here. I think the evolving NFV goals of operators, the opex improvement and service agility, say that NFV/TMF unity of purpose is essential.