It's been a rough week for ONAP, public relations-wise.

First my colleague Iain Morris reported on something of a groundswell of negativity about the open source MANO project, much of it generated at Light Reading's "OSS in the Era of SDN & NFV" event in London last week. Then veteran industry analyst Tom Nolle, president of CIMI Corp. , added his voice in a blog post , saying the LR news analysis didn't go far enough in assessing basic faults in Open Network Automation Platform (ONAP) 's approach. (See ONAP Takes Flak as Telcos Prep for Release 1.)

Arpit Joshipura, general manager of Networking & Orchestration for the Linux Foundation , which hosts ONAP, is well aware of what's being said, but comments in an interview that the criticisms are coming from people who lack in-depth familiarity with ONAP and the contents of its upcoming first software release, Amsterdam, due out by year's end.

"I can accept the fact it is difficult to figure out and navigate everything we are doing, especially for people who are not members," Joshipura comments. "We have been trying to communicate with the broader community outside our members, but we have not spent a lot of effort on marketing or packaging information for non-members, we have been focused on our work. So there may be some confusion."

One misunderstanding he sees is that ONAP is being discussed by its critics as if it were a product, to be adapted and deployed, and that's not the case.

"ONAP is a platform, not a product," Joshipura says. "Platforms by default means it has as many components as it needs. It has the flexibility of picking and matching and mixing components and you can take one of more of those components and package them into a product and sell it, or package them into a service and sell it."

For example, he says, the original AT&T Inc. (NYSE: T) code that went into ONAP used OpenStack as an NFV infrastructure and OpenDaylight as its SDN controller, so ONAP has OpenStack and OpenDaylight as modules, but it also has the flexibility to support other NFVis and other SDN controllers.

Figure 1: Linux Foundation's Arpit Joshipura

"ECOMP and OPEN-O [which merged to form ONAP] are both hardened code bases, used in production," Joshipura says. "In merging them, we added as much flexibility to the platform as we could, it is multi-VIM, multi-cloud, multi-controller."

One of Nolle's criticisms is that ONAP isn't being built as a multi-purpose tool, but rather to support a specific and limited set of applications, reducing its usefulness as a management and network orchestration solution for network functions virtualization.

Joshipura says Nolle is interpreting information about ONAP incorrectly, that in fact it isn't being developed in a limited way at all, although the first release will include three specific application blueprints -- he hesitates to call them use cases -- that its members requested.

"What the member community wants is immediate deployment of three [specific applications] -- these are blueprints for deployments, which are most immediate requirements for this year's deployment," he says. Those include voice-over-LTE, including IMS and a virtual evolved packet core (vEPC), network-on-demand and virtual CPE, the application Nolle discusses. But ONAP is in no way limited to those and what it will provide is modular pieces that can be combined by member companies to create those solutions.

"We are not here to provide a solution or product," Joshipura. "This is a platform, [members] will take the platform and depending on what EPC they want, the platform supports all the interfaces and structures for that. There's more than 50 examples of that across the platform in which you can use ONAP in a very innovative way. We are not doing blueprints for all use cases, but we will do a few examples and the rest of them are what vendors are already doing and deploying."

He strongly refutes criticisms that ONAP is not production-ready, saying multiple service provider members are planning deployments or trials and pointing to the fact that the ten largest networking companies, including Ericsson, Cisco, Huawei, ZTE, Nokia and more are very actively working in ONAP alongside active operator members. Joshipura points out that one of the critics quoted in the Light Reading piece -- David Hughes of PCCW -- is with a company that is technically a member, by virtue of its acquisition of HKT, but has not yet become active in ONAP and may not be familiar with its details.

Want to know more about managing and orchestrating virtualized networks? Check out our orchestration section in the Light Reading NFV channel.

Joshipura believes the in-depth briefings ONAP will be providing in advance of Amsterdam's release may quiet some critics but he's also realistic enough to know that there will always be skeptics of projects as ambitious as this one. And, he points out, in some cases the criticisms may be coming from someone within an operator or from a vendor whose jobs and/or products may be threatened by the internal transformation process or who may simply be out of the loop on this particular discussion.

It will be ONAP's job to present a more detailed and accurate view of what it is doing and what lies ahead, Joshipura says. "That is something we can certainly do more of."

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