I know, I know. Both claims bear some further investigation, which I will take up at a later date. Actually, I have a metric ton of questions about FCoE that I want to track down.
What’s that, you ask? How can two vendors implement the same standard in radically different ways? One of them has got to be non-standard, right? Nope. They both appear--to me, at least, based on conversations with both Brocade and Cisco and my reading of the relevant bits of the standard--to conform to FC-BB-5, which is pretty much mum on forwarding mechanisms. FC-BB-5 specifies the requirements that must be met, such as lossless forwarding, preserving order and some other important things, but leaves those pesky implementation details up to the vendors.
I suppose that if Brocade's and Cisco's implementations did conform to the standards, you could make them work together if you wanted to.
Mike Hagen from the University of New Hampshire Interoperability Labs (UNH-IOL) tells me that the next round of testing will be sponsored by the FC Industry Association and will include multivendor interswitch FCoE testing. The question is, why would you want to build a multivendor network (not to be confused with a multivendor DCB network, which is a different animal altogether)? After plunking down the large chunk of change for Brocade's VCS or Cisco's Nexus, learning how to make it all work nicely, integrating it with your management systems and operations, getting your staff trained, and ensuring that all the parts play nicely together, why would you want to add multivendor complexity to the network? You wouldn't. It wouldn’t make sense.
If you are going to converge your storage and data networking, here is what is going to happen. You are going to decide (however your IT department makes these decisions) to purchase whichever product set your storage VAR or array vendor tells you they support. Then you will build it out and make sure it all works well together. You are not going to worry about whether a product does or doesn't use QCN or whether each switch is a Fibre Channel Forwarder. You are going to rely on your VAR or array vendor to do the messy conformance and performance testing for you, and ensure that you can, in fact, ensure lossless FCoE SAN operation of your Ethernet network. You are not going to worry about whether the routing protocol is the IETF's TRILL, IEEE SPB, Cisco’s FabricPath or Brocade's multipath Ethernet routing protocol. (I can’t call what Brocade is doing TRILL. I just can't.)
You're going to use what you are told to use because if you don't, you—yes, I mean you—will take on the operational responsibility of ensuring both your data and storage are going to perform optimally at all times and will work with whatever equipment you acquire in the future. That's a responsibility that I am not confident you can meet, because the products don't have the baseline functionality to achieve seamless interoperability, and there are a lot of unknowns that need to be ironed out.
Nor do I see a compelling reason for competing vendors to work on FCoE feature/function interoperability. If you aren't going to demand interoperability (because everything is customer-driven, so I am told)--and you won’t, because you really don’t want it--the vendors aren't going to do it, and therefore you can't have it even if you did want it. Am I wrong?
