On 8/24/12 11:11 PM, Linda Dunbar wrote: [...]
But most, if not all, data centers today don't have the Hypervisors which can encapsulate the NVo3 defined header. The deployment to all
> 100% NVo3 header based servers won't happen overnight. One thing for > sure that you will see data centers with mixed types of servers for > very long time.
If NVEs are in the ToR, you will see mixed scenario of blade servers, servers with simple virtual switches, or even IEEE802.1Qbg's VEPA. So it is necessary for NVo3 to deal with the "L2 Site" defined in this draft.
There are two hypothetical ways of implementing NVO3: existing layer-2 technologies (with well-known scaling properties that prompted the creation of NVO3 working group) or something-over-IP encapsulation.
I might be myopic, but from what I see most data centers today (at least based on market shares of individual vendors) don't have ToR switches that would be able to encapsulate MAC frames or IP datagrams in UDP, GRE or MPLS envelopes. I am not familiar enough with the commonly used merchant silicon hardware to understand whether that's a software or hardware limitation. In any case, I wouldn't expect switch vendors to roll out NVO3-like something-over-IP solutions any time soon.
On the hypervisor front, VXLAN is shipping for months, NVGRE is included in the next version of Hyper-V and MAC-over-GRE is available (with Open vSwitch) for both KVM and Xen. Open vSwitch is also part of standard Linux kernel distribution and thus available to any other Linux-based hypervisor product.
So: all major hypervisors have MAC-over-IP solutions, each one using a proprietary encapsulation because there's no standard way of doing it, and yet we're spending time discussing and documenting the history of evolution of virtual networking. Maybe we should be a bit more forward-looking, acknowledge the world has changed, and come up with a relevant hypervisor-based solution.
Furthermore, performing something-in-IP encapsulation in the hypervisors greatly simplifies the data center network, removes the need for bridging (each ToR switch can be a L3 switch) and all associated bridging kludges (including large-scale bridging solutions). Maybe we should remember that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away" along with a few lessons from RFC 3439.
I am positive a decade from now we'll see ancient servers still using VLAN-only hypervisor switches (or untagged interfaces), so there might definitely be an need for an NVO3-to-VLAN gateway, but we shouldn't continuously focus our efforts on something that's probably going to be a rare corner case a few years from now.
... or I may be completely wrong. Wouldn't be the first time. Ivan _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
