I’ve been talking with service providers about the state of their NFV deployments. While Open Network Automation Platform (ONAP) and Management and Network Orchestration (MANO) are almost always part of the conversation, I am curious about the overall state of NFV. And, in particular, why NFV hasn't progressed as much as it should have given its original premise of unlocking value, saving money, and improving agility.

I'm not alone in asking the question. At the recent Open Networking Summit in Amsterdam, Axel Clauberg, vice president of aggregation, transport, IP, and infrastructure cloud architecture at Deutsche Telekom, said that NFV was taking longer than he expected, while also warning that jumping to cloud-native wasn’t going to be a panacea.

Certainly, networking vendors didn't jump on the bandwagon to commoditize themselves aggressively. And new entrants hoping to ride the NFV wave discovered that replacing existing physical network functions (PNFs) wasn't as easy as expected, and integrating into a telco environment with its OSS/BSS and other entrenched systems was hard. Also, cultural barriers and lack of the right skills at telcos continue to be issues.

Nevertheless, if early NFV deployments had demonstrated significant and immediate savings (capex + opex), or had unlocked more revenue, I submit that things would have gone much faster. Take SD-WAN, for instance, and the rapid adoption of SD-WAN by service providers. Those service providers view SD-WAN as a value-add service because there's strong enterprise demand and a clear path to make money. Unfortunately, not all SD-WAN deployments qualify as full NFV deployments. In particular, we're seeing virtual network function (VNF) islands where, essentially, there is a single function NFV deployment limited to a single domain (e.g. SD-WAN, virtual EPC, or virtual IMS). This single silo is usually vertically integrated and purchased from a single vendor (or a single vendor plus a few partners) that has pre-qualified the full stack. Which is not quite a general uniform network functions virtual infrastructure (NFVI) managed by a generic VNF Manager (VNFM) and NFV-O on boarding multi-vendor VNFs.

The unified white box underlying infrastructure has not been realized. Just recently, Orange's Jehanne Avi talked about fake virtualization at the SDN World Congress 2018 conference in The Hague where she described vendor lock-in as occurring concurrently with mainstream virtualization solutions instead of with a real open ecosystem. She also advocated that operators push back against easy-to-go solutions in the core businesses. In other words, eschew the fully-integrated SD-WAN solution that can bring in immediate revenue with the least hassle, and push for a true open NFV platform approach with disaggregation.

On the NFVI (and virtualized infrastructure manager) front, the current state is a two-horse race between OpenStack and VMware with a new dark horse emerging in the form of Kubernetes with containers. However, OpenStack has presented its own challenges in the form of bloat and pure documentation, as well as historically being difficult to deploy and upgrade. And OpenStack isn't always the best option for the hot use case of virtual CPE/SD-WAN deployments. I've heard anecdotally from operators that OpenStack can take up 2 of 8 cores, leaving 6 for actual VNF work. If true, that's a 25 percent overhead tax.

And we're still working through performance issues through the NFVI, grappling with managing options for PCI pass-through, DPDK, SR-IOV, smart NICs, TOR offload, and figuring out how to accelerate TLS and other encryption options. We've made progress but it is much slower than we were all hoping.

On the MANO front, many have given up on the generic VNFM unicorn and instead are focused on orchestration and automation. Sorting through VNFMs, NFV-Os, and element management systems (EMSs) has been difficult for operators. At the ONS Summit, Orange Group Networks CTO Emmauel Lugagne Delpon issued a call to action to standardize on an Infrastructure-as-a-Service (IaaS) model for NFVI and drive toward a uniform MANO, pointing to ONAP as the leading candidate to standardize. However, ONAP itself is still a work in progress as evidenced by presentations and conversations at SDN NFV World Congress. And rationalization between ONSP, OSM, and other options is unlikely to happen soon.

The amount of money and effort to implement platform-wide NFV MANO given the current state is non-trivial, and we'll likely see only domain-specific implementations tied to specific VNFs or VNF groups performing a limited set of functions.

VNF transformation is taking a while. Vendors started with simple NFV-washing in the early days by simply wrapping existing PNFs in virtual machine (VM) clothing. These early 'VNFs' didn't quite perform and required a huge memory and CPU footprint to operate, leaving a poor taste for those early on the NFV bandwagon.

The situation has improved, with better architected VNFs that behave better today and that understand how to deliver cost-effective performance (usually with DPDK or in association with other hardware acceleration techniques). But we're learning that NFV journey will take much longer than we expected. And DT’s Clauberg is right, we are just barely through our VM journey. VNFs in containers will take more time and learning.

Despite all these challenges, I don't believe we can turn back. The competitive nature of the telco business demands that organizations transform themselves into agile entities equipped to roll out new services faster than before and to adapt those services as customers provide feedback. Plus there's lots of ego and pride at stake given the public commitments by telco leaders to open ecosystems, disaggregated systems, agile development, cloudification, and the ubiquitous yet amorphous “digital transformation.”