As I’ve said before, the only virtualization analogy that applies to Network Virtualization is a VM running on VM Player. Yeah it’s virtualized, yeah it’s running, but it has no visibility or control of it’s effect on the underlying system or the underlying systems effect on it.

Joe

Thanks for the insight; but may I please gently press the original question, as the answer intrigues me greatly?

What is the crucial role that hop by hop intelligence plays in the DC networks?

Cheers,

– Dmitri

Visibility into queues, link utilization, and local resources … Sure, why not. That doesn’t preclude decoupling. At the end of the day it’s just data collected, stored, and synthesized by software. If that’s the coveted “hop-by-hop intelligence” we’re worried about, Network Virtualization doesn’t break that.

Cheers,
Brad

The important commonality of Server Virtualization to Network Virtualization is *decoupling*, that’s what matters. Decoupling provides automation and mobility on commonly available hardware with architecture independence. Are there some differences in implementation details? Of course.

A server is piece of hardware, and a network is a *service*, so of course Server Virtualization and Network Virtualization are different in that sense. Server Virtualization must emulate hardware, because the workload expects to see an x86 machine. The network, on the other hand, is *not* hardware, it’s a service, which for the last 30 years has been delivered by hardware (prior to decoupling). Network Virtualization doesn’t need to emulate hardware — the workload consuming the network service doesn’t care one bit about the hardware or form factor of the devices forwarding its traffic.

The similarity lies in the fact that compute and network are decoupled into a software layer at the edge host (the hypervisors and its vswitch). The fact is, the first network device the workload is attached to is a vswitch on its own hypervisor, so it makes perfect sense emulate the desired network services right there at the same edge software layer and achieve the coveted *decoupling*.

Network Virtualization makes sense because of Server Virtualization, a virtual network for virtual servers. We’ve been eating Peanut Butter (server virtualization) sandwiches for the last decade — tastes pretty good, but something was missing. Now it’s time to add the Jelly (network virtualization).

Cheers,
Brad

Thomas

http://www.sdncentral.com/market/sdn-churchill-club-long-live-sdn/2013/01/

View on L2 versus L3 hooks into network? Najam’s view is that L2 is dead and that he only cares about L3 networks. Martin concurred. In reality, what Najam really wants is the switches to just report visibility into queues, local resource utilization etc up to a central control plane and for that control plane to make all the intelligent decisions. Today, all he gets is SNMP. And as he eloquently put it “SNMP is dead, long live SNMP”.

I had stressed that point before, I think that conditioning people to think that server virtualization is analogous with network virtualization is just wrong. Server virtualization platforms leverage hypervisors, which in turn schedule real hardware resources for consumption by the virtual machines. In contrast, network virtualization, as being presented today, creates a totally abstracted container with it’s own control, data and management plane. The motivation behind creating those containers (overlays) is obvious, however, in my view, leveraging such approach only slows down the bleeding, providing no more than temporary relief. Negative customers’ experiences I hear about many times when testing such solution only re-enforce my thinking that the provisioning simplicity offered by this model is not enough to justify day-2 operational challenges. Having said that, not every deployment is bound to fail. To your earlier point, DC bandwidth is becoming cheaper and Clos architecture provides plenty of it, however it’s not just about bandwidth.

Today’s network virtualization technology tries to pull us back to the very basic primitives of network communications. If I can send a successful probe/ping between the tunnel endpoints, I am golden… not my problem anymore. If I can snoop packets at the host and trace TCP SYN and ACK counters, my troubleshooting is done. Lets learn from the past experiences and not turn a new page each time around…

I would also encourage server/virtualization admins, who would most likely be designated as primary consumers of network virtualization technology, get more intimately acquainted with the principles of networking. Don’t just take my word for it, as an example, in IP Telephony world long time ago there was a saying “if you can ping it, you can ring it”. We had evolved beyond that by leveraging services provided by the underlying infrastructure to deliver solid Unified Communication experience.

Thank you,
David