In the past, there was never another company big enough (in networking) to challenge Cisco with a competitive non-standard protocol (unlike the HD-DVD vs. Blu-Ray standards), but maybe that changes now with all the consolidation (ie. Juniper, HP, etc.) and instead of a tagging standard (18-24 months of bureacracy), there quickly emerges a VN-Link alternative.

@JimD – welcome to protocol battles. I made my bones with SIP many years ago.

Great article. This is off the VN-tag topic but paragraphs 2 and 3 really stood out because of a biz-dev meeting I just had.

We were talking to a larger company about a possible partnership based on our technology which is winning market share. One of the engineers on their side was stonewalling us in the meeting because we are not standards based.

We tried to explain to him that the current standard is unable to solve the problem which is why we went away from it. Still he was stuck. I got the feeling that this guy never talks to customers and may be a member of the standards committee.

Good example of the tail wagging the dog.

Well, today you are probably stuck with option “c” above (for “creative” or for “compromise” . But this will improve. There are startups working on better vswitches, and VMware will surely improve theirs over time … and both of these will happen before your NIC vendor, server load balancer, application-aware firewall, and intrusion protection system all support VN-TAG.

In other words, VN-TAG is not a complete solution today either, and I expect the standards-based approach (of putting access-layer functions into the vswitch) will be complete much sooner because it is so much more straightforward architecturally.

The Ethernet frame format is virtually unchanged since 1980, when Ethernet went from 8-bit addresses to 48-bit addresses (and from 3 megabits to 10 megabits). 802.1q is the only frame format change since then, and it brought us VLANs and QOS which are important features. I remain skeptical that we should modify the frame format for the third time in history when the only benefit is enabling aggregation-layer switches to perform access-layer functions.

I see your point on the rigid segmentation model falling apart in multicast/broadcast environments too depending on how the upstream devices handles multicast replication.

1. What about traffic that is local between two VM’s on the same server? How do you get your policies applied uniformly to this traffic? The answer is that the vswitch would do it, which is great for Nexus 1000V but not so great if you are using a standard vswitch that does not have the security feature you need — in that case, you really want all traffic routed through your top-of-rack switch.

2. What about broadcast and multicast traffic coming into the vswitch from top-of-rack? If your vswitch applies policies based on the egress virtual port, you are okay, but if you are attempting to apply policies in top-of-rack, you are stuck, because the top-of-rack switch can’t treat the packet differently on a per-destination-host basis when the vswitch is simply going to flood the packet to several destination virtual machines.

In summary, doing everything based on MAC address is (in general) the same as doing everything based on port, which is the status quo today. Both MAC-address-based policies and per-port policies work great when the vswitch has the features, and they are both inadequate when you want the top-of-rack switch to do the heavy lifting.

In reality, the primary purpose of VN-TAG-like tagging schemes is not about making policies follow VM’s. You don’t need VN-TAG for that — you just need a vswitch that can enforce the policies. The purpose of VN-TAG is fundamentally to enable an aggregation switch to perform access-layer functions. To me, this appears to be a significant and unnecessary complication in LAN architecture, when the obvious answer is to perform access-layer functions in access-layer switches. It is not the sort of innovation that should be rewarded in my view, and I am hopeful that the IEEE sees things the same way, namely: we should create standards to solve customer problems, not to protect the business models of large network equipment vendors.

Good question Phil – can anyone comment?