What is the easiest way to account for space/power consumption of a network element?

Am making a spreadsheet comparing different products and looking at longer term costs, maintenance, power, cooling, etc.  I felt that rather than scrubbing the DOE sites and trying to get power costs by state I would just use the national average, but then fell flat on that because I found negotiated rates could be much less than published tariff rates.

Then I stumbled upon what may be an easier solution to my quandary and one inline with what I see a lot of enterprises doing - call a hosting company.  I haven't talked to too many enterprise customers that are not at least considering if not seriously considering using a hosting environment, or event a full-blown cloud deployment for some portion of their enterprise data center workloads.  Why? - the main reason I keep hearing is that most enterprise customers cannot build big enough to achieve the same economy of scale as a Google, Microsoft, Facebook, etc.  So they may as well lease space from a provider who can achieve a higher density, lower PUE, better delta-T, and handle the compliance tasks like SAS 70 Type-II (Switch, Equinix, Corelink, etc) and not to mention the IT assets put within the data center grow at a power/performance curve that usually breaks the facility they are housed within in 5-7 years, so who wants that on their books - better to let the provider manage/operate it.

In asking around I got to an average number of ~$155 per month per kilowatt consumed when in a hosted environment (ping, power, pipe).  Does this seem inline to you or too high/low based on what you are seeing?

With this data you can then extrapolate Watts/10Gb port across several systems and you get variability from $92/year per 10GbE port up to $372/year per 10GbE port assuming $155/month per kilowatt.  (I am eliminating my own companies products from this so as to avoid being a blatant advertorial...) Annualized hosting/power cost comes to $9,400 to $25,800.

I will be the first to admit there are HUGE differences in features, programmability, buffering, network segmentation, encapsulation methods, and Quality of Service Granularity between many of these platforms.  Those that performed the best were usally more 'switch like' with smaller buffers, less features, and fixed function ASICs for the data path.  Those at the top end of the spectrum were almost always products like Juniper's T640/T1600 and Cisco's CRS - extremely high function core routers with huge performance, buffers, shapers, policers, and probably most importantly a software upgradeable packet processing engine that allows incremental feature additions that execute in the data plane.

It's clearly not an apples-to-apples and don't want it to come across that way, my real question is - is using an average of US hosting pricing per kilowatt an effective way to get a model for opex cost/10Gb port or are there other models people would recommend?  Am pretty open to anything right now provided it is accurate and neutrally intentioned.

dg

If you don't like synthetic astroturf, you'd plant real grass, right?

In March 1999 Scott Bradner from Harvard University and Jim McQuaid of NetScout got together and published RFC 2544 - "Benchmarking Methodology."  In the subsequent eleven years this informational RFC has been used to provide a baseline for testing many networking devices.  It is designed to provide consistency between vendors so an end-customer can make a more informed buying decision and have some idea of the performance and scalability characteristics of the products they are considering.

For many years this RFC was applied by testing companies to provide comparisons and contrasts between different networking vendors.  Recently though, a company who usually takes an 'elder statesman' role in the networking industry and takes pride in its public brand image wrote that this was 'synthetic testing' and was not in any way indicative of 'real world' performance results customers were likely to see.  This was published on their blogs, and then on comments made on NetworkWorld's web site by their employees renouncing the testing and trying to invalidate the good work of David Newman.

I have a simple question...

"In the last eleven years why didn't you write a better and more 'real world' benchmarking methodology if the one you blast as synthetic is really that deficient?"

I mean, let's be serious, you are a huge company, and have the resources.  You have lots of people who go to the IETF meetings and try to steer standards.  You have lots of customers and have no problem telling us that, so it can't be a lack of revenue.   Why not just help us all by writing a better test plan rather than proverbially taking your ball and going home?

As I close this little diatribe let me remind everyone of two fun little stories...

In 2006 Kanye West was up for 'Best Video Award' at the European MTV Music Awards.  He won in a smaller category, 'Best Hip Hop Artist' but failed to win the prestigious 'Best Video Award' losing to a  smaller production.  He stormed the stage and "lashed out in a tirade filled with expletives," West said he should have won the prize for his video "Touch the Sky," because it "cost a million dollars, Pam Anderson was in it, and I was jumping across canyons."

