VMware, Microsoft, Red Hat and Intel have proposed a new encapsulation protocol that would standardize how traffic is tunneled over the physical infrastructure by network overlay software.
The vendors have submitted a draft for Generic Network Virtualization Encapsulation (GENEVE) to the IETF. In theory, GENEVE would replace three similar -- but competing -- protocols: Microsoft's NVGRE and VMware's VXLAN and Stateless Transport Tunneling (STT). Moreover, the current draft for GENEVE includes extensions that would allow network overlays to insert metadata into encapsulated frames for the purpose of enabling other services -- such as specialized forwarding or stitching firewalls and load balancers -- into a virtual network.
"There is recognition that the war over NVGRE and VXLAN is a little bit unnecessary," said Jesse Gross, senior staff engineer at VMware and co-author of GENEVE. "It makes sense to come together. We all more or less want the same thing: to avoid a repeat of an architectural split."
GENEVE will bring more interoperability to the network overlay market. It will also appeal to data center operators who have a heterogeneous hypervisor environment.
"The issue here is fragmentation," said Eric Hanselman, chief analyst for 451 Research. "In order to be effective and to keep management of all these various overlays from being a serious problem, and to mitigate a lot of the overlay integration problems that are going to crop up, it would be useful for there to be a de facto encapsulation standard."
GENEVE extensibility could make network overlays more powerful
The first generation of network overlay encapsulation protocols, NVGRE and VXLAN in particular, were designed primarily to provide virtual network segmentation that, in turn, enabled multitenant networks. GENEVE, a superset of these earlier protocols, is extensible, allowing overlays to insert metadata that enables more than network segmentation, Gross said.
"One of the issues that all [network overlay] approaches have dealt with so far is the lack of simple extensibility," Hanselman said. "They don't have the ability to bring along information as part of that overlay, [which] would allow for better management and network operations to reflect more of the network state." Overlays can use this metadata to share additional information about network state, "like application identification, application requirements, more information about who generated the traffic, and what kinds of characteristics it needs," he said.
"If you imagine a firewall, one of the things you might want to provide is additional context such as identity," Gross said. "[A hypervisor] has a rich amount of information. It knows any kind of central management information. It also has the ability to do introspection into the guest, to the logged-in user, the operating system, the patch level. If you're building a firewall, it's very helpful to get that type of information. But that requires the ability to support additional metadata in a tunneling protocol, which NVGRE and VXLAN don't have enough space or flexibility to provide."
Enterprise IT should welcome encapsulation protocol cooperation
The two leading and competitive protocols -- VXLAN and NVGRE -- to some extent emerged on the market due to hypervisor and network virtualization competition between Microsoft and VMware. Now those companies are cooperating on GENEVE.
"I think it's somewhat a case of a 'the enemy of my enemy is my friend' here," said Teren Bryson, IT director for a multinational industrial equipment manufacturer. "Microsoft and VMware have a strong interest in getting tunnel overlay technology to take hold as the preferred method of 'doing' SDN.
Bryson said GENEVE could also make the NVGRE and VXLAN support Broadcom has built into Trident II silicon obsolete. "Intel has an interest in hurting Broadcom, whose chips will get marginalized in the short term if this takes hold in any meaningful way."
Unanswered questions about GENEVE encapsulation protocol
In order for GENEVE to take hold, hardware and silicon vendors will have to create supporting equipment and chips.
In-hardware, VXLAN and NVGRE encapsulation is just now hitting the market in large volumes, thanks to Broadcom's Trident II networking chip. Broadcom was co-author of the VXLAN specification and integrated VXLAN and NVGRE support directly into its silicon. Switch manufacturers have relied on those chips to provide in-hardware encapsulation, which is essential to overlay scalability and performance.
GENEVE may require new silicon, and it's unclear who will provide it. Intel's involvement in GENEVE suggests it will build chips to support the protocol, but what about the rest of the industry?
More on network overlay software
Overlay vendor Midokura teams up with bare-metal vendor Cumulus
Juniper open sources Contrail overlay software
Nuage builds its own hardware gateway for its overlay software
Price of VMware NSX overlay remains a secret
"The biggest problem I see, yet again, with [GENEVE] and NVGRE/VXLAN, is [they] require new silicon in most [top-of-rack] switches," said Josh Barron, a senior engineer at a systems integrator in the Pacific Northwest. "We have only just recently seen wide adoption of the Trident II chipset, and even that doesn't have full VXLAN capabilities in the 1U reference architectures. All in all, GENEVE sounds great, if the industry can truly embrace it and make gear for it. It doesn't really matter if Red Hat, Microsoft and VMware are supporting it if the [top-of-rack switch] manufacturers don't."
The approach to metadata is also being hotly debated inside the IETF right now, Hanselman said. "The question is -- what is the nature of the meta tags that need to exist? And within that encapsulation, where should they live? Should it be included in the header or the body of the data that's being carried?"
GENEVE's proponents will have to settle these questions quickly, Lerner said.
"The longer GENEVE takes, the more entrenched the VXLANs and NVGREs of the world will become. In the absence of GENEVE today, organizations are deploying the other protocols, so speed of ratification is important, because it will likely be tedious for organizations to switch overlay protocols down the road."