Just when I hoped we were finally getting somewhere with the FCoE/QCN discussion, Brocade managed to muddy the waters with its we-still-don’t-know-what-it-is announcement. Not surprisingly, networking consultants like my friend Greg Ferro of the Etherealmind fame responded to the shenanigan with statements like “FCoE ... is a technology so mindboggingly complicated that marketing people can argue over competing claims and all be correct.” Not true, the whole thing is exceedingly simple once you understand the architecture (and the marketing people always had competing claims).

Pretend for a minute that FC ≈ IP and LAN bridging ≈ Frame Relay, teleport into this parallel universe and allow me to tell you the whole story once again in more familiar terms.

I apologize to the younger readers who never had the privilege to experience the “beauties” of Frame Relay, but to my knowledge Frame Relay was the last major technology that implemented congestion notification.

Imagine your hosts need IP connectivity and native Frame Relay connectivity (maybe to run SNA over it, after all, we’re in a time warp). Obviously the hosts would have a Frame Relay port instead of a 10GE port and two virtual circuits (DLCIs), one for IP and another one for SNA.

Some vendors in this parallel universe would be really good at making routers with minimal Frame Relay implementation which would lack FECN and BECN support (Frame Relay congestion mechanism). Actually, Cisco IOS was lacking FECN/BECN support in its Frame Relay switching code for a decade, but let’s not call any names here. The by-now familiar “dense-mode FCoE” diagram ...

... becomes something like this in our parallel universe:

Obviously these vendors would try to persuade you to use routers everywhere, do IP routing and Frame Relay switching on them, and ignore the FECN/BECN issues. After all, when you do hop-by-hop IP routing, you don’t need FECNs and BECNs, they would be lost at every hop anyway.

On the other hand, you would have the Frame Relay vendors. They would lack IP routing knowledge, so they would try to tell you that you should do Frame Relay switching as long as possible (obviously using their gear) and use routers only on the edges of the Frame Relay cloud. The “sparse-mode FCoE” diagram ...

... would look like this in the Frame Relay/IP parallel universe:

Congestion avoidance (FECN/BECN) becomes more and more important as the size of the Frame Relay network grows and so these vendors would claim that you must support end-to-end congestion avoidance if you want IP to work well.

Did vendors argue about the “best” architecture when Frame Relay and IP were competing? Of course they were. Did people claim that “IP was mindboggingly complex”. Sure. Did we figure it out? Eventually most of us did. The same will happen with FCoE. Just keep in mind the basics and try to evaluate vendors’ claims using good reference architecture (do I have to tell you that I know one of the possible sources?).