Proprietary Cometh before the Standard

Published On 2011/02/19 | By Kurt Bales | Rant

Driving home the other night I was listening to the latest episode of the podcast “Coffee with Thomas”. This episode had our host, Thomas Jones, interviewing Steve Chambers of ViewYonder (and also a history of great vendors!). During the interview, Steve made the following comment:

It amazes me that people criticise Cisco for not be standardised on things that are brand new, as if the standards bodies are innovators. That is not their job. They follow up after things have been invented.

This statement took me back at first, and I was about to write it off as protecting your own team, but the further I drove (I have a very long commute – about 100km each way) the more I thought about this statement and the evidence – both historical and current.

As network engineers we often love to get into religious arguments about which technology is better, and almost invariably a comparison will be made between a vendor proprietary solution and an open standards solution. Whether that is EIGRP vs OSPF, HSRP vs VRRP, or FabricPath vs TRILL they all seem to come down to a core need:

I have a need right now, and the standards bodies will take years to agree. Do I innovate and press forward with what I can do now, or do I wait?

When HSRP was introduced the market had a need for redundancy of Layer 3 gateway devices. A vendor saw a problem, thought of a solution, and implemented the solution without waiting for the rest of the market to catch up. And I firmly believe that this is in the best interest of the market. Once HSRP was recognised as a viable solution other vendors and standards bodies worked on bringing to market an industry standard protocol. Admittedly Cisco could have done many things to improve HSRP (proper load balancing is just one idea, though they brought similar options into GLBP), but they brought a solution to market when it was needed.

Zoom forward to today. The market today is seeing a push towards large virtualised domains (dare I say “Cloud”?), and as a side effect of this we (currently) need to implement these solutions using large Layer 2 domains. As has been the history of Layer 2 this comes with the “nightmares of spanning tree”, that seems to wake up so many admins at 2am in the morning in a cold sweat.

A problem exists now, and a solution is needed now. As is usual with standards bodies there is much debate as to how to move forward as everyone has their own opinion. In fact, which standards body do we look to? IETF with TRILL or IEEE with SPB? Life is slow in the land of standards, and while the boffins are battling it out there is a market place looking to roll out a solution to meet a need in there own environment.

So who is tackling these problems today? Well, like in the past, some vendors are claiming “There is no standard to move forward with”, or “We will support it when there is a standard”. This is not innovation – this is doing the same as everyone else. Im honestly not sure how I feel about a tech company who will only do exactly what everyone else is doing. Maybe in the sub-$50 SMB switch and router market sure – but not somebody I have to justify budgets and ROI and staking part of my career on!

Cisco’s FabricPath and OTV solutions may not be standards compliant. They do appear to have taken several of the nice features of the proposed standards and added some other features that will improve the Nexus platform overall, but they are not backwards (forwards?) compatible with either of the proposed standards.

Is this a bad thing? They have gone to market with a solution to a problem we have now. From the accounts I have heard the technology appears to do what it promised (even if it was behind schedule). With the standards “almost ratified” should they have waited so that their competitors could go to market with a solution at the same time?

The main thing I would like to hear from Cisco is that they will also support the standards compliant version when ever it finally gets ratified.

Im sitting in a hotel room in Hong Kong right now, with a whole city to explore so I will leave it here for now.

As always, thoughts, flames and comments welcome.

Like this Article? Share it!

About The Author

Kurt is a Network Engineer based out of Sydney Australia. He a the Senior Network Engineer at ICT Networks where he spends his time building Service Provider networks, and enterprise WAN environments. He holds his CCNP and JNCIE-ENT, and currently studying for his JNCIE-SP and CCIE R&S. Find out more about Kurt at and you can follow him on Twitter.
  • Kurt,
    You hit the nail on the head. If customer shoose to wait for the standards, that is great, but for those who have a need and or desire, non-standard solutions meet the need. Additionally, as a customer, having competition between vendors is desired, right? If everything is the same across the board and there is no feature differentiation the world would be much more boring. 😉

    Enjoy Hong Kong; it’s one of my favorite cities!

  • Jeramiah Dooley

    Good observation, Kurt. The vendors who play the “we haven’t released the hardware/solution yet because there’s no standard” game are just looking to cover their inability/unwillingness to innovate with an excuse. The customer is the ultimate arbiter of what is valuable and what isn’t, not the standards bodies. The standards are there to make sure the customer has choice once the market has decided on the features that need to be included.

  • Pingback: When Proprietary Kills the Standard()

  • Carlos

    FWIW, cisco says that FabricPath is TRILL complaiant at the data plane, and that they will support the standard when it settles.

  • Pingback: Technology Short Take #12: Networking Edition - - The weblog of an IT pro specializing in virtualization, storage, and servers()

  • Kurt,
    Great blog. I agree 98% with what you are stating. The piece I feel that is missing in your article is that there will never be a standard (IEEE or IETF) is there is not first a solution out there in the market that is gaining traction. Meaning that you need a vendor to invent (by definition that then is proprietary).

    It is up to the vendor that invented the specific solution, to submit his solution to the standards bodies, or have the standards bodies create a totally new standard. In most cases the inventing vendors solution is never copied 100% as a new standard as that would give this vendor a lead over the following vendors. And since all vendors together vote/define the new standard, it will always differ. That implies that the inventing vendor will at some point have to ensure his products support both the invented solution as well as the standardized solution (which could be a few years later).

    Standardizing is a good thing – not just for customers, but also for the inventing vendor. It makes the market for a specific solution bigger. Proprietary solutions market size will always be limited. In my experience, customers want to know that there is a path towards standardization for new technolog and are happy to deploy if that is the roadmap – and the technology solves a problem they have today.


  • Pingback: Proprietary? So what. | In Search of Tech()