Heavy Reading: Common Data Models Unlikely

LONDON -- OSS in the Era of NFV & SDN -- The push for common information models is running into practical problems that could prevent the industry from ever reaching this Holy Grail, Heavy Reading Senior Analyst James Crawshaw said here today. As a result, the telecom industry is moving more toward an application-programming interface (API) and middleware approach to knitting things together.

In his event-opening presentation, Crawshaw said that while getting to a common information model is a critical part of transforming operations and support systems for virtualization, getting to that stage is proving impossible, because every operator remains convinced of its own approach.

"When I talk to operators, I hear a lot of skepticism," he said. When questioned further on this topic, Crawshaw said many in the industry say finding a true common information model isn't possible, when each operator has its own specifications and way of doing things. "What I hear is that we've tried that and it didn't work."

James Crawshaw addresses Light Reading event crowd.
James Crawshaw addresses Light Reading event crowd.

Speaking on a panel about an hour later, David Hughes, vice president of IP engineering for PCCW, colorfully confirmed Crawshaw's statement.

"I'll see pigs fly out of one of my private parts before we all agree on a common data model," Hughes said. And from his point of view, network operators need to stand up and take responsibility for that and for coping with the multiple approaches.

Because the industry does want some approach that enables Lego-like building blocks, instead of unique snowflakes with specialized treatment, there is a movement to make systems talk to each other via open APIs, and then create a dynamic API or middleware that can manage the process of keeping all those open APIs up-to-date, Crawshaw said.

The Heavy Reading analyst sees the telecom industry's move to open source as a positive and isn't bothered by the sometimes-confusing array of open source initiatives. "We do see competing and overlapping initiatives but that is healthy, because it means competition and survival of the fittest."

He also advised the telecom industry to keep a close eye on where open source is going on the enterprise side of the house, where it is more mature. For instance, Crawshaw noted, if enterprise open source initiatives are moving away from OpenStack and toward Kubernetes and containers, "perhaps the telco industry should think about doing that same thing."

Crawshaw listed five key aspects to transforming OSSs to support network functions virtualization: activation, provisioning, inventory management, DevOps and service assurance. On the activation front, operators need intuitive portals with pre-defined templates for all aspects of services while on the provisioning front, standard protocols based on Netconf/YANG and Tosca will be required to enable end-to-end chaining of functions from multiple vendors, and service rollback. Inventory management needs to be real-time, and DevOps will require tools for testing and deployment, including rollbacks, he said.

— Carol Wilson, Editor-at-Large, Light Reading

bgraham 11/3/2017 | 7:33:35 AM
It is all a question of level It seems that when we debate common data models the assumption is that we are talking about the commonality going right down to the implementation detail. What our members are arguing (and Lester does it most elequently) is that there are plenty of ways of getting the commonailty you need without having to drive it right down to the bits and bytes.

Plug and play does not require the bits and bytes to be the same, plug and play requires a system than can automatically generate the translations without having to do manual integration.

Our Open API program in particular is looking at some of those mechanisms at the moment.
brooks7 11/2/2017 | 11:16:49 AM
Re: Quick Note Yeah, Penguins are the "mascot" of Open Suse (think a nice version of Larry the Attack Monkey).  

What this leads to is that you basically have to manually regression test every patch of every piece of Open Source that you get - no matter who its from.  That little "feature" was only in 1 version and was removed shortly thereafter.  It was done because the code contributor thought it was cute.  It didn't break anything that they tested and so went through the QC process without a problem.

There are software programs that will examine a manifest and see if there is an updated package if available.  The problem is that this means you have to have absolute trust in what you are getting.  Once you say no, that you better test yourself any auto-update goes away.  What you CAN do is create an auto-distribution and update process for approved software.  One thing from the web giants (and we did this as well) is that you roll it out in batches.  Start relatively small and grow over time.  That allows you to have a simpler rollback if you need it.  Note a lot of these auto-updates will need the service to be restarted either temporarily interrupting or slowing service.  For web based services that have some form of load balancing, this is really not a problem.



Carol Wilson 11/2/2017 | 4:47:20 AM
Re: Quick Note Penguins???

Interestingly, by day's end in London, there were folks - Lester Thomas from Vodafone and Barry Graham from TMForum - strongly arguing in favor of common data models, so more coming on this endlessly debated topic. 
kfv 11/1/2017 | 5:40:10 PM
Lets look what was 30 years ago IPv4 was invented more than 30 years ago and 4 byte address looked huge enough at that moment. At 1995 was invented IPv6 because suddenly all understood that IPv4 not enough. 

The same with 12 bit VLAN ID - invented different overlay headers, another kind of complexity.

It is very early to talk that  Common information model unlikely. 
brooks7 11/1/2017 | 1:21:49 PM
Quick Note "and then create a dynamic API or middleware that can manage the process of keeping all those open APIs up-to-date, Crawshaw said."


Just be aware that this does not work today in the IT world particularly with Open Source.  There are often changes that are put in that make incompatibilities - many of which are unintentional.  One of the least humorous that I ran into is somebody in the Open Suse Community made the boot up sequence send walking Penguins across the screen.  Of course, it completely locked up if you were running a server without a screen.  This notion of auto-updates makes a LOT of assumptions of product quality and compatibility that does not really exist.


Sign In