Here is the 3rd video in a series to help educate on Fibre Channel over Ethernet (FCoE):

For a full list of EMC FCoE resources, see my previous post The current state of FCoE.
Additionally, on the question of “end-to-end Ethernet”, see…

You and I both know that there is a difference between educating/positioning a customer on technology trends so that the customer is prepared, and overselling a technology. Certainly we want our customers to be knowledgeable about where the industry is heading, and to plan and position themselves so that they can take advantage of technology for the benefit of their business. Recommending that a customer deploy FCoE today as an edge convergence technology with an eye toward a complete FCoE implementation/Unified Fabric in future years—as long as the customer understands the limitations in place today—is great. Implying, stating, or otherwise allowing a customer to believe that FCoE can do more than it actually can do, based on the state of today’s available’s products and implementations, is wrong. Let’s not confuse the two.

You said: “Selling/pushing/supporting FCoE for more than that is, in my mind, a disservice to customers…”

My comment to that is this: Articulating what the future holds with a technology investment and how it can transform something as significant as the Data Center is what customers expect from their trusted vendors.

A fast food restaurant only sells and discusses what is currently available, with no discussion of futures, investments, and return on thereof. There is no value in the relationship you have with your local fast food restaurant.

A technology vendor such as Cisco or Emulex, on the other hand, is never just selling what is available today. Rather, such vendors are selling a long term investment in technology architectures that affect planning with budgets and significant spending decisions. Customers want to make the best possible decisions with their long term investments, and discussing only what’s on the menu today provides no value to that effect.

Cheers,
Brad

(vendor disclosure: Cisco Systems)
(disclaimer: I am not an official Cisco spokesperson)

Exactly! If everyone were positioning FCoE in this way—which is really where it is best suited given the current generation of products actually available to customers—then things would make a lot more sense.

Thanks for your comments.

What I’m trying to do here is point out the gap between the standards and what’s actually available today. Customers are out there buying FCoE-based solutions with what is, in my opinion, an incomplete view of what is actually available. I’m not talking about what’s possible—I’m talking about what’s available. The vendors give people plenty of information on what’s possible, but what’s lacking is plain speaking on what is actually available.

Now, I’ll grant that I am not familiar with Brocade’s product line and therefore I’ll admit that some of these “gaps” may exist with Cisco’s product lines but not with other vendor’s product lines.

1. FC-BB-5 doesn’t restrict the types of network configurations, AFAIK. I provided two examples—certainly there could be many other configurations. The key point here, and one that you support, is that there are NO IEEE DCB-capable Ethernet switches available today. Therefore, customers attempting to build FCoE-based solutions today cannot build solutions architected on IEEE DCB-capable Ethernet switches connecting to an FCF. All the pieces aren’t there.

2. Once again, that’s all well and good, but all the vendors are just now getting around to full support for FC-BB-5, much less the as-yet-unratified FC-BB-6. Again, my beef is not with the standard, but with the real implementations available to customers.

3. You don’t think what will be a limitation? The lack of multi-hop support? I agree, it probably won’t be an issue. But the fact remains that many customers don’t know about this limitation, and I think it’s only fair to point this out so that they can plan accordingly.

4. That statement is made in the context of the lack of availability of IEEE DCB-capable Ethernet switches. Is there such a device that a customer can order today? If there is, let me know so that I can point it out to my readers. If not, then I stand by my earlier statement—if the components aren’t available today, then customers can’t buy and build these solutions today.

5. Again, this statement is made based on today’s available functionality. What other FCFs are available besides the Nexus 5000? Will those FCFs, today, create VE_ports between them? If so, then point these products out to me so that I can bring them to the attention of my readers. Otherwise, I will again stand by this statement—this is not an arrangement that customers can buy or build today.

6. Go back and read my corrected article and you’ll see that I retracted that statement. Certainly you can build end-to-end FCoE solutions on a single FCF today. Anything more than that just isn’t possible today, unless you know of a) FCFs that will create VE_ports between them; or b) IEEE DCB-capable Ethernet switches that will act as FCoE passthrough devices.

Again, let me re-iterate: my purpose here is to educate people on the CURRENT STATUS of actual, available FCoE products. We’re not talking about future standards, future developments, or even what current standards support that no one has bothered to implement.

