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.

When I started this blog last week, I certainly didn’t think my first post would be on the topic of Storage Networking. My background is R&S / SP more than it is storage. I work as a consultant building ISPs in Australia (and occasionally across Asia Pacific).

Some of my customers are End User ISPs, others are Content Providers, so I often get thrown at interesting new projects (sometimes at the whim of engineers on a tech-fetish, sometimes from the buzzword bingo of Sales and Marketing).

Given the industry craze at the moment for “virtualisation” and “cloud computing”, I knew it wouldn’t be long before I had to design a solution based on the Nexus platform and that this would involve more than just Ethernet and IP.

I knew that the Nexus would allow me to just implement a tried and true solution using MST and some port channels. What I hadn’t realised was that a whole new world of networking goodness had been opened up in the Nexus platform running NX-OS. Upon researching the NX-OS platform I learned wonderful terms such as “Lossless Ethernet”, “Virtual Port Channel”, not to mention more information about Storage networking than I had gained working with some VMWare/Virtualisation geeks on several projects.

I’m still investigating best-practices builds for the Nexus platform, but I currently have a project on hand that requires me to learn about FCoE and Virtual Port-Channel implementation.

I promise I will keep you updated with any new tricks I learn.

Resources:

http://jasonnash.wordpress.com/2009/08/10/vpc-virtual-port-channel-and-the-nexus-platform/

http://www.cisco.com/en/US/products/ps9670/prod_white_papers_list.html