First let's establish the difference between the NFV and the VNF:
- VNF (Virtualized Network Function) refers to the implementation of a network function using software that is decoupled from the underlying hardware. It simply moves network functions out of dedicated hardware devices and into software. Cisco currently has around 90 VNFs ready to be implemented, mostly for the SP environment.
- NFV (Network Functions Virtualization) represents a concept, and it's based on running SDN functions, independent of any specific hardware platform.
This all simply means that we need the network functions virtualization (NFV) architecture to support the deterministic placement of virtualized network functions (VNFs).
Network Functions Virtualization is "the new black" in the Networking Security, and all of us Network Bloggers have been talking about it extensively within the past few years. What it basically means is that we are finding a way to virtualize one of the Functions of our Network/Network Security Elements, such as LB or FW. The concept is rather simple, and while the entire industry is wondering why we're not there yet, the Network Engineers (meaning - the ones with real understanding of how networking protocols work) are having a really hard time explaining why it can't all work as simply as the OpenStack enthusiasts expect it to.
Server Virtualization is not complicated. Once you have a Hypervisor - you can create numerous Virtual Machines on a single Bare Metal server. Networking is much more complicated. In order to implement the NFV, you need to have the Networking part underneath it completely handled and controlled, you need the ALL-to-ALL connectivity provisioned in your underlay, and just "apply" the desired connectivity in accordance with what your VNF needs. This might be simple if we're talking about a couple of switches where we would simply extend a big group of VLANs all over the place, but as soon as we get into a bit more complicated Networking Architecture (as in - any serious companys DC network) - we add Spanning Tree, Routing, VxLAN Control Plane (and all other control planes that use MCAST) etc. If we don't have an SDN solution capable to handle both Physical and Virtual Network elements - we shouldn't even start thinking about the NFV. It would be like trying to breathe in space, you know WHAT you want to do and which organs you need to activate, but there is simply no all-to-all elements connectivity, which would be an oxygen in this case. Therefore - SDN is the enabler for NFV, and the two concepts go hand in hand.
What Cisco did is they came up with an alternative that allows them to offer the NFV solution using al alternative (OpenSource) SDN solution instead of Cisco ACI. NFVi is a reference of the architecture which does not depend on the SDN Solution at all, and it´s primarily made for the Service Providers. NFVi would be the Infrastructure component of Ciscos NFV Platform. A key part of Cisco NFVi is Cisco Virtualized Infrastructure Manager (VIM).
If you ever played with OpenStack, you know that we are talking a platform that is pretty complex to deploy and operate. This is where VIM really shows it´s value. VIM takes care of the Installer and the Life Cycle management of the entire NFVi Storage, Network and Compute components, and it fully integrates:
- OpenStack Platform (Red Hat distribution)
- CEPH (for reliable storage)
- All this on Cisco UCS (Unified Computing System)
There are so many different SDN and NFV ecosystems out there that it gets overwhelming for the end users, which is kinda why I wrote this post. NFVI is an Open Network Architecture compatible with any SP End-to-End Service Creation. There are a few Cisco solutions to have in mind when thinking about the Service Provider:
- WAE: WAN Automation Engine that complements the Cisco NSO (Network Services Orchestrator, enabled by tail-f) and Cisco´s distribution of OpenDayLight.
- VTS (Virtual Topology System) is a true controller, designed to be Open, and it works with any other Vendors Networking equipment. VTS only requires BGP-EVPN in the underlay to be able to build VXLAN overlay.
- Mercury is an Internal Cisco´s OpenStack platform specific for SP, based on RedHat OpenStack, made to do a successful, reliable and stable installation via GUI every time.
I could write an entire post about Cisco VTS (Virtual Topology System). It´s basically an SDN Controller for Service Provider Datacenter, a Hybrid (Physical and Virtual Overlay) Provisioning & Management System. In the context of NFVi the diagram bellow will tell you what you need to know.
Where exactly does NFVi fit in then? It´s quite simple actually. NFV Infrastructure is simply a tested and validated design that is, as Cisco claims, easily extensible and expandable. You could build a similar architecture yourself, or get a System Integrator to do it for you, but if you opt for NFVi - you get a Cisco label on a support contract. The following diagram shows the most common use cases of NFVi Platform.