Apparently to the judges it didn't matter how much Kanye spent, or that he looked cool flying across canyons, they judged on value.

By contrast at the 2009 Academy Awards 'Slumdog Millionaire' won Best Picture, Best Direction, and six other Oscars.  As Danny Boyle and then Christian Colson took the stage to thank their teams and supporters their competitors stood up and cheered for their victory.  You never saw Ron Howard, Gus van Sant, or Sydney Pollack trash-talking the Academy for how they voted.

These guys are smart enough to know two things - One, you are measured by how you well you lose as much as by how you win.  Two, if you bad mouth the Academy how will they treat you next year?

Do you want your primary networking vendor to be more of a Kanye West or more of a Ron Howard?

Imagine a car that was fixed speed and couldn't adapt from highway to city to parking lot. Just sayin'...

I am still a very proud alumnus of cisco Systems, but am also not bashful about areas I think the networking behemoth can improve.  My main recommendation would be to get the business units working together to consistently solve customer problems - be a big company, but act like one company, not 20 or 50 or however many initiatives, boards, councils, or work streams there are.  As a former commissioned combat arms officer I will state that some things are better run in a command and control environment if you want consistency and necessary if your customers want a consistent experience.

The recent 'data center' announcement of 10GBASE-T products really served to illustrate this better than I could ever explain.

According to Cisco's Frequently Asked Questions about their 10GBASE-T products for the Catalyst 6500 and 4500 they state the following:

Q. Is the 10GBASE-T line card on the Catalyst 4900M compatible with Gigabit Ethernet?
A. The 10GBASE-T line-card module on the Cisco Catalyst 4900M supports Gigabit Ethernet or 10 Gigabit Ethernet mode for each port group. The eight ports are divided into four port groups, and each port group can be configured to operate in either Gigabit Ethernet or 10 Gigabit Ethernet mode. All ports within the same port group must have the same mode. This allows customers an easy migration path from Gigabit Ethernet to 10 Gigabit Ethernet network connectivity.

Q. Can the 10GBASE-T line card on the Cisco Catalyst 6500 Series be connected to Gigabit Ethernet network adapters using auto-negotiation?
A. No, the 10GBASE-T line-card module will not support Gigabit Ethernet. It will support 10 Gigabit Ethernet network adapters only.

Can someone explain to me how the board, or council or whatever new-age org model is in charge decided that customers want a 10GBASE-T port that would support your existing cable plant but not interconnect your existing GbE attached servers on one switch (the Catalyst 6500 - hard coded into the PHY so it is not a field or software upgrade) and wanted a completely different behavior on the other (Catalyst 4900 that did the rather obvious feature of speed autonegotiation)?

Quick car analogy, since some people who have issues with 'synthetic tests' (apparently auto-negotiation tests are synthetic now too....)

Why build a network equivalent of a Bentley Continental GT that goes either 12mph or 120mph yet requires a mechanic to switch between the two speeds, and then have the audacity to claim that this offers an easy migration path between the city street and the autobahn? (analogy credit to Ed, you know who you are!)

This makes no sense to me.

dg

Everything seems to come full circle in IT...

Cautious optimism is a term I have been having many discussions lately with friends and analysts about - whether we are seeing true economic recovery or a bit of a 'W' and whether to make serious investments in planned growth or not.  Candidly, in IT we have compressed capital spending for a while, so it could just be a bit of elasticity - although one major thing strikes me as different.

In the current world order many of the IT investments seem to be directly proportional to short-mid term ROI, sure everyone wants to build for 5-10 years, but they also want to see real business results, right now.

Mostly this means that new project types are getting priority and IT is finding creative and innovative ways of delivering near-term business value without, hopefully, taking their eye off the architectural ball.  Ideally we can do both- deliver short-term value creation, while building towards a longer-term vision that enables IT to reinvent itself and infrastructure to transcend generational shifts. Sadly this is not always the case, some companies and people seem to want to either over-rotate on short-term. Sadder, others refuse to admit the world is changing.  Even worse are those who keep their head in the sand and cannot move at all.  Denying change happens is dooming almost any business to failure, embracing a fickle trend too quickly can be just as painful, and relying on past formulas from previous successes doesn't always work.

