I usually use the “Nicira is Skype of virtual networking” analogy when describing the differences between Nicira’s NVP and traditional VLAN-based implementations. Cade Metz liked it so much he used it in his What Is a Virtual Network? It’s Not What You Think It Is article, so I guess a blog post is long overdue.

Before going into more details, you might want to browse through my Cloud Networking Scalability presentation (or watch its recording) – the crucial slide is this one:

In the beginning, there was a patch cord

Typical virtualized data centers we’re seeing today are no better than manual service exchanges using cord pairs to connect the users – the hypervisor virtual switches using VLANs to create virtual networks are too simplistic to tell the network what they need, so the networking team has to provision the required VLANs manually.

Good morning, which VLAN would you like to talk with today? (source: Wikipedia)

The VM-aware networking is an interesting twist in the story – the exchange operator is listening to the user traffic and trying to figure out who they want to talk with.

Automatic Service Exchanges for Virtual Networks

Following the great example of telephone exchange vendors that heaped tons of complexity into their gear (ensuring hefty margins and pricey support contracts), the networking vendors are trying to persuade you that you should keep the edge (hypervisors) as simple as possible and let the network (= their gear) deal with the complexities of scaling VLANs and L2 switching.

Does it make sense? Let’s see – to get a somewhat scalable VLAN-based solution, you’d need at least the following components:

• A signaling protocol between the hypervisors and ToR switches that would tell the ToR switches which VLANs the hypervisors need. Examples: EVB (802.1Qbg) or VM-FEX.
• Large-scale multipath bridging technology. Examples: SPB (802.1aq) or TRILL.
• VLAN pruning protocol. Examples: MVRP (802.1ak) or VTP pruning. SPB might also offer something similar with service instances.
• VLAN addressing extension, and automatic mapping of hypervisor VLANs into a wider VLAN address space used in the network core. Q-in-Q (802.1ad) or MAC-in-MAC (802.1ah) could be used as the wider address space, and I have yet to see ToR gear performing automatic VLAN provisioning.

It might be just me, but looking at this list, RFC 1925 comes to mind (“with sufficient thrust, pigs fly just fine”).

What could be better than a flying pig? A brass flying pig!
(unfortunately, the folks @ whimsie.com no longer make them)

To understand the implications of ever-increased complexity vendors are throwing at us, go through the phenomenal presentation Randy Bush had @ NANOG26, in which he compared the complexities of voice switches with those of IP routers. The last slide of the presentation is especially relevant to the virtual networking environment:

• With enough complexity we strongly suspect we can operate [whatever environment] in polynomial time and dollars.
• We are working on a proof that [whatever environment] can be made to be NP hard [the list of emerging technologies you need to scale bridging is a great move in the right direction].
• And then you’ll just wonder where your margins went [sounds familiar, right?]

Enter the Skype era

Going back to the voice world: eventually someone figured out it’s way simpler to move the voice processing complexity to the end-devices (VoIP phones) and use a simple and cheap transport (the Internet) between them.

You don’t think VoIP scales better than traditional voice? Just compare the costs of doing a Skype VoIP transatlantic call with the costs of a traditional voice call from two decades ago (the international voice calls became way cheaper in the meantime, partly because most carriers started using VoIP for long-distance trunks). Enough said.

We can watch the same architectural shift happening in the virtual networking world: VXLAN, NVGRE and STT are solutions that move the virtual networking complexity to the hypervisor, and rely on proven, simple, cheap and reliable IP transport in the network. No wonder the networking companies like you more if you use VLAN-based L2 hypervisor switches (like the Alcatels, Lucents and Nortels of the world preferred you buy stupid phones and costly phone exchanges).

Does that mean that EVB, TRILL, and other similar technologies have no future? Absolutely not. Networking industry made tons of money deploying RSRB, DLSw and CIPs in SNA environments years after it was evident TCP/IP-based solutions (mostly based on Unix-based minicomputers) offer more flexible services for way lower price. Why should it be any different this time?

We made so much money supporting this gear. Let’s try to do it again!

More details

Start with the Cloud Computing Networking presentation I delivered at EuroNOG (recording) to get the basics. The Cloud Networking Scalability presentation from RIPE64 (recording) focuses on the scalability aspects. For more details, watch the recording of the Cloud Computing Networking webinar.