A while ago someone posted a link to an article that links to LinkedIn’s blog post describing their switch-building efforts to the LinkedIn SDN group (how’s that for a circular reference?), and a consultant from Brocade felt compelled to share his wisdom with the world. Unfortunately he got most of the facts wrong.

Please note that I’m not picking on Brocade (anyone who watched my Data Center Fabrics webinar knows I like some of the things they’re doing), and a lot of my very good friends work there. I also don’t care what vendor reps tell their customers (until those same customers ask me for my opinion), but if you decide to promote your marketing messages on a public forum, you’re fair game.

This is how that consultant started his story:

When we acquired Foundry back in 2009 one of the first efforts our teams got involved in was a purpose built Ethernet Fabric technology called TRILL

My sources tell me that the VCS Fabric solution has nothing to do with Foundry (and the VCS ASICs clearly got some technology from Brocade’s SAN products), and it’s not TRILL. It uses TRILL data plane and FSPF routing protocol (at least a few months ago), which means it cannot interoperate with any standard TRILL implementation even though Brocade promised IS-IS support four years ago (to be fair, Cisco also promised TRILL data plane for FabricPath). In any case, that point is moot because the world moved on in the meantime.

… as well as the service provider industry creation of SDN, which in essence was the removal of all the clunky OS garbage that was unnecessary, and for which to your point, most of the costs and patching problems centered around.

I call bullshit. Brocade VCS Fabric still runs on monolithic NOS and the last time I checked the Foundry platforms also used a monolithic image. I might have missed something in which case I’d appreciate an update pointing to shipping documentation in the comments.

We worked with industry to remove our OS and created platforms that decoupled routing and switching decisions and out them on centralized controllers

What a bunch of Deja-Moo. Brocade switches still run Brocade operating system (which is their competitive advantage, without software they would be no different from any ODM shipping boxes at a third of the price). Also, Brocade was the last major data center vendor to implement OpenFlow on data center switches (assuming VDX switches already have OpenFlow support in shipping code – I really don’t have time do check those things more than twice a year or so).

To be fair, the Foundry platforms had OpenFlow for quite a while, but those are not the boxes Brocade’s web site lists under the Ethernet Fabric category.

And the cool part is since it is centrally controller and standards based our cots platforms could insert right next to these white box systems and integrate seamlessly as long as a standard controller such as OpenDaylight are implemented.

Will the madness never stop? The only reason those white-box systems interoperate with Brocade’s (or anyone else’s gear) is because they run BGP and OSPF.

In case you read the LinkedIn’s blog post (I know that my regular readers diligently read the cross-references, but some people love to comment without even bothering with the background facts), you might have noticed that they didn’t mention controllers, OpenFlow or OpenDaylight even once. Why not? Because people who know what they’re doing and try to solve real-life problems don’t need those distractions to get the job done.

The same consultant decided to share more wisdom on network automation, Puppet, Chef, NETCONF, OCP and a few other topics, but I had enough.

Note to $Vendor SE managers: if you think your team members might suffer from over-exposure to marketing messages and would value alternative real-life perspective on emerging technologies, I might have a solution for you.