A couple of times now, I've heard the suggestion that NVGRE is so similar to VXLAN that the two software-defined networking (SDN) frameworks ought to just be glommed together.

The argument is pretty simple. They perform the same task in very similar ways and are even being crafted by some of the same IETF contributors. "For all intents and purposes, those are seemingly equivalent functions," says J.R. Rivers, CEO of Cumulus Networks.

VXLAN (alternatively spelled VxLAN) stands for Virtual eXtensible Local Area Network, and it was submitted to the IETF in 2011 by VMware, Cisco, Arista, Broadcom, and others. People tend to call it a "protocol," but it's more a method of using a Layer 3 tunnel to move a virtual machine from one place to another.

The Layer 3 option is useful because Layer 2 doesn't always suit large networks. It gives operators a way to bypass the limit of 4,096 Layer 2 VLANs available to them, for instance.

Two weeks after VXLAN arrived, Microsoft, Dell, and others (including Arista and Broadcom again) published their IETF draft for network virtualization using Generic Routing Encapsulation (NVGRE, or NV-GRE) to do the same thing. (Here's the latest version.) Yes, they have minor differences: VXLAN is UDP-based, while NVGRE is GRE-based, and NVGRE introduced the idea of a tenant network ID. But they're awfully similar beyond that, and NVGRE got knocked for it.

"It’s obvious the NVGRE draft was a rushed affair," wrote Ivan Pepelnjak on the IPspace blog at the time.

Here's a more recent take from Lame Journal, published in response to Arista's "spline" announcement, in June:

"I’m no expert here, but when I looked at the IETF docs, I’m pretty sure I saw the same name from Arista (K. Duda) as an author on both the NVGRE and VXLAN drafts. I haven’t kept up with the movements, but it seems to me that – entirely reasonably – Arista are betting on both teams," blogger John Herbert writes.

OK, it's more a criticism of Arista, but the point is: The connection between NVGRE and VXLAN is neither small nor subtle.

Assuming the two frameworks get merged, why should VXLAN be the surviving name? VXLAN has grabbed the mindshare; it's the one that always gets mentioned first (if NVGRE gets mentioned at all); and it's gotten huge visibility due to its role in the VMware NSX launch. By comparison, NVGRE is languishing on the bench. "Let me put it this way: Nobody's really asking about it, and we talk with Microsoft a lot," Rivers says.

It's actually not hard to see Microsoft and other NVGRE supporters eventually agreeing to do this, because network encapsulation by itself isn't a moneymaker. It's not as if we're asking Microsoft to adopt Mac OS. "In this particular market, you don't get extra points for it being your technology," Rivers says.

Of course, living with both frameworks would be fine. They're likely to interoperate forever; Microsoft notes that it supports multiple network virtualization protocols in the Windows Server Hyper-V virtual switch. And chipmakers seem happy to support both. But it seems a little pointless.

We did ping Microsoft about the issue, and the company said it's still confident NVGRE is the better option. Here's the emailed response, from Anant Sundaram, senior product marketing manager for Windows Server:

As you’re likely well-aware, these are two different formats that help encapsulate network traffic. In that context, we feel pretty convicted in our support of NVGRE as it enables better network scale in cloud-based environments, but do not have anything further to provide regarding ongoing efforts or a point of view about the formats merging.

Our goal is to stay focused on solving for customer needs and pain-points. As Windows Server Hyper-V continues to gain more customers, we are committed to enabling interoperability at the hypervisor/virtual networking layer (and all layers of the software-defined networking stack to enable hybrid cloud environments) for our customers. As an example, we’ve enabled multiple network virtualization protocols to co-exist in the same Windows Server Hyper-V virtual switch in our R2 release — check this out for more details. We will do this using multiple approaches including: in-the-box capabilities, networking ecosystem partnerships and our ongoing participation at industry forums like the Open Networking Foundation (ONF), IETF, DMTF, and OpenDaylight.

For a lot more on Microsoft's point of view, you can read this blog entry.