The TMF event in Nice this week is a focus for an important issue in the evolution of networking, which is the way in which existing network and operations elements relate to newly introduced technologies like SDN and NFV. The Forum promoted its “ZOOM” project, which is aimed at modernizing OSS/BSS models and introducing (hence the play on the name) faster responses to service problems and opportunities, and some of the Catalysts have been aimed at showing how cooperative evolution can work. What’s interesting to me here is that there are two underlying realities being demonstrated at the same time, and these operate against the Forum’s explicitly stated goals.
Carol Wilson, who’s covering the event for Light Reading, commented that open source seems to be establishing a competitive position with ZOOM, at least insofar as implementation of next-gen operations models are concerned. She goes so far as to suggest that ZOOM be considered an open-source project rather than an evolution to OSS/BSS standards.
Most of you know that I’m actually working on defining an open-source implementation of management and orchestration tools (my first tutorial may be out late this month, in fact). Given that, I’m hardly likely to dispute the value of open-source in OSS/BSS evolution. However, my experience shows that there are fundamental challenges in using open-source tools, challenges that have to be addressed right up front. The difficulty for the TMF may be less one of open source as one of timing.
For somebody to kick off a complete open-source MANO project today, and base it on the presumption of new development, would be an exercise in futility. It would take too long, and it would duplicate dozens of other open-source activities that are already doing good work in subsets of the total problem space. The right open-source OSS/BSS solution doesn’t have to be developed, it has to be identified, and then customized a bit to fit these available tools together in a cohesive way. That means starting with a high-level vision of what tools you’re going to use and how they’ll integrate.
The problem this poses for the TMF, and also for OSS/BSS vendors, is that OSS/BSS standards and structures don’t reflect natural open-source boundaries because the dominant implementations aren’t open-source. I can define open-source implementations for the major elements of MANO and also demonstrate how they can integrate with existing OSS, BSS, and NMS elements but when I do that what I am really doing isn’t supporting a ZOOM project or implementation or evolution. I’m making one unnecessary.
We’ve seen a couple of TMF-related announcements and Catalysts, notably the CloudNFV one (disclosure: I was founding architect of CloudNFV) and NetCracker. While the available information on these implementations won’t support a complete analysis of the approach, the material does show that both build what I’ve called a “shim layer” between infrastructure and operations tools and the OSS/BSS processes. Rather than propose massive changes to operations systems and practices, they propose to support evolution at the technology level through a process of consistent abstraction. Legacy and evolving processes and service elements are presented in simplified form to higher operations levels. This is possible because the differences, the details of orchestration and management, are harmonized in the shim. Thus, the Nice events are demonstrating that you don’t need ZOOM to “zoom” in terms of service velocity or operations expediency.
None of this has to be a bad thing for the TMF. There’s nothing wrong with advocating a shim layer and with the notion of consistency of abstraction as a framework for ZOOM. The problem, as I’ve said, is timing. If you can really build open-source-based shim layers for operations, then you need to focus on how that is done and what the interfaces really have to be. Not what a standards body like the 3GPP or TMF or even NFV ISG might think are needed, but what are presented by the open-source components you’ll need to leverage. If you don’t recognize the intrinsic component structure of an open-source solution assembled from components, you’ll define workflows and connections that can’t be supported without writing more code, and you’re lost in terms of market relevance.
The same, arguably, can be said for the MANO implementations that are coming out as we speak. So far, nobody really has a complete story of MANO because nobody tells a story that envelopes the essential pillars of evolution—support for where you are and for where you need to get to. The fact we’re gravitating to shim-based solutions without acknowledging that’s what we’re doing doesn’t mean the necessity of the shim approach isn’t being proved, only that we’re not going about the process as we should be. You rarely happen upon the right answer while digging randomly in the technology diamond pit.
I would like to see an open-source project here, but I’m not sure I’d want it to be ZOOM-based. The TMF specifications and legacy OSS/BSS structures should be accommodated, just as legacy infrastructure should be. I like the notion of having the NFV ISG promote an open platform model too, but I wonder whether that would work. Why do I feel this way? It’s back to timing. The right way to do our MANO shim is the fastest way that works.
That’s going to be by assembly, not by new development. Could TMF people come up with that, given that they are influenced by the desire to perpetuate the value of their current work? Could a group of NFV people do any better given that they’d try to build to the structural model they defined in their own specs, rather than build to optimize the use of current open-source tools? Would the proprietary implementations of MANO provide for the integration of open-source elements? The problem is that we don’t know the answers to any of these things yet, in no small part because nobody is providing much detail on exactly how “shimming” works, even though their solution relies on it.
I think this is going to change, and frankly I hope to be at least an instrument in making it change by defining what is at least one example of an open-source approach to MANO that does offer explicit integration of infrastructure and operations tools. But I also think that competitive pressure will drive others to try to do the same. That at least will get our MANO debate and our open-source interests where they belong—on the same page.