Brocade And Cisco Maintain SAN Lock-In Status Quo With FCoE

If you are a storage administrator, you are used to vendor lock-in driven by your storage vendor and you choose SAN equipment based on a qualified equipment list. You might even defend the lock-in as being preferable. If you are a network administrator looking at FCoE, you are going to chafe under these restrictions because you'll find your product choices restricted to whatever products the SAN vendor, Brocade or Cisco, has qualified with. If you go off the qualified equipment list, you won't get support, and you will continue to pay comparatively high prices for what should be commodity equipment and features. Both Brocade and Cisco are trying to maintain the status quo in storage by standards and non-standards based protocols for the same functions forcing you into making a difficult choice and potentially locking out competitors.

Cisco gets beat up when it comes out with protocols that are not standards-compliant. I have taken my swipes at Cisco for continuing to support Cisco's Discovery Protocol (CDP) when the IEEE Link Layer Discovery Protocol has been out for years. I brought up the standards issue during a small meeting with tech reporters and Cisco CEO John Chambers at CiscoLive. Both Brocade and Cisco are splitting the SAN market again on what appears to be a difference in interpretation of FCoE.

In a recent survey of 468 IT professionals, Networking Vendors: IT Pro Ranking [registration required],  about important data center features, adherence to industry standards was #2 behind virtualization. Proprietary technology in advance of standards was number 15 out of 15 features. Now it's Brocade's turn. The company's version of Transparent Interconnection of Lots of Links (TRILL) doesn't use the required link state protocol, IS-IS, but like Cisco, Brocade says its version of TRILL will be standards compliant. Something stinks.

To be fair, there aren't any TRILL-compliant implementations yet because TRILL hasn't been ratified by the IETF. It's with the IETF RFC editor queue, but for all intents and purposes, the standard is as good as complete. Brocade's disconnect with TRILL is that section 4.2 of the TRILL draft states that TRILL uses IS-IS for the link state protocol (the other multi-path protocol, Shortest Path Bridging, also uses IS-IS). Brocade's TRILL implementation uses Fabric Shortest Path First (FSPF), a link state protocol that Brocade uses in its FC SAN products. I came across this nugget while tracking down some questions on Brocade's Virtual Chassis System (VCS).

At first I thought I misunderstood Brocade's statement. Erik Pounds, senior product manager with Brocade clarified. He said "Brocade's initial implementation of TRILL uses FSPF. FSPF has been fully tested and is proven to build fabrics in data center environments. IS-IS with L2 extensions will be the industry standard. Once the L2 extensions to IS-IS become standardized and are implemented by other vendors, we will, via a firmware update, enable interoperability in those standards-based TRILL environments." FSPF may or may not be better, but using it rather than IS-IS means Brocade's version of TRILL is non-standard.I pressed Pounds on the L2 extensions he mentions, but I have yet to receive an answer. I don't see any extensions or language in either the draft RFC or in the other documents within the working group that indicates an alternative link state protocol like FSPF can be used with TRILL and remain standards based. I may have missed something, but I don't think so.

Cisco's FabricPath, which uses IS-IS for the link state protocol, also plays games with the standard because it adds some secret sauce to make FabricPath better. Cisco was open about the fact that FabricPath was using a pre-standard implementation of TRILL with proprietary features.

Pounds goes on to say "Once interoperable TRILL solutions are available, network architects are going to have to weigh the value of a multi-vendor TRILL network versus a single-vendor fabric. A lot of value that we bring in VCS is above and beyond what the standard provides. Cisco will claim the same with FabricPath,." He is spot on. Cisco said as much in their FabricPath announcement.

If you want to run a multi-vendor switch environment, you will face a problem with both Brocade and Cisco's positioning of TRILL. You, the IT buyer, will have to choose either the new and improved TRILL, or the standards compliant TRILL which is not new and improved and therefore is not as good. That is what Brocade and Cisco will tell you and it is how they lock you in. There doesn't seem to be any interest by either vendor in supporting both standard TRILL and their proprietary versions simultaneously. I don't know why Brocade or Cisco can't implement a dual stack supporting standard TRILL and their flavor of TRILL simultaneously. It's not like running multiple routing protocols, or in this case, link state protocols, is new and uncharted territory. Fact is, neither wants to.

If you are using Brocade's VCS or Cisco's FabricPath just for FCoE, it doesn't really matter what they do to ensure the FC frames make it across the fabric in the proper order, because the encapsulated FC network is a closed environment. But if you want to use loss-less Ethernet and layer 2 multi-pathing for anything else, like the rest of your network equipment, standards-compliant protocols are a must. There are already two standards-based layer 2 multi-path protocols, TRILL and SPB, which are not interoperable. Now with vendor tweaks, there are going to be more versions of protocols than there are vendors. Thanks for thinking of the customer.