Why Isn’t NFV Widely Deployed?
My last post provided a short overview of Network Function Virtualization (NFV); if you’re new to this terminology, it would probably be best to review that post before reading this one. It discusses the idea of moving network functionality, such as the various components of a firewall service, off of custom built appliances and onto commonly used server hardware. Various powerful benefits of NFV are also discussed. However, I’ve been asked by ECI to explain: “if everything is so hunky dory, why isn’t NFV being more widely deployed?
First, it’s important to determine what “widely deployed” really means. NFV is being used by some very large network operators to virtualize specific functions. For instance, in the AT&T CORD architecture (which is currently being deployed), virtual routers and firewalls are used to terminate connections and provide security functions. Another common application is load balancers running in a VM. Users who are moving to cloud based services, either to augment or replace their existing data centers, are using virtual routers, firewalls, and load balancers, as well.
These spaces, however, seem to contain the whole of the NFV deployment space right now. The promise of NFV seems to be much larger than just a few functions in somewhat narrow applications. If NFV is such a great idea, what’s slowing down (or limiting) deployment?
Limited Use Cases: Let’s begin answering this question by asking another one: beyond the firewall, load balancer, and virtual router in a cloud service examples, what other functions provided by a network can actually be virtualized? There is really only one other “service” that’s normally considered a part of the network in any real way—content caching (which I’ll leave to one side for a moment). The first hurdle NFV deployment is facing, then, is there isn’t a whole lot to virtualize beyond these four services.
Traffic Optimization: A second hurdle revolves around optimization. One of the ironclad rules of services in a network is that packets actually need to pass through the service. This might seem obvious, but it’s often forgotten in the rush to virtualize. The figure below illustrates the problem.
In this network, traffic must pass from Host A, through Firewall C (a virtualized service running on Server F), then through Load Balancer D (running as a virtual service on Server G), then to an actual application running on, say, Server H. This means any packets being forwarded from Host A to the service on Server H must pass through Router E three times, rather than once. While these hops through the network are actually handed as east-west traffic across a data center fabric, the network here is very simplified just to illustrate the concept.
Where an appliance is literally wired into the path of the packet flows, virtualized services often require traffic to be brought to the service. This represents a virtualization tax, if you will, on the network. Bandwidth and packet switching need to be accounted for when services are virtualized, as well as some mechanism deployed to actually pull the traffic along a path that passes through these virtual services—a topic for a future post, perhaps.
Organizational Culture/Mindset: A third hurdle is cultural. Let’s face it, for many network engineers, particularly in the security realm, appliances are a warm blanket we’ve been holding for many years—a blanket that’s really hard to let go of. We’ve become so accustomed to providing security and load balancing as part of the network that we actually build virtual load balancers and firewalls in cloud environments. If you’re building an application from scratch to run in a cloud, why aren’t these functions just part of the mix, rather than being handled by the network?
Territories: Finally, once a service is virtualized, it makes engineers start asking another question: why not just conceptually move the service out of the network and into the host running the application? One prime example of this is per application or per host stateful packet filtering. Moving these traditional functions from the network into the servers actually hosting applications can make a lot more sense than running a firewall in a VM and directing traffic to it. A couple of examples might be useful to clarify.
On the security front, we’ve been building castle walls for many years around our networks. The reality is, however, that social engineering and more sophisticated attack vectors act as cannons and airplanes. Castle walls don’t make a lot of sense in an age of cannons and airplanes, honestly. Many operators, particularly in hyperscale environments, either already encrypt internal as well as external traffic in their networks to provide a higher degree of protection than the traditional “hard trust edge” can offer. LinkedIn, for instance, has already enabled TLS encryption along its public facing edge, and we’re working towards encrypting the internal traffic on the data center fabric. Firewalls as an appliance (or as a standalone service) lose much of their functional capabilities when all the traffic on the network is encrypted, so it just makes more sense to move the functionality traditionally associated with these appliances into the applications and server. Another example of this is virtual firewalls that run directly in a hypervisor on a particular server (or set of servers). The functionality isn’t moved into the application, but it is still moved out of the network proper, and into what might be considered the already virtualized edge of the network.
Again, LinkedIn doesn’t really use load balancers. Rather, load balancing is built into the applications that need it, and network side load balancing is managed using IP anycast alongside network control plane analytics and traffic engineering.
The deployment, then, of NFV is a mixed bag. There is widescale deployment in a narrow range of environments, and there is virtualization that’s moving functionality out of the network into hosts or the already virtualized edge. While NFV might be coming to a network near you, then, it might not look like the diagrams you’ve seen in that glossy vendor promo, or networking magazine. Rather, it’s going to look like a quieter rethinking of where functionality really needs to live, and what can really be virtualized.