The Promise of NFV
Network Function Virtualization (NFV) is the implementation of network functions, such as routing, into a cloud environment. The resulting Virtual Network Function (VNF) is designed to operate such that as demand increases it creates duplicate copies of the VNF to share the traffic load. As demand decreases the extra instances of the VNFs are taken away. It is this dynamic nature, the capability for a network to grow and shrink automatically based on demand, that makes the promise of NFV so alluring.
Additionally, NFV promises significant cost savings, especially as providers move toward managing virtual instances of the network functions instead of physical devices. Software versions of devices are cheaper than physical devices, and on top of that, operational savings from automation are assumed in the European Telecommunications Standards Institute (ETSI) NFV standard, that has been adopted worldwide.
Automation and NFV Goes Hand in Hand
The core tenets of NFV automation are found in the Management and Orchestration (MANO) layer. This layer includes an NFV Orchestrator that manages the overall environment by working with a VNF Manager (responsible for creating, modifying, and destroying VNF instances) and the Virtual Infrastructure Manager (VIM) which manages the compute, storage, and networking parts of the environment. These three components provide the automation within the NFV portion of the network.
Network automation issues arise when end to end services involve more than just the NFV components, which is common. Most services also have physical network elements included as well, such as the fiber or copper connection from the provider network to the customer’s house or place of business. The result is an operational process that is part manual (or possibly automated by legacy systems) and MANO automated NFV-related pieces. Often times these separate automation processes do not interoperate with one another.
Why is NFV a Promise Yet Unfulfilled?
Lack of Interoperability
There are a number of reasons why NFV has stalled, a primary one being the lack of interoperability. There are many MANO-related options. Oftentimes these different solutions are specific to certain products or services. For example, there may be one set of management tools for a Virtual Firewall offering, another for SD-WAN offering, and yet another for a Virtual CPE offering. These are all NFV based solutions that are from disparate vendors and do not work well together without complicated integrations. Add to this the fact that existing physical networks are managed by yet another set of systems that are not natively integrated, and the result is multiple orchestrators, multiple controllers, and multiple legacy OSS systems managing the physical devices involved.
Technology Issues
A second reason for stalled adoption is due to a plethora of VNF technology issues. Initial VNFs were virtual machine based. Vendors began by porting the same code that ran on their proprietary hardware to virtual machines. The result was a set of VNFs that had no hope of competing with the physical devices due to extreme performance differences. The software used on the virtual machines was optimized for the proprietary hardware and operated at suboptimal levels running on the virtual machines. As time passed many vendors began using container technology and rewriting their VNF software from the ground up. Instead of porting existing code not made to run on a virtual machine, today VNFs are being developed as container-native. The result is a faster time to create new devices as well as remediate or destroy and recreate those devices due to issues encountered.
VIMs (Virtual Infrastructure Managers) built to manage virtual machines typically do not also manage containers and vice versa. As a result, a customer with a mix of virtual machine-based and container-based VNFs faces multiple automation systems in this area as well. Additionally, vendors typically ship their own VNF Manager with their VNFs. In a multi-vendor network environment, this only adds to the number of systems that need to be automated.
Licensing Issues
Vendors have failed to meet the promise of lower costs for the purchase of VNF licenses versus purchase of physical devices. In some cases, the vendor charges the same price as they do for a physical device, even though their cost is lower. Often vendors do not have volume based pricing or other breaks for providers that will be buying in bulk. This issue has caused many providers to reconsider going with NFV-based solutions and incurring the challenges of learning new tools.
Operational Skills Gap
Developers are not network engineers, and network engineers are not developers. The concepts introduced with NFV and SDN are not just managing the network-like software, but the network actually becoming software. The skillsets involved in this new discipline don’t translate easily from the network engineering operational groups. Everything in NFV is based on models (both services and devices) and this is foreign to network engineers. Similarly, while developers in a network operator’s IT department will understand modeling and the syntax and capabilities of the modeling language used, they have no experience with the actual devices and services being modeled.
How to Jumpstart NFV Adoption
True Interoperability
The most daunting barrier to NFV adoption is the confusion generated by so many options for managing components. The various solutions that exist today are not going to organically become interoperable. However, due to the fact that these solutions have all been created in the last several years, they are designed with full exposure of their capabilities via APIs in mind. This provides the basis for a solution to the problem.
An emerging approach to network automation is one that considers just this scenario. Any multi-vendor network will have multiple orchestrators, controllers, and other network management systems. By consuming the APIs of these systems and presenting a unified management layer that exposes their capabilities for use in intelligent network automation workflows, it is possible to abstract the complexity from the user. This new approach focuses on full end-to-end automation, federation of data from the multiple systems instead of creating more copies of data and being a completely vendor-agnostic solution that focuses on services from an intent-based perspective.
Key components of this approach include a solution that is model-based (understanding the common modeling languages such as YANG, TOSCA and YAML), API driven, focused on federation (from both external systems and consumed via APIs from those systems), and low-code.
Low-Code Operations
As we move towards a DevOps-like approach to managing the network and network elements become completely software-based, the skills gap between a network engineer and a developer comes into play. The worlds of IT and Network are colliding as we introduce NFV and SDN into the network. Many solutions require a high level of development skill to effectively use, but the people that typically have this skillset don’t have the networking knowledge to know exactly what to code. The way forward is to close this skills gap via a solution that not only federates capabilities, making multiple systems interoperable but to also provide a canvas for network engineers and developers alike that requires little to no coding in order to create and use an automation. This solution must abstract the need for development skill so that network engineers can be self-sufficient but provide for some custom development for more sophisticated automations. This approach would serve to lessen the oftentimes painful, yet inevitable process of merging IT and Network Engineering.
Licensing Alignment
VNF licensing and management has to align with traditional software-based licensing models and not continue to be based on the legacy hardware model most vendors continue to follow. A consolidation of the licensing model will allow for the use of the same, or similar tools that enterprise IT
departments use today. Additionally, consolidation of management tools will lessen the number of disparate systems that interface with automation solutions.
The promises of NFV are compelling — high-performance networks with greater scalability, elasticity, and adaptability at reduced costs compared to networks built from traditional networking equipment. By addressing the issues that NFV faces and making the technology more accessible to more operators, IT pros will be more likely able to adopt the technology and automate their modern network.
Blog originally posted on The New Stack.
Tags: Network Transformation