What are the risks of network functions virtualization (NFV)? As with any emerging technology, moving fast or picking the wrong components can do more harm than good. Let’s spend some time breaking down the NFV risks in building a virtual network.

I have spent the few months gathering feedback from various service providers to get their view on whether NFV and its cousin software-defined networking (SDN) are ready for prime time. Even though many service providers expressed optimism that NFV technology is moving toward maturity, there are definitely cautionary tales on what to look out for.

This article serves as an introduction to the challenges of NFV component selection – later articles will refer in more detail to the challenges in selecting NFV hardware and software components such as OpenStack and Open vSwitch.

In the big picture, NFV introduces new risks because it adds additional layers of complexity, which need to be tracked and managed. The next big level of risk is performance – because virtual systems often add a software overhead and may not be engineered to carrier specs, enhancements and testing may be needed to bring the NFV operational stack up to snuff for carrier environments.

In a traditional network, proprietary hardware such as routers and switches are often designed as dedicated appliances with built-in failure protection, both in hardware and software. In an NFV environment, more generic components are used, including the addition of open-source components such as OpenStack and open vSwitch (OVS), adding to the complexity.

This added layer of virtual software solutions means that carriers will have to develop sophisticated Management and Orchestration (MANO) layer that can detect and manage failures or bottlenecks in both hardware and software. This will lead to features such as auto-scaling and self-healing -- for example setting up new virtual machines to replace failed units or to adapt to scaling demand.

“Commodity hardware by definition is not carrier grade, so you have to rely on your software to be smarter than the underlying hardware and compensate for any gaps to reach a true carrier-grade solution in the SDN/NFV world,” wrote Michael Kozlowski, Vice President of Product Management at Windstream, when I asked him to describe what’s need to build a carrier-class NFV platform.

The reality is that off-the-shelf cloud platforms are not ready to be plugged into carrier networks. Operators will need a checklist of the virtual components they are going to install and what they need to test.

Kozlowski describes how these components must be tied together to present a complete, automated system:

“Availability means that both redundancy and diversity are built into the solution, and that any faults are managed instantly and automatically. And security should include considerations such as encryption and isolation. Finally, the underlying network must be fault-tolerant and low-latency to ensure there are not disruptions.”

If you were to start with a high level list of the common requirements for NFV in the telco cloud, they would be:

• Performance
• Scalability
• Compatibility between components such as hypervisors and cloud management platforms
• Interoperability with legacy hardware and networking infrastructure.
• Required expertise in the organization
• Security
• Integration with existing OSS and BSS systems

What carriers are trying to do is build a full NFV ‘operational stack” that can extend through their entire organization. These elements will be need to delivery performance, programmability, security, reliability, and agility. It will require a wide range of technology, which could include off-the-shelf hardware, high performance Network Interface Cards (NICs), carrier-class cloud-management platforms, Linux container software, APIs, and orchestration and management software.

In the next few articles, we’ll focus on specific areas of interest for carriers, including the NFV infrastructure (NFVI), OSS/BSS, and cloud management platforms such as OpenStack.

It’s clear that scaling the cloud to meet the needs of operators to yield NFV is a long process. I’ve pointed out in previous articles that it’s likely to take a decade, and likely to happen in steps rather than as a rip-and-replace of the infrastructure.