NFV Specs/Open Source

NIA Tests Reveal OpenStack Version Challenges

ROME -- The latest New IP Agency (NIA) report, being released here today, shows advanced software from multiple vendors is addressing some NFV deployment challenges but that interoperability issues around OpenStack -- the key NFV infrastructure component -- are still holding back multivendor NFV deployments.

Despite that ongoing challenge, significant interoperability progress is being made, according to the findings of the test program report, which is being released here today to coincide with the latest meeting of The New IP Agency , the non-profit group that supports the development of open, advanced, virtualized IP networks. (See 2016 NIA-EANTC NFV Interoperability Test Report.)

Over the course of multiple interoperability evaluations during its first year of operation, the NIA achieved a 69% success rate in testing 33 commercial solutions -- virtual network functions (VNFs), NFV infrastructure (NFVi) components, VNF managers and NFV orchestrators -- from 23 members. This included the extensive VNF to NFVi Interoperability Program, whereby VNFs from vendors such as Fortinet Inc. , Infoblox Inc. , Mitel Networks Corp. and Procera Networks were run on an NFVi from either ADVA Optical Networking , Cisco Systems Inc. (Nasdaq: CSCO), Dell EMC, Huawei Technologies Co. Ltd. , Juniper Networks Inc. (NYSE: JNPR), Nokia Corp. (NYSE: NOK) or ZTE Corp. (Shenzhen: 000063; Hong Kong: 0763).

The seven NFVi vendors deployed their hardware at the Berlin labs of European Advanced Networking Test Center AG (EANTC) where, with help from testing vendor Ixia (Nasdaq: XXIA), evaluations were conducted in two separate campaigns: the VNF to NFVi Interoperability Program; and the VNF Manager to VIM Interoperability Campaign. One testing VNFs and NFVis, while a separate set of tests looked at interoperability of individual VNF managers with the overall Virtualization Infrastructure Manager (VIM). Results of the latter test are not being released yet, because of multiple issues needing resolution that are specific to the companies involved. (See NIA Replacing 'Old Standards Bodies,' Says Cisco .)

In addition, the NIA conducted a Service Chaining Orchestration Showcase, which involved the construction of a complete NFV scenario, involving NFVi, VNFs, VIM (virtual infrastructure management) and NFVO (NFV Orchestrator).

The key findings of the report center on the OpenStack challenges, where telecom operators and their vendors are finding that vendor implementations differ, based not only on which version of OpenStack a vendor uses but also on how it is implemented. Nomenclature is not all common and in making the testing work, EANTC often had to "dig deep into the policy, tenants and topology configuration" to make things work, despite providing a single template for all NFVis to use.

"In the end, we had to handle each NFVi configuration separately," the report states. "The conclusion remains similar to previous phases: NFVi configuration consumes time. Vendor implementations differ too much to be handled consistently."

In an email interview with Light Reading, EANTC Managing Director Carsten Rossenhövel says multi-version interoperability is needed now and will be more important in the future, "as soon as there will be 'brownfield NFV' installations a couple of years old."

He notes: "The basic problem is that software developers are still in the 'We-are-developing-lots-of-stuff mode' where frequent upgrades are expected, while service providers want to get to the 'Don't-touch-this-important-infrastructure-it's-running-production-services mode.'" That results in a conflict of goals, Rossenhövel adds.

In the past, this challenge was handled in the standardization process but standards for NFV are not nearly ready for this kind of specifics, he says. There are de facto open source software processes substituting for standards but none of those is currently taking responsibility for OpenStack multi-version interoperability, according to Rossenhövel.

The OpenStack Foundation releases come out every six months and support for older releases hits "end of life" after more than a year. There is longer term support for OpenStack releases from vendors such as Red Hat Inc. (NYSE: RHT) but there isn't enough data to assess the benefits of those approaches, states Rossenhövel.

The report provides three specific examples of issues where different versions or implementations of OpenStack created testing problems, and notes in general that it wasn't always easy to determine which exact versions of services and components were in use in an NFVi installation.

"Distributors (vendors) would need to provide such information out of band as of today," the NIA report states. "We strongly recommend to implement better API version control/status operations in OpenStack-derived NFV components."

Another key finding of the report is that migrating VNFs remains tricky as well, even though what it was testing was mostly migration of simpler VNFs -- those that used only one virtual machine -- when telecom operators are hoping to ultimately use much more complex VNFs composed of software based on multiple VMs. The issue was that the resources of VNFs that process traffic on the Ethernet layer, where it is switched not routed, could be migrated but the MAC address tables weren't automatically updated, so traffic still was sent to the old compute node.

Finally, vendors report that upgrading NFVis is a complex process that, at this point, is only done by the vendors at their own sites. So the NIA tests were mostly done using older versions of OpenStack such as Icehouse and Kilo. While service providers want to get to the point where they can upgrade NFVis in service, on an automated basis, that remains a distant goal at this point. And, as Rossenhövel notes, it's something not yet achievable for mature routing technology.

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

COMMENTS Add Comment
acarrilloa 12/12/2016 | 12:36:17 PM
Looking in the right direction? Maybe the SDN+NFV+Cloud dilemma is not about replacing today's monolithic black boxed solutions in our network by virtualized versions of the same boxes. I find more attractive and easier to integrate if we replace the telco services we provide today ny freshly programmed services that provide better functionality than current boxes in a much faster development cycle, in tune with today's customer demands. Trying to integrate a plethora of many network functions from a diverse number of manufacturers pretending they will automate service provisioning seem to be the wron approach, and the NIA Test confirms it.
Sign In