You may wonder where I am going with this.  Over the past thirteen years I have seen a lot of things change and come full circle- Cut-Through Switching, Lossless L2 Networks, Ring Topologies, Hosting/Cloud/Insource/Outsource.  Universal truth - things change and open and experienced minds that can capture this change tend to prevail.

Architectures have to change with the trend, the old way of doing things is not always the best- althought there are always viable lessons to be learned and due respect should be paid to past success.

Looking at networking, especially in the data center there are a lot of architectural changes in play.  Obviously, the changes being driven to effect convergence between Ethernet and FibreChannel is a big one.  The other is the collapsing of layers and efforts to simplify the topologies while increasing the scale of operations - I think in my next post or two I will have to explore these some more, what are your thoughts on other architectural changes in the data center network?

dg

Custom or Merchant Silicon?

Hello there!

I've been on a bit of a vacation the past couple of weeks, so sorry for the slow-down in posting frequency.  But now, I am back at my desk, with a decent speed Internet connection, and too many ideas on what to write about.

---------

Chance had it that today a friend of mine sent me an email reminding me of a blog post I wrote about a year and a half ago titled - 'On Merchant Silicon and Mowing my Yard.'  It was a piece, purposefully a bit inflammatory, designed to have a bit of a go at the guys who were drawing some interesting comparisons to product lines I worked on.

As often happens, times change.

Reading this email which spoon-fed my prior writings back to me, I had to reflect a bit.  Does merchant silicon matter?  Is it a sell out?  What creates customer value in a networking product?  Is it the silicon, the software, the system as a whole, how it operates with other adjacent products, etc...

Realistically, to me, what most people seem to care about in a switch is that it works, at the performance rates necessary, and that the software is stable and has the features they need to accomplish the networking task at hand.

Inside this system there is a collection of silicon, some of which may be custom, some which comes from vendors other than the systems manufacturer.  The PHYs are almost always 3rd party, the CPUs as well, most every part is always 'merchant silicon' except the switch fabric and the packet processor.  These are custom in some switches, or merchant in others depending on that specific vendors goals for that particular product.

Ethernet continues to evolves and offers lots of opportunities for innovation and improvement - some of these will require new silicon, some will require new software.  Using merchant silicon sometimes will affect a vendors ability to control the pace and order they bring features to market that require new silicon.  However, with the breadth of silicon available in the market today there are several viable silicon choices.

Custom chips create their own set of challenges - most vendors doing their own chips actually do their own logic and rely on a third party to actually build the chips and fab them out, deal with the process challenges, etc.  The vendors doing full custom take on a high cost burden up front and hope they get enough market traction to enable future R&D in their ASIC teams.  In this period of compressed budgets these programs tend to be one of the first things to get financial focus.    What do you think- is one better than the other, or is a healthy mix appropriate for our maturing industry?

P.S. Oh, and I outsourced yard mowing...  too time consuming and others did a better job than I ever could.

When will 10Gb become 'default' on servers and data center hosts?

Since 2002 I have been attending trade-shows like Interop and answering the same question, "Is this the year of 10Gb Ethernet?"

I never really understood the question, but after perennially trying to answer, and usually being inaccurate to what that individual questioner wanted to hear I started thinking about this a lot more, at least so I could have a reasonably rehearsed answer.  Running into Bruce Tolley from SolarFlare today, who hosted the panel I was on for at least the last couple of years, reminded me that we are still not quite in 'the year of 10GbE' so I started wondering why, and when it would be.

What's it going to take?  What will it take for 10GbE to take off on the same growth pace that GbE had?

In no particular order, I will start with density.  When I was first asked this in 2002 there was a single-port 10Gb Ethernet module shipping in the Catalyst 6500 and a roadmap to deliver a four-port module the next year.  Density matters, and how dense a network device is can allow different use-cases for the nascent technology.  I remember making a PowerPoint slide once that said essentially the following:

Single Port- nice demo
Two Ports- very expensive, nice for metro connections and dark-fiber long hauls
Four Ports- useful in Distribution to Core switch interconnection
Eight Ports- starts aggregating access layer switches
Sixteen Ports- a good density of campus wiring closet aggregation
Twenty-Four Ports- high performance server aggregation
Forty-Eight Ports- server aggregation

Not surprisingly as silicon densities increase, port densities tend to increase and costs can come down through volumes, value engineering, and better utilization of common equipment.

