A debate is raging over whether solving the management and orchestration challenge of virtualization requires a common information model -- or whether the effort to create such a thing will actually hinder progress.
Common information models (CIMs) were a hot topic at last week's Light Reading event, "OSS in the Era of NFV and SDN," where there were passionate stands taken on both sides -- and even some in the middle. It's particularly interesting to explore the debate in the run-up to a CableLabs -sponsored meeting of multiple standards development organizations (SDOs) that's set for Louisville, January 13-14, on the very topic of converging information modelling on NFV.
During a London panel debate devoted to service orchestration, for instance, some panelists argued that a CIM is absolutely essential.
"It's important to agree on a common information model and data model," said Klaus Martiny, NOC vice-chair and leader of network management and orchestration for the Next Generation Mobile Networks (NGMN) Ltd. 's 5G Project. With a common model in place, he said, everyone can then use their own data and create their own services. A couple of other panelists agreed with Martiny.
But Stefan Wallin, senior product manager with Cisco unit Tail-f Systems and a major proponent of the Yang data modeling language, disagreed vehemently. In his view, a CIM becomes an arcane document that sits on the shelf and requires massive systems integration by experts. What the industry needs, Wallin said, are data models that can be consumed by software -- as opposed to those done in a Unified Modeling Language (UML) -- to automate processes and allow services to be defined in very customer-specific ways.
Caroline Chappell, principal analyst with Heavy Reading and chair of last week's event, points to that panel discussion as a classic example of the debate over CIMs.
"The industry is divided between a top-down, architecture-led approach -- using a CIM -- and a bottom-up, code-led approach," she said. "The problem is that there are so many information models out there and they are written in UML [unified modeling language], so you can't actually program with them -- they have to be interpreted and that's when the variances and vendor-specificities creep in. However, they are good for helping people realize they are talking about the same thing," she added, citing the TM Forum's SID Information Framework as an example.
Getting a single view
At a time when so many aspects of management and network orchestration are in flux and many pieces of the NFV infrastructure are still being defined, having a single view can be helpful. Andy Reid, chief network services architect at BT Group plc (NYSE: BT; London: BTA), pointed out during a TM Forum workshop held the prior day that everyone in the industry seems to be coming at the NFV MANO from their own perspective, whether it's related to virtual CPE or some other piece of the network. (See BT Wrestles With NFV Orchestration Confusion.)
"People are coming at this from different ways, so the idea is to have a common information model so everybody understands" what different elements do and how they interact is helpful, Chappell notes.
That's the positive view. The problem is, she adds, creating a CIM "could take a lot of time," and there is no certainty that a long process stays on track. The fear would be that such a process would delay the pace at which the industry moves forward with virtualization. The multi-SDO effort currently underway will bring together existing information models and identify common ground between them, Chappell notes, and the hope is that 80% to 90% of what's out there can be reused for a proposed CIM, which would significantly reduce that development time.
The possibility of a longer process is one of the reasons that folks such as BT's Reid are pushing for layers of abstraction, Chappell notes, so that flexibility (and speed) can be built into the process. But even deciding on the levels of abstraction requires broad industry agreement and at the end of the day, if the model can describe network elements but doesn't understand behaviors, then much of what is needed in terms of end-to-end operational automation may be lost, she notes.
Next page: The microservices approach