ETSI unveils new standard for NFV deployment templates

While there are several anchors on the adoption of NFV architectures, standardizing VNFs has been one of the weightier issues.

Last week the European Telecommunications Standards Institute announced it had published the first version of a specification that it said will standardize the structure and formats of virtual network functions (VNFs).

"The ETSI Industry Specification Group (ISG) on Network Functions Virtualization (NFV) ended 2018 on a bright note, with the publication of the first version of ETSI GS NFV-SOL 001, the specification of NFV descriptors based on the Topology and Orchestration Specification for Cloud Applications (TOSCA)," according to the press release. "This was a highly-anticipated document in the industry, considering the prominent role VNF deployment templates play in an NFV system. Together with ETSI GS NFV-SOL 004, the specification of the structure and format of a VNF package, this new specification provides the foundations of an open ecosystem."

Operators have complained for years that the VNF vendors, including large vendors that were previously mainstays of the legacy telco architectures, have made their own flavors of VNFs, which meant operators had to configure, scale, and rebuild the VNFs prior to deploying them.

During a panel discussion at Light Reading's NFV and Carrier SDN conference in September, Ray Watson, vice president of innovation for Masergy, said that his company needed to deploy 2.2 commercial VNFs just to break even, which defeated the NFV goal of lowering costs with off-the-shelf hardware and software.

RELATED: ONAP drops Casablanca software release while OPNFV advances VNF testing

To be sure, other open source organizations, such as ONAP and OpenDaylight, have also tackled the issue of testing, onboarding and creating VNFs that are standardized.

ETSI is laying claim to solving the VNF issue with the NFV deployment templates, which it said creates an open ecosystem where VNFs can be onboarded and managed "by independently developed management and orchestration systems."

"It provides a standard way to describe VNFs, so they can be deployed and managed by NFV orchestrators," said Bruno Chatras, vice chairman of ETSI NFV ISG (Network Virtualization Industry Specification Group), in an email to FierceTelecom. "This is an obvious advantage for VNF consumers and developers. 

"It has been developed by the ETSI NSP (new standards and policy) and vendors, and it is being used. This has already been exercised in some early (ETSI) Plugtests. ONAP, the open source community, uses it as one of the VNF descriptor formats accepted for its platform."

NFV templates a step forward

BT deploys common service models, or model-based concepts, to create product models across its wider IT infrastructure using TOSCA. This automated configuration allows BT to see what parts of the network need to be upgraded, rolled back or left alone when doing network upgrades.

"It's a good step forward," BT Chief Architect Neil McRae said of ETSI's NFV deployment templates. "BT has been pushing a model-based architecture and approach leveraging TOSCA and YANG models for some time and we have done a lot of work on this at TM Forum. We welcome this."

McRae previously said to FierceTelecom that NFV and other software-based technologies actually make service provider networks more complex, whereas common service models and automation provide deep insights to better manage networks while also rolling out products and services at a faster rate.  

Industry needs cloud native, not NFV

ETSI pioneered the NFV movement with an initial white paper seven years ago, but not everyone is on ETSI's NFV bandwagon.

"The problem I have is that deployment templates for NFV don't address the fundamental problem that NFV has, which is that it's based on a monolithic architecture and a set of tools and practices that diverge sharply from the things we're learning about deployment and lifecycle management in cloud computing," said Tom Nolle, president of CIMI Corp., in an email to FierceTelecom. "What ETSI needs to do is to reorient its approach to match the way that cloud technology is evolving, or it forces operators to ignore cloud-centric and high-revenue future applications to do some modest function-hosting for legacy services.  That's a terrible trade."

Proponents of NFV have said that the promise that was put forth by ETSI was about operational savings and converting the legacy infrastructure with virtualization. In some cases, service providers don't convert their legacy infrastructure unless there's a viable need to do it, preferring instead to use NFV for new products and new revenue rather than focusing on operational changes.

CenturyLink's Bill Walker, senior director of strategy and advancement, said at last year's Light Reading NFV and Carrier SDN conference that his company, which is on its third iteration of NFV, believed NFV was highly successful.

Also last year, Vodafone's Fran Heeran, who will be moving back to Nokia next month, said that service providers should move on from NFV to cloud native implementations to deliver improved benefits to service providers.

Cloud native, or "cloudification," uses microservices, virtual machines and containers instead of virtualizing functions and components. Some vendors, such as Cato Networks, maintain that it's easier to add functionality and features from a cloud instead of managing them on an NFV platform.

"The future performance of the carrier cloud, or the NFV cloud, I do not believe in that architecture at all," said Cato Networks CEO Shlomo Kramer in a recent interview with FierceTelecom. "It's a service chaining, integration-based architecture, which I think is the wrong approach. This (NFV) architecture comes from the ones that invented it, which were the telcos.The telcos are integration-based organizations."

Kramer, whose company competes against telcos' SD-WAN offerings, also said that the gross margins and ROI for using NFV weren't good because telcos have to pay VNF and orchestration vendors, and that the customers face fragmentation from managing five or six different NFV solutions.

While there are service providers in both the cloudification and NFV camps, Nolle isn't convinced of NFV's viability, or of ETSI's mission.

"Movement isn't progress, in my view," he said. "For NFV to progress, it has to address the real issues that operators face. The (ETSI) ISG work is not doing that, and it's inexcusable that they've spent five years doing things that the cloud had already done, and done better."