Orthogonal Upgrades.  Not all budget cycles align.  Sometimes you get budget for a server refresh, other times you have have budget for physical plant upgrades, and on others you have some room for new network equipment.  Most 10Gb implementations today require 'symmetric upgrades' i.e. you have to uplift the cabling, the servers, and the switches all at the same time in a coordinated manner.  This is usually a pretty big inhibitor.  You need to be able to add switches that support past, present, and future speeds, on top of existing cable plant, then allow the servers to upgrade when their budget cycle allows and computational/transport demands require it.

Price.  Yes, it always matters and many times it all comes down to price.  Let's set a magic mark of 10% and 3-4x depending on how you look at this.  It strikes me that when the price of a complete system (servers, NICs, cabling, switching) at speed X*10 is only 10% more than speed X the market moves pretty quickly to connecting the hosts at X*10.  The other way to look at it is that when X*10 is 3-4x the price of X in a myopic pricing arrangement the technology also tends to rapidly shift.

In many cases across most major vendors you can get two or all three of the above today.  The outlier for data center host conversion and 'cross-over' from GbE to 10GbE is 'LAN on Main Board'.  When all other factors align this tends to come out, and then the world changes and in the span of 12-24 months the new transport closes the gap and then starts passing its predecessor.

When do I think we will see the transition and cross-over (caveat- in the data center.  I see no current trajectory towards demands for 10GbE to the desktop or phone in a campus.  For all that video is the vaunted next wave of upgrades I can put several HDTV signals over 100Mb pretty effectively and it won't make a dent in GbE much less 10Gb to the desktop)  I saw some data recently showing 100% growth in 10Gb to the server quarter over quarter, although largely driven by HP Blades with their virtual connect and flex-10 offerings.  Given this trajectory and the desire for the server manufacturers to have a compelling value proposition against HP and Cisco's UCS I would imagine they are rapidly moving to offering 100/1G/10G LOM offers on their bladed and stand-alone server systems over the next twelve months.  Then we finally, after seven years of speculation, can have a 'Year of 10Gb.'

This is Greg, he likes DNS and DHCP, IP Address Management, Fine Scotches, and Infrastructure 2.0

Just a quick link and shout-out to Greg Ness of Infoblox and Twitter fame for a nice piece in SeekingAlpha that just hit here.

As I have said often enough to have been quoted and mis-quoted a few times there is a potential value-shift in enterprise IT given the increased business value many enterprises are realizing from virtualization which in some cases takes the network for granted or as one rather esteemed company once stated, "just dumb plumbing."

I don't want to be just a dumb plumber, and I think there are a set of very strategic activities the networking vendors can do to ensure that the network continues to deliver high-value and business-relevant services that enable the networking team within IT to keep their place in the pecking order.

dg

It's all happy up in the cloud, right?

For networking companies cloud computing could be the biggest boon or the biggest bane, or as is sometimes quoted - the road to (shareholder) hell is paved with good intentions.

Network companies have been relatively and somewhat strangely quiet about cloud computing. Sure we've seen some partnerships, some demonstrations, and a lot of rhetoric- but there really hasn't been a lot of action. There certainly has not been purposeful, planned, development. One of the reasons may be the school of thought that the network is an inherent beneficiary of cloud computing - certainly anything that spits more bits out and drives larger pipes is a win for networking, right? The darker side is that at scale cloud computing represents a fundamental shift in the balance of purchasing power and a massive consolidation of computing, and thus purchasing capability into a smaller number of larger companies.

We've already heard about search companies building their own servers and even rumors of them building their own networking equipment. When you have that much domain expertise consolidated and there is that degree of specificity about the features and capabilities required saving capex while lowering the power consumption reducing your overall operating costs against one of your biggest expense line-items is worth it to large enough providers. Plus many of these providers know exactly what features they do and do not need - and there is variability between providers based on their respective philosophies about redundancy, fault tolerance, accounting, traffic engineering, etc. Is this model for everyone? Certainly not. But for those with enough chutzpah, mass and the technical wherewithal, it seems to be working.

Now fast forward seven to ten years. (like when Bill Gates once famously proselytized a vision based on unlimited bandwidth and limitless computing power - what would you do?) Imagine 50% of the world's compute capacity is owned by five companies. The purchasing power would be immense, the value to a vendor of winning the deal is a make/break proposition to many start-ups and even mid-caps. The ability to squeeze margin out of the vendors and define the exact requirements for what needed to be built, unparalleled. High margins? Doubtful.

Where would the network be? Let's see, certainly my 'glass half full' self sees that there would be a large WAN opportunity and Internet core upgrades required to support the increase in mobile workloads and mix of elastic and real-time network traffic. Ideally there would be a way of consistently signaling a particular packet's requirement for real-time, lossless, or an elastic traffic profile across multiple network providers with some guarantee they adhere to the marking. Although with net-neutrality I doubt this will ever happen in any end-to-end consistent manner and the owners of the end-stations and clouds will over-provision capacity and use clever over-the-top mechanisms to solve this issue further reducing the carrier's value.

The main change for the network will be static and physical definitions of service bound to location shifting to much more dynamic addressing
and embracing workload mobility. The network needs to be able to move workloads to run on the server and in the location that can service that workloads performance and processing requirement in the most effective and efficient way possible. This will enable and drive demand for follow-the-sun, follow-the-kilowatt, and follow-the-tax-code portability and mobility requirements. This is not just moving a workload around the data center, this could be moving it from one continent to another, and not a one-time move, but a dynamic and elastic environment where resources are constantly being re-balanced to achieve operational efficiencies, meet customer SLAs, scale to add new customers or divest customers quickly, and ensure security/segmentation where appropriate.

As I have said before today's networks are not ready for this. The static addressing model is broken, the routing protocols are not designed for the scale or the change-rate, and the need for abstraction and management is different than any networking vendor has embraced yet.

Let's assume that the technical hurdles get solved, that really smart people who solved the addressing problems for mobile phone systems, local number portability, and global roaming can use some of the same principles and solve the issues around globalization of IP addressing, /32 host route mobility, and really large scale routing tables. Let's focus on what makes a networking system "cloud-ready" that is a bit more complicated than even these rather sizable network and routing architecture challenges- Religion. Politics. Business. Control.

Here's the big 'gap' in everyone's story. Right now each vendor views their own system at the core of this cloud. It's all about the network, server, VM, SAN, etc depending whom you are talking to. Everyone wants to take their castle and put it on a cloud, without giving the keys to above-said-castle to anyone else. This means a strong desire in every major player to keep business as usual and extend the current value proposition and operational models to the cloud as best possible, see what sticks, adjust, go from there.

I believe, depending how 'evolved' the segment is, this could be a major failure if the core capabilities of the technology are not designed around the principles needed in cloud environments: elasticity, self-provisioning, open APIs, programmability, trust, control, interoperability, etc.

Where are networking vendors failing and flailing? Largely around the management and configuration interfaces to their systems -- The CLI is dead to the new world order. Take every feature in a network operating system and write down the ones you use. Put them on individual note-cards on a desk and then put the ones that are machine-readable, software controlled/instantiated, centrally provisioned, and globally scalable in a box we call 'Cloud Ready' and put everything else in the 'Old World' box. If the Cloud Ready box is pretty empty, that vendor will be left with one thing to differentiate - PRICE.

Everything in the networking world is instantiated by a CLI. Every cloud operator I know wants a machine readable interface, they want their devices to plug into a common management framework, they want a single point of administration and control. For some this is home-grown, for some this will be VMware's vSphere, for others it may be another offering. This 'Cloud OS' does job macro-scheduling, enforces work flows, and provides elastic scaling and depends on machine readable interfaces into switches, routers, firewalls, servers, storage, and so on. It also will depend on consistency between managed devices - i.e. if stuff doesn't work identically between products the outliers are not likely to be adopted.

Many vendors are reticent to give their 'keys' to someone else's Cloud OS - i.e. if it can't be their own, they don't want to open the system up, to the operator this means now having to install multiple management systems when what they really want is one that can work with multiple vendors. The message I heard one cloud operator tell me was, "Be Open or Die."

Make the shift to building planned systems architectures, and intelligently using networking protocols to provide a consistent abstraction to a cloud OS, there is a chance to win big. Miss it, build fragmented systems with no management abstraction or not tie into the right eco-system of partners and risk rapid commoditization as the core value of your product can actually never be expressed to a customer/operator in a way they could use it. Unused features is simply higher cost with no incremental value.

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