Cisco Blogs

Do You Really Want a Nanny?

- December 16, 2010 - 1 Comment


If you are a Cisco customer, or thinking about becoming a Cisco customer, that number should help you get a good night’s sleep.  Why? Because it represents the percent of our revenue we devoted to R&D in 2009 – essentially towards developing solutions to the business and IT problems that you’re dealing with today or we expect you to see down the road.  As a percent of revenue, that puts us in pretty good company between Microsoft (14.6%) and Google (12%) and well ahead of some other IT folks such as IBM (6.1%), HP (2.4%) and Dell (1.2%).  Even in terms of absolute dollars, at $5B we are just behind IBM ($5.8B) and well ahead of HP ($2.77B) and Dell ($0.62B). (Source)

The customer benefit to this R&D spend is investment protection (i.e. we can afford to continue to invest in Nexus, Catalyst and MDS concurrently) and innovation with the development of new technologies such as extended memory on the UCS.  In short, it reduces customers’ risk and allows us to act on their asks.

So, you would think all this R&D and the resulting products and technologies are a good thing, but recently I have been pulled into a couple of conversations where we were accused of hurting the market for some interesting reasoning.

The current object of our critics’ ire is FabricPath (a technology introduced to help simplify data center networks and better support today’s workloads) and its similarity to another standard-in-the-making called TRILL.  Concerned folks are lamenting the fact that we are a) confusing customers, and/or b) subverting the standards process.

So, lets pull this argument apart a little bit and start with the “confuse the customer” part. Over my career I have met a lot of IT folks and as a group they tend to be a) pretty smart and b) pretty opinionated.  I am guessing the vast majority of them are not looking for a nanny to tell them what to do and to keep them safe.  To the contrary, I find most folks want to understand their options and have the freedom to make the best choice to suit their purposes.

As far as the “standards” angle, in this case, we actually co-chair the TRILL effort and have stated we will support TRILL and the hardware we are shipping will support both technologies, so I am not really sure how that subverts TRILL.  There is not even a lock-in angle, since the Cisco hardware in question supports both FabricPath and TRILL.

The argument has been made that since FabricPath offers a superset of TRILL’s features, folks might choose FabricPath instead of TRILL.  I guess, I don’t see a problem with that. If folks are focused on standards compliance, they can choose TRILL. If folks want certain functionality, they can use FabricPath. Net-net, folks should be allowed to choose what works best for them instead of their choices being artificially limited.  In this case, there is also a time component, since if they need a solution now, FabricPath is their only option.  But again, nothing precludes folks from implementing FabricPath to meet immediate needs and then migrating to TRILL once the standard is finalized. And, if the features in FabricPath are broadly compelling enough, they will probably end up in some future version of TRILL anyway.

At the end of the day, the fate of FabricPath and TRILL lies in the hands of our customers–they will succeed on their own merits, which is how it should be.

Finally, don’t get me wrong about standards. They are an important and intrinsic part of networking, but being open to innovation is just as intrinsic and what allows the networking market to grow and evolve instead of stagnating–I wrote about the balance between the two forces a few months ago.

So, dear readers, how do you strike the balance–when do you pick the functionality you need and when do you hold the line for standards compliance?

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. So I understand that a standard may take longer to develop than a proprietary technology as more people (Vendors) are involved and they each bring their own requirements and opinions and it perhaps needs broader testing to ensure interoperability. However I think the issue is that by pushing a proprietary technology such as FabricPath when a standard is not available then the choice becomes: Implement FabricPath now or wait year(s) for the standard to be ratified. Yes we could deploy FabricPath now and migrate to TRILL when it's available but I seriously doubt that that will be a trivial task, and will have a significant cost associated with it. I totally agree with you regarding your comment "I am guessing the vast majority of them are not looking for a nanny to tell them what to do and to keep them safe. To the contrary, I find most folks want to understand their options and have the freedom to make the best choice to suit their purposes" So why is my Cisco rep, lets call him nanny, pushing for me to implement FabricPath now rather than wait so we can better understand our options? Why would I want to waste my time and effort to deploy FabricPath now rather than wait till there is a real open standard option available at which point I can make an informed evaluation and decision on what is best not just as a technology but to meet my overall organisations network needs? I have no issue will I FabricPath as a technology and it may turn out to be the best option but I for one wont be rolling it out until TRILL is also available and only then if in comparison there is a clear benefit.