Moooo-re Siloes Please!

I have received a few private comments that I was unduly critical of tagging mechanisms in my recent post about the VN-Tag/VN-Link debate between Cisco and HP.  I don't have a problem with tagging mechanisms, in fact I am a fan of them - however, I have an issue with too many tagging mechanisms.  There ends up being a tag for about everything - we have Security Group Tags, MPLS Tags, VLAN Tags, QoS Tags at L2 and separate ones at L3, we also now have tags that identify the Virtual Machine or the NIC on the Virtual Machine so we can create new NICs in software.

Let's just own up to it for a second that there are way too many tags; however, the problem is not always the industry and companies that want to create a new tag. Now before I go offering a solution that is highly likely to not be flame-retardant let me get on my proverbial soapbox for a second, so bear with me...

I think a root cause problem is that there is a schism in the relevant standards bodies.  I have to go to one standards group for Ethernet (IEEE), another to work at the IP layers (IETF), yet a third if I want to carry storage traffic (ANSI T.11) - and this is the tip of the iceberg.  It is hard enough to shepherd a great idea through the bureaucratic morass that are created anytime you put that many strongly opinionated, diametrically opposed, and discretely compensated individuals on a board/council/committee and try to get them working together but now with things getting 'blurry' between the once rigid lines between siloed standards bodies it is near impossible.

So while I often catch the brunt of 'why isn't this done in the standards bodies' question and have fielded it for years I don't think we have done a fair job of analyzing how efficient the standards bodies are and whether they should look at reorganizing around how their customers use the technologies they ratify.  The world is changing from 20 years ago - are the standards bodies changing with it?  Are they part of the legacy of siloed information technology that needs to change with the new world order where lines are crossed, borders are blurred, and service is more important than boxes?

As far as how to solve this embedded multi-vectored tagging problem I don't think there is one 'right' answer.  But one thing I always with was available was a single extensible tagging structure, that could be layered/embedded, that could be re-purposed for different functions and the first few bits (say 8 or so) delimited what 'kind' of tag it is (QoS, App Descriptor, Segmentation, Forwarding, Cloud Storage Access Rights, etc), and the next 16-24 bits were used to delimit something relevant within that kind of tag.  Done in an extensible fashion we could keep the extended header short of 128-256 bits which would mean it could pretty easily be parsed with one of the more advanced stream processing methods on the market.

One standard to rule them all, one to bind them...

Yes, it is sort of 'too simple' and is probable a bit like Dark Lord Sauron forging the 'One Ring to Rule them All, One Ring to Bind Them' (and the fact that I am doing that from memory should be a strong signal that I missed ComicCon)  but a tagging construct that 'crossed party lines' between IEEE, IETF, ANSI, ISO, W3C, etc could be quite interesting.  It's a shame there is not standards body to run it through....

dg

Tag, you're it!

Recently there has been some eloquent flaming back and forth between Cisco and HP over the VN-Tag, of course I have an opinion and figured I would vocalize it.  Scott Lowe has a good piece on this as well, focused more broadly on the implications to the unified computing system.

First off, I do not think there is a lot of innovation that comes directly out of the standards bodies.  However, i firmly believe that in today's mature networking market in order for a technology to get a decent traction and following it must at least be inserted into the standards process and be on a trajectory towards being multi-vendor and open/interoperable.

Secondly, I believe that innovation should be rewarded.  "To the innovator go the spoils" I say.  Innovation is risky, there should be a bit of light at the end of the tunnel.  I am not-so-subtly reminded of a conversation with about 20 customers I led a few months back.  I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard- the gentleman from a large manufacturing company interrupted him and said, "I don't care what standard they support, as long as they solve business problems for me I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs."

Lastly, and somewhat controversially, I think there are enough tagging formats out there already, and worse: most of them have no interoperability plan or architectural tie-in with each other.

Let's look at VN-Tag with these three lenses now....

1) VN-Tag was jointly developed by Cisco and VMWare to address a problem their customers were having: they could not bind a policy to a VM and have that policy move with the VM in a DRS or VMotion environment.  They also felt that traffic could go from one VM to another, bypassing any network policy for governance or regulatory compliance and thus have a tail-end/hop-off type of attack possibility for VMs on the same physical host.

2) It was submitted to the IEEE, but is not a standard yet, thus to be binary it is 'proprietary' although it seems the companies are not holding onto the IP specifically, they just want to execute on a time-to-market advantage.  (this is no worse and the ongoing CEE vs. DCE debate (note: there both are proprietary...  DCB is the IEEE standard))

3) It is 'yet another' tagging format.  If you trust that MAC addresses will not change dynamically the same problem-set could have been solved by binding network policy to the MAC address of a host.

Was VN-Tag necessary?  maybe...maybe not.   Personally, I think many of the same problems could have been solved if the MAC address was used to instantiate policy.  There is a legitimate concern that the MAC address could be spoofed, but then again so could a multi-byte tag structure too unless it has signing/authentication/etc.

Is it proprietary?  Yes.  Although all indications are Cisco and VMWare are working to shape an industry 'de jure' standard and are trying to gain a time to market advantage over merchant silicon based players. (I would argue that innovation should be rewarded so a time to market advantage in silicon is not out of the question and probably shouldn't be demonized).

Is it well implemented?  Here is the rub of the whole thing.  Implemented broadly this is a promising capability for a network to have.  VM's are, after all, the building block of many leading edge new data centers.  However, VN-Tagging does not seem to be broadly embraced across the portfolio of products in the data center.  At least I can see no indications of shipping products or announcements of how this capability is going to be brought into the security products, application networking products, routing products, rest of the Nexus line, etc.  Broadly implemented in a coordinated fashion- this would be a powerful capability.  Sporadically implemented in one or two products will lead to little impact.
This will probably get flamed a bit, so am finding the nearest asbestos store...dg