We’ve heard a couple of times that it’s pointless for VXLAN and NVGRE to stay at odds. Both are encapsulation frameworks for virtualized networks; they do pretty much the same thing but happen to have different corporate backers. We’ve even written that NVGRE maybe ought to concede.
Peace might now be at hand. A superset of both protocols, called Generic Network Virtualization Encapsulation (Geneve), got submitted to the IETF in a draft published Feb. 14, just at the IETF’s 4:00 p.m. deadline.
You could call it the Valentine’s Day Draft. (Martin Casado, chief scientist of VMware, did.)
“This’ll be a big deal once people figure out what’s happening,” Casado says. “It had to happen. You don’t want to have a bifurcation in the market.”
Casado and others found it grating that VXLAN, NVGRE, STT, and possibly other protocols are all lingering around. They all create Layer 3 tunnels between virtual machines (a key bit of infrastructure for a virtualized network), and they’re similar to the point that they’ve even got common authors. Starting at Interop in spring 2013, representatives of the companies behind those standards started working to find some common ground.
The Geneve draft was written by representatives of VMware, Microsoft, Red Hat, and Intel. (That’s the order in which they’re listed. Casado is not an author, but he’s one of the folks thanked in the draft for providing consultation.) VMware has been arguably the biggest VXLAN proponent, while Microsoft is usually held up as the biggest NVGRE backer, so there does seem to be a joining of paths here.
It’s a promising development, but there’s a catch: It appears that switch chips, such as the Trident series from Broadcom, will have to be updated to accommodate Geneve.
Unity on the Data Plane
Geneve is described not as a compromise or love letter, but as a superset of VXLAN, NVGRE, and STT. The core idea is that these data-plane protocols are “only superficially different” and might as well be unified to avoid duplicated effort.
Control planes, on the other hand, can and should be vastly different and will be continually changing, the draft states. To avoid obsolescence in the event of future control-plane innovations, the Geneve draft says it’s “providing a framework for tunneling rather than being prescriptive about the entire system.” Moreover, “it should be straightforward to port an existing control plane to run on top of [Geneve] with minimal effort,” according to the draft.
Casado says we should view VXLAN, NVGRE, and STT as the first go-around for tunneling protocols. They gave VLANs Layer 3 powers, but they did not account for more “rich” virtual-network functionality that developed later, such as service chaining. “This allows one framework that will evolve in the future,” he says.
Geneve has a mechanism for supporting extensions and multiple versions, giving the protocol room to grow. It also adds a way to recognize system state, conveyed through metadata.
What About Broadcom?
Geneve could run on an x86 chip today, and some current network interface cards (NICs) will be able to support it via software upgrades. But Ethernet switch chips will need modifications to support it.
The industry just got done waiting for Broadcom to directly support VXLAN and NVGRE, a feature that’s supported in the company’s new Trident II chips. Assuming Geneve gains favor, there could be a similar wait as the next generation of chip designs gets completed. (Because the story broke Friday evening, we haven’t yet polled chip vendors on whether they’ve already started this work.)
On the plus side, Geneve’s future-proofed design could mean this is the last tunneling protocol the chips need to accommodate for a while.
Hardware issues aside, Casado is head-over-heels for Geneve. “I think a lot of protocol development gets dictated by ASIC design,” where a feature already baked into someone’s proprietary hardware gets proposed as a standard, he said. (Cisco gets accused of this a lot.)
By contrast, Geneve was crafted from the software side by a group that stuck to a unified goal, to hear Casado tell it. “When you have two of the most successful software companies on the planet doing this, you know change is afoot.”
This is great news to the industry as “map & encap” are becoming the choice architecture for emerging virtualized networks. Such drafts decouple the encapsulated grid-fabric mechanics from global awareness methodology, as well as allow for distributed software defined control planes to evolve.
The approach in the draft allows different virtualization nodes to Interoperate and form whole systems. Nodes which are OpenFlow based or vSwitch based, network edge devices, or VM aggregators within hosts, Nodes connecting hosted networks, or those with multi-protocol balancing-chaining telco-nfv capabilities. Most importantly nodes from different vendors, different releases, and different locations.
The next steps in the evolution of this tunnel “subway system” is to allow for SDN Edges to traffic engineer the underlay networks without polluting them with hop by hop states. This can be done by specifying standard re-tunneling nodes (aka RTRs) and segment routing nodes (SRs). While this is a step-by-step process, the news of Geneve is a major move in the right direction.
Microsoft added another gift by submitting an IPR claim against the IETF NVO3 architecture draft. US-2013-0058346-A1 is the patent which basically patents distributed overlay routing where communication and control is in the hypervisor and not using a central controller.
They submitted the IPR as a licensed with royalties type, where in general most IETF IPRs state non enforcement for standards based IPR claims… If they want Geneva to go anywhere they will need network vendors onboard.
This is actually bad news for the industry as choosing to ignore the mistakes of the past are bound to be repeated. This is happening here. The world does not need yet another encapsulation format. And the world certainly doesn’t need (and has never used in practice) variable length options. There is no innovation here.