Finally, I will again echo my statements regarding FCoE’s usefulness as an edge convergence technology—this use case is possible today, products are available for purchase today, and it has real value in customer’s data centers today. Selling/pushing/supporting FCoE on that basis is fine. Selling/pushing/supporting FCoE for more than that is, in my mind, a disservice to customers given the current state of products and standards implementations.

Here are some thoughts on your blog from our technical team here at Emulex.

The blog seems in many cases to struggle with the gaps of the shipping products and the completeness of the standard. We can’t speak for the current capabilities of Cisco products, but since the standard is mostly written by Cisco, what is standard seems like a good indication of what they will soon offer. To clarify what the standard supports:

1. We don’t believe FC-BB-5 restricts the types of network configurations provided as examples. It is all about the timing of product introduction (i.e., DCB compliant Ethernet switches) and implementing functionality specified by FC-BB-5 (e.g., “FCoE aware” DCB switches that create/remove ACLs to emulate the security of FC point-to-point links and FCF VE_Port to VE_Port connectivity).

2. We think that the limitation of having to go through the FCF for native FCoE Initiator to FCoE Target communication in FC-BB-5 has the potential for being a future issue, but work in FC-BB-6 appears to address this. “FCoE aware” DCB switch firmware would probably have to be enhanced to support FCoE virtual link security for direct communication between native FCoE devices.

3. We don’t think it’s a limitation in the current environment. Our understanding of the initial deployments is that the FCFs will be at the top of rack. If you have 10G Ethernet pass through modules in the blade chassis’, you shouldn’t have any intervening Ethernet switches.

4. “FCoE end devices cannot access an FCF via multi-hop paths”: Given FIP, the standard fully specifies how FCoE end devices can access an FCF via multi-hop paths. (In fact, the standard would have difficulty preventing it…even without FIP, a preconfigured FCF address would suffice.). DCB-capable intermediate switches are presumed by the standard, though it does not in fact require them..

5. “FCFs cannot access FCFs via multi-hop paths”: The is still some standardization work to be done on how to map VSANs between a Fibre Channel VSAN header and an Ethernet VLAN header. The standard strongly encourages implementations to use ONLY VLAN headers, so an implementer would not need to do the mapping. The FCFs, in fact, can prevent end devices from using the VSAN header, so the issue need not arise. If an unfortunate installation happened to mix FCFs that required VSAN headers with FCFs that supported only VLANs, they would probably have a problem. But FC-BB-5, together with other Fibre Channel standards, provides enough information to enable an FCF to map between the two methods.

6. “No Such Thing as an End-to-End FCoE Solution”: The standard fully supports end-to-end FCoE and some of the recent announcements from NetApp and Brocade have addressed some of the end-to-end questions and other storage vendors will follow…The standard fully supports end-to-end FCoE.

thanks

My response to you is similar to my response to David—the advantage of the Nexus 5000 is cable/connection/port consolidation at the edge of the network for organizations that have existing investments in FC gear. If that’s not you, then the Nexus 5000 is valuable to you only as a good 10GbE switch. Unless you’re small enough that the Nexus 5000 can be your whole solution, that is.

Does that answer your question?

FCoE is fine as long as you understand its limitations. First, FCoE is (today) an edge technology only; as I’ve stated on multiple occasions, you can’t really build an end-to-end FCoE solution of any substantial size. Not anytime soon, anyway. As an edge technology, its key redeeming factor is the fact that it reduces and simplifies the connections to servers at the edge of the network.

Second, FCoE is really only a good option for shops with an existing FC fabric. Because it is completely compatible with “traditional” FC, it’s reasonably easy to extend your existing FC fabric with FCoE at the edge, leveraging the investment you have in FC gear. If you aren’t already using FC, then there’s no need to go FCoE—just use iSCSI or NFS over 10GbE and be done with it.

I’m not sold on FCoE as the “be all end all” that so many vendors (cough, cough, Cisco) portray it to be. It’s a reasonable edge convergence solution for shops with significant FC investments. For everyone else, 10GbE will address the majority of their needs.

Does that make sense to you?