According to a recent piece on SDxCentral, “Operators don’t want the TM Forum to get lost in NFV technicalities. They want the focus on making money.” That’s an interesting and insightful couple of sentences, for several reasons, and it may be a signal of a sea change in NFV. The obvious question is who’s going to chart the change.
I’ve noted in prior blogs that many of the operators believe that the NFV ISG process has gone off-track, getting bogged down in little details of implementation that are actually outside the original spec-finding mandate for the group. At the same time, the body hasn’t found the time to address critical issues in operations integration and federation, issues that could be the foundation of a real business case. That’s left these critical issues out in the cold, to be resolved (if they can be) elsewhere.
One logical place to resolve them is the TM Forum, the body charged with operations standards. The article in SDxCentral is about the TMF, and specifically about the “Zero-touch Operations and Orchestration Management” or ZOOM project that is intended to get the TMF on board with virtual network resources and services. The acronym’s decoding is highly relevant to what the goal should be—we need operations and automation to be zero-touch and inclusive of the virtualization/orchestration processes of SDN and NFV.
So the TMF is riding to the rescue of NFV? To be fair to the NFV ISG, the TMF hasn’t set the world on fire in this space either. ZOOM goes back over a year, and in my personal view it’s not made tremendous progress in that time. In the TMF case, as with the ISG, the problem is likely one of the bias of the people actually involved.
NFV is a software strategy, a software architecture, a software problem. It takes software to solve it, and neither the ISG nor the TMF have really approached this as a software issue. The ISG got mired in standards, and because old-line standards had to be highly specific in some areas and were generally directed at interfaces and little else, the focus of the ISG was directed at interfaces and details thereof. The TMF got mired in its own architecture, in making NFV and virtualization fit within it.
But there is progress being made. Some of the work on Phase Two of the NFV ISG program is very helpful and insightful, particularly as it relates to intent modeling. There is also work underway in the TMF to modernize some aspects of their event-handling and the application map that frames operations processes overall. The question is what this will add up to being.
In my view, the TMF has the inside track on creating something comprehensive. While there’s useful work in the ISG, such as a harmonization of operator views in favor of intent modeling and a recognition that they need operations integration and federation, it’s hard to see how they could get to the right place on that range of topics in a short time. The TMF, on the other hand, has nobody to fear but themselves.
The core of the right approach to NFV is a comprehensive service data model that extends from the top service layer to the bottom resource layer in a unified structure. The TMF SID might not be the way I’d personally have built that model, but it’s quite suitable. There is nothing being talked about in the ISG here except YANG, which I think is a waste. TOSCA is probably the best approach, and one that might win out in the market regardless of what others do.
The next point is the notion of a full intent model representation for every customer- and resource-facing element of a service. That means defining ports and SLA as well as functionality. I don’t see any reason why the TMF SID could not accommodate this, though they’d have to make some specific recommendations to insure compatibility. The more difficult issue would be the notion of derived operations views created by active expressions linking the model SLAs. You could do this in SID, but here there’s certainly a need for an explanatory project.
Following on the expression-linking of SLAs, NFV demands active-chain binding of pool resources to intent-model abstractions that represent them in the service domain. This can be done using SID, but how elastic bindings and active expressions of any sort are handled is in my view a project not unlike the original NGOSS Contract work that gave rise to GB942. It should have been started a year ago.
On both the prior points, the notion of “active” expressions or bindings is outside the range of normal data models. A traditional data element has a value. An active element has a value that is determined by a process executed at the time of reference. Active elements considerably enhance the utility of virtualization-operationalization technology because they allow a reference to a “high-level” variable to drive the derivation of that variable rather than having the variable constantly updated (or out of date!).
The next point is state/event synchronization of service lifecycle processes across the whole data model. Every element of a service must have its own lifecycle states, respond to its own events, and synchronize the stuff that depends on its operation. To me, this is a core feature of any valid service data model. Every object in the model is an intent-modeled sub-service “atom” that has its own properties, lifecycle, and management. This means that every lifecycle activity designed to operate on an object operates on everything, top to bottom, high-level to detail. It simplifies implementation considerably.
A top-down approach to the challenge of NFV would have produced something like these points back in 2013. OK, that’s off the table now, so the question is what process might be close enough to the right answer to do something by next year, which is probably the drop-dead date to preempt operators’ changing from NFV to something else.
None of this stuff is even mentioned in the Phase One ISG material, so it’s my view that it’s doubtful that the body could address all these points in a year or less, even if we assumed that members wanted to (which would be a dangerous assumption). I think the ISG contributed the critical MANO notion, but somebody else will have to carry the torch from here.
The TMF might be the group, but if there’s a body on earth that outdoes the NFV ISG for glacial movement, the TMF is that body. In fact, given their historicity, they arguably set the standard. The only hope the TMF has IMHO is that vendors and operators will present Catalysts that will move the ball even if the formal processes of the TMF are mired in the usual political and personal wrangling. That could happen, but even here we have the barrier of publication. The TMF is a membership-fee body like the ONF, but unlike the ONF its stuff doesn’t roll out to full public view quickly, if at all. A lot of good work the body has done has been submerged, where it never influences the broad media and market.
Remember my blog on the various CxOs in the operator world and NFV’s progress in engaging them? Well, engagement is made primarily through public marketing and media channels these days. Standards groups either sing or they risk irrelevance through simple lack of ability to build decisive momentum in buyer organizations. If the TMF does all the right things with ZOOM and other modernizing initiatives, and fails to publicize the results, they may as well have done nothing.
The media and “public processes” bring their own baggage to this. The fact is that 1) no technology revolution is going to generate legitimate stories at the rate the media needs them and 2) no media type is going to write a story at the depth needed to actually influence a major decision, nor would the editor run such a piece—it would be too big. You get press to sell website visits, and you get press by riding the hype wave. NFV has already passed the crest in that regard, which means that engagement by the TMF or by vendors to get their story out will now be harder. The good news goes back to my opening quote, though. Buyers now know what they want—monetization and a business case—and if they search websites they can still find enough to make progress possible.
