My buddy Steve Foskett wrote a blog recently that talks about FCoE and 16Gb Fibre Channel. I want to say, for the record, that I like Steven, a lot, and normally I think he has a good grasp of the realities of new SAN technologies that emerge.
At the very least he has usually shown himself to be fair and balanced, even if not totally unbiased. In the many, many articles he has written I have never seen him knowingly write something to be untrue in his examination of technologies such as FCoE… until now.
For that reason, I can’t help but feel very disappointed.
The problem is that he writes in his first paragraph, “Why use a 10 Gb Ethernet standard that remains in flux when 16Gb FC is shaping up nicely?”
Thing is, Steven knows that the DCB standards have been finished for a while now, and that Multihop FCoE has been completed for years.
What he is most upset about, it appears, is that for FCoE storage there is “no interoperability”, and therefore more work needs to be done:
“FCoE is functional as an edge-only protocol, and is gaining traction in specialized use cases like blade servers. But end-to-end FCoE requires integrated Fibre Channel Forwarding and Ethernet fabric technology that remains decidedly experimental, and interoperability is a serious question.”
Steven apparently confuses several issues in his statements, which is most disappointing because I have sat down with him one-on-one and I know him to have a much greater understanding of where things are in terms of standards, vendor implementation, and what can be considered “prime time.”
I know he’s not the only one, as I’ve watched panels at SNW and have read reports from Interop where several people have conflated these questions into one big honking answer that doesn’t really help anyone make an informed decision – not customers, not vendors, not analysts.
In reality there are four basic questions that need to be asked and answered individually in order to begin determining the status of FCoE development. None of them, however, address the crux of the issue: whether this technology is a tool that may be useful for solving customer problems or not.
Some people have made erroneous statements that simply are not true. For Steven (and several additional others who have decided to write about FCoE from positions of uncertainty or ignorance), here they are:
Question 1. When will Multihop Standards be done?
Statement 1. The Standards for Multihop are not done (either for FCoE or Ethernet)
Steven implies in his article that the 10Gb Ethernet standard “remains in flux.” He knows this is not true, because the key elements for running Consolidated I/O on 10Gb Ethernet have been completed for a while now. The key DCB standard documents, Priority Flow Control (PFC), Enhanced Transmission Selection (ETS), and Data Center Bridging eXchange (DCBX) have all been approved for inclusion in their final form into the 2011 revision of 802.1q. (Yes, that’s how it’s described – the shorthand version, “it’s ratified” is not actually used by the standards committee).
(A fourth document, Quantized Congestion Notification (QCN), is often erroneously lumped into the mix for consolidated I/O, but as I’ve pointed out earlier this is a red herring and has nothing to do with FCoE or Converged Networks.)
Moreover, the standard for Multihop FCoE has been completed for several years now. Stephen also knows this and has spoken about it several times on his own blogs, podcasts, and public speaking engagements. He doesn’t specifically call it out in his most recent article but heavily implies this to be the case.
Question 2. When will vendors have Multihop FCoE?
Statement 2. Nobody has Multihop FCoE technologically ready/End-to-End FCoE isn’t ready for “Prime Time”
This is the most interesting one – from my perspective, certainly – because the statement is simply factually incorrect; on the other hand, the question may simply be a matter of not knowing what is available in the marketplace.
Cisco made Multihop FCoE available on the Nexus 5000 series in December, and Director-Class Multihop FCoE in August and September on the MDS 9500 and Nexus 7000 platforms, respectively. This is released code available now, and not sitting in some testing phase.
Steven knows this as well, as do several of Cisco’s competitors. While I can understand while someone would want to perpetuate this incorrect information as a competitor, throwing in all kinds of nonsense about needing QCN or TRILL, Steven’s insistence on stating that end-to-end FCoE not being ready for “prime time” is thoroughly disappointing.
With the standard being completed and the implementation tested, working, and available, it is not clear what “prime time” we are waiting for.
Could it be…
Question 3. Will FCoE interoperate between vendors?
Statement 3. There is no interoperability between vendors
On the face of it, this is simply not true. The Fibre Channel Industry Association regularly holds plug-fests with several switch, storage, and server vendors that consistently strive to improve interoperability with new equipment.
As just one example, take a look at the new Nexus B22 Fabric Extender for HP’s Blade Systems. Fitting into HP’s C-Class Blade System chassis, customers can connect interoperable FCoE between vendors. This is in addition to the rack-mounted solutions that have already been available.
I mean, come on! If HP and Cisco can do fully end-to-end FCoE then how can you claim it’s not interoperabe?!
(For the record, I wrote a joint paper on FCoE and Converged Management with HP’s Rupin Mohan, published in the FCIA Solutions Guide in time for SNW Fall 2011. If it becomes available on the web I will post a link to it in an update. Not working together… yeah right).
Ah, but the question has a sinister twist. The question comes into play if certain vendors will work with other vendors. That is, will Cisco FCoE work with Brocade’s FCoE?
Before answering, let’s take a look at the merit of the question on its face. First, this places an incredible burden of fitness on one vendor’s implementation (i.e., Brocade’s). It assumes that until Brocade offers interoperability, even if Cisco has the technology – and now QLogic – then it doesn’t count as “complete.”
Second, given that Brocade’s FCoE solution is not a standard implementation of Multihop FCoE – take a look at the specifications, where it says that it requires the VCS technology in order to work – does this mean that the entire industry hinges on one vendor’s willingness to interoperate?
Does this mean that end-to-end FCoE is only possible once Brocade catches up with everyone else?
I think not.
If that were the case, we would have to concede that end-to-end Fibre Channel implementations are not possible because Brocade actively prevents interoperability in that technology as well. Obviously, the mere suggestion of this is laughable.
So, I turn the question around. If one vendor has applied standard-based FCoE technology in its products, has released those products into the wild, and has created solutions based on that technology, should that vendor be accused of not having the solution just because “not everyone else” has it too?
Question 4. Who is using FCoE?
Statement 4. Nobody is using FCoE
This is not so much an argument as it is an excuse for not thinking.
It is, after all, the height of arrogance to assume that just because one does not see or hear of customers implementing end-to-end FCoE that no one is using end-to-end FCoE.
This is particularly curious as Multihop FCoE for Director-Class systems (the most common for Aggregation and Core deployments) has only been available for two months.
The other key thing to note is how often critics disqualify existing FCoE deployments as “not counting.” Apparently despite the fact that the technology is consistent regardless of where it is placed in the data center (same standards, same frame type, same protocol format), the only “valid” location for critics are the ones that have yet to be implemented by their favorite corner of the Data Center.
Truth is, I cannot reveal the customers who are working on end-to-end FCoE because, as is common in the industry, you need to have permission to do so. Fortunately we do have deployments that have gotten customers excited enough to want to participate, but these things take time to develop. And like everyone else, I will just have to wait until those Case Studies are completed. (Being patient can be very difficult for me, too.)
Ultimately, though, this is a non-argument.
Everyone’s data center is unique, and what may be a problem for one company may not be a problem for another. The fact that FCoE solves a problem for one customer in all likelihood will not be the reason why another decides to implement it.
After all, I’ve never – ever – said that FCoE was a panacea for the Data Center. In fact, the only people I have ever seen say that particular phrase are those who criticize FCoE vendors for saying it (in other words, they’re making it up in order to knock it down).
Let me put it this way: FCoE may be a technology to help your data center, or it may not. But how will you know unless you first understand enough about it in order to make an informed decision?
Looking at what your neighbor is doing will not suddenly change the unique nature of your data center, what solves their problems may not solve yours, and I get concerned when looking at customers who rely too heavily on peer pressure to solve their own complex issues.
Generally, Steven knows that the standards are completed. So does every vendor out there who has skin in the game, despite what they may write on their blogs or (not-so-subtlely) guest-write for trade magazines.
They know that the technology is stable, and they know that there are solutions out there that are interoperable between vendors.
Most importantly, they know that the more customers are confused about the technology the more they are likely to second-guess themselves and misread the opportunity to solve problems they have in their data centers.
My disappointment with Steven’s post is that he knows all of this, we’ve spoken at length (in person) about it, and he has shown that he has a much better understanding of the issues at hand than his blogs have revealed.
(I mean, come-on! FC over Token Ring? Freakin’ hilarious!)
It’s understandable that the most prevalent (dare I say “best”) defense is to simply ignore or pretend that Cisco’s vision of Converged Networks doesn’t exist in reality. It doesn’t change the fact that it does, and that it’s here today.
Despite all claims to the contrary (notably by critics who have a vested interest in pushing their Mononetworks), additional features and products are on their way, interoperating with the 16G solutions and increasing the amount of choice for customers.
Cisco’s dedicated to giving more and more choices to customers to use the right tool for their Data Centers, without forcing them to choose. Moreover, we’re doing it with tools and technologies that are available today.
No one is asking Steve to endorse or promote one technology over another, nor am I pushing for him to support FCoE (or Cisco). That’s not his purpose, and not my place (I would never do it anyway).
It would be far better, however, that in these conversations we be more deliberate with the terminology. It’s important to help reduce any risk of confusion by providing accurate answers to the questions at hand.
Finally, an honest and genuine examine of the realities of converged networks would clearly show that end-to-end converged networking with FCoE is, in fact, “Ready for Prime Time.”