In storage area networking, there are really only two vendors to pay attention to: Brocade and Cisco. Combined, these two vendors dominate the Fibre Channel SAN switch market with some 90% of market share by revenue, according to Dell'Oro Group. The rest of the SAN switch vendors just don’t matter, although we'd keep an eye on HP, which is showing more market share (by revenue) of Fibre Channel over Ethernet switches and adapters than Brocade, according to HP, though those numbers come from sales of FlexFabric, which includes Fibre Channel over Ethernet.
Yeah, yeah, revenue isn’t ports shipped, but let's assume the pricing is fairly comparable, and 90% share of anything is still a whopping majority. During the last year or so, some Fibre Channel over Ethernet experts have been arguing nuances of FCoE and which protocols you need or don’t need. FCoE interswich interoperability? I will be old(er) and gray(er) before that happens in any meaningful way. While these are interesting discussions—if you go for that sort of thing—ultimately, they won’t impact your purchasing decisions. You are going to use whatever your SAN vendor tells you to use.
If you are a storage admin, you already know this. If you are not, pay attention. In the storage world, you use the products you are told to use by your value-added reseller (VAR) or storage vendor, and that includes Fibre Channel SAN gear. Go off the approved equipment list, and you go off your support contract. Even though Fibre Channel is an American National Standards Institute/International Committee for Information Technology Standards (ANSI/INCITS) standard, competing vendors' products may not work well together. That there is even some level of conformance in Fibre Channel SANs is due as much to attrition in the product space--two SAN switch vendors and two to three host bus adapter (HBA) vendors—as it does to vendors working together. Or at least that is what Howard Marks, chief scientist and Network Computing contributing editor, tells me.
FCoE (FC-bb-5) is an ANSI/INCITS standard. TRILL is an IETF standard. The DCB protocols are IEEE standards. You don’t think they all get along, do you? Vendors can't even decide which of the many protocols you need, much less agree to get them to work together. One big debate in FCoE minutia is whether there is a need for Quantized Congestion Notification or not. Basically, QCN is a Layer 2 protocol where a node can tell another node to stop sending data when it gets congested.
J. Michel Metz of Cisco wrote a very good blog on QCN and why you don’t need it. You button-down types might like the drier but equally informative Quantized Congestion Notification and Today’s Fibre Channel over Ethernet Networks.
At least, you don’t need QCN when using Cisco equipment because of how Cisco implemented FC-BB-5, where each switch takes the FCoE frame, decapsulates it, processes it using the embedded Fibre Channel forwarder, then encapsulates the Fibre Channel frame into a new FCoE frame and spits it out. You might need QCN with networking gear that hands FCoE forwarding differently, which Metz will tell you if you poke him with a stick a few times.
You don’t need QCN in Brocade's Virtual Cluster Switch (VCS) either, according to Gurpreet Singh, director of data center product management at Brocade. The VDX switches, which form the VCS network, can support QCN, but Brocade has yet to have a request to enable it. Brocades VCS—its multihop FCoE suite of products and architecture—performs Fibre Channel Forwarder functions at the network edge and forwards TRILL frames containing FCoE natively across the spine switches.
Brocade has a decent techincal overview of VCS. To ensure lossless operation, VCS prioritizes control plane frames like neighbor discovery, TRILL control plane and iSCSI control plane at a high priority by default, and any other traffic can be prioritized to be lossless.
