Howver, the point that FC remains the same protocol (with all its flaws and strengths) is true. Zones LUNS etc are all identical configuration and concepts and remain unchanged.

The real art is building the Ethernet fabric to be lossless and low latency. But once this is done, Storage over IP (NFS or iSCSI) becomes a winning technology because it solves the weaknesses of all storage protocols.

Chris is right. FC is now a legacy protocol, FCoE is the migration path to IP Storage. Choose NFS or iSCSI or something yet to come but FC isn’t likely to survive for long.

Chris

Great and comprehensive response. Despite my negativity towards FCoE, I am looking forward to seeing how the technology develops and where it fits in the greater scheme of things.

Chris

Thanks for taking the time to make the post. I attempted to read the vast number of comments but felt the direction of many of those responses weren’t addressing your original questions. If they were I apologize to those who have pointed them out.

* FCoE needs new switches
Absolutely correct, their are however fundamental advantages to the evolution of technology. The concept is to make things better and the new lossless switches to support data center Ethernet and thus transport FCoE are designed in kind to evolve technology and continue to push the bar higher for technology and ultimately the benefit of consumers.

* FCoE needs new HBA adaptors
I wouldn’t call an FCoE CNA an HBA, it is far from it. I have built some very large data centers in the last 5 years and one thing is sure that we are increasing the quantity of cables and interfaces that we are jamming into servers. All of those interfaces are not being used efficiently and that makes it troublesome to get into the server to perform any maintenance and a nightmare to troubleshoot if someone moves a cable.
So yes, the technology requires new interfaces but in the spirit of consolidation. No one has ever said “hey I get the value of VMware, but it requires me to buy new bigger servers to consolidate all my physical machines on, I don’t want to do that.” If they did well they probably aren’t leading the strategy for technology in that company.

* FCoE operates at 10Gb/s – do all your servers need this performance?
This is probably my biggest gripe with the technology at this point. Everyone assumes that it operates at 10Gbps and they could not be more wrong. All of the HBAs that are being sold today almost exclusively run the FCoE portion of the adapter at a max speed of 4Gbps. The entire value of FCoE today is consolidation not performance increase. The future is eventually see hardware asics on the HBAs which run at higher speeds or the promise of hardware assisted initiators is being designed into a few offerings. Read the fine print on those CNAs out there, they run at 4Gbps for FCoE traffic. 10GBps for the IP stack (which is separate –read on)

* FCoE requires changes to the IP standards to implement; to handle congestion
This is my biggest gripe with the lack of education on the protocol. FCoE has absolutely zero nothing nodda to do with IP. FCoE doesn’t even use the traditional Ethernet forwarding mechanisms. The mechanism for forwarding a FCoE frame on a Ethernet fabric is through the use of traditional zoning as with traditional fibre channel SAN networks. This is what makes the two technologies so complementary. You can sit a SAN person in front of the tools being released by Cisco to deploy FCoE environments and if they were able to zone a MDS, they can zone a Nexus 5000 FCoE switch.

* FCoE will require additional thinking and planning to bring two different network architectures together
See last point, one of the reasons why the standard has taken so long to adopt is because of the incredible conversations that have went on to make sure that management security and every other element of traditional FC fabrics are entirely compatible with FCoE.

* FCoE will require bringing together two different operating teams
There is some truth to this but that combination is already occurring in most organizations that are small to medium size, which account for a majority of the businesses on the planet. Those few large organizations (by comparison) which have dedicated SAN teams and Network teams will be required to collaborate together. However, because FCoE does not use the Ethernet forwarding mechanisms, it does not use IP and it only operates within the data center on the same layer 2 segment, the only thing the san team will be required to do is make sure there is link light and the zone is configured properly.

* How will FCoE handle traffic prioritization?
This again is built into the Data Center Ethernet Technology through the use of a few new technologies to the Ethernet world.

The first is lossless Ethernet; this is the ability to provide a lossless service to a traffic class. Thus when the switch is configured, you will state that FCoE is granted the lossless service. What this ensures is that any FCoE frame that arrives at a switch or host interfaces will be processed prior to that of any other type of frame. Those other frames will be buffered and ultimately dropped if they cannot be processed. The reason why that is okay is because those other protocols will likely have a higher layer capability of dealing with retransmissions. FC traffic does not like discarded frames, thus the requirement for a lossless service was needed and thus created.

The remaining are 802.1Qbb Priority Based Flow Control
802.1Qaz Class of Service Bandwidth Management
802.1Qau Congestion Management
L2 Multi-Path

Of the above L2 multi-path is the one that is not completely baked yet as this brings FC excellent ability to multipath to Ethernet which has the evil spanning-tree lurking to block redundant links from the forwarding path.

* FCoE will add additional complications to change control; data network changes will be even more impactful
This is not a true statement. The same process that one goes through today to schedule and ultimately change a zone will apply with FCoE tomorrow. Any change by the network team to routing or ip addresses etc… will have ZERO impact on FCoE traffic. The only thing that will impact FCoE traffic is the physical shutdown of the switch or port or removal of the cable. There is no dependency on the Ethernet forwarding fabric thus there are no further complications than what exists today.

* FCoE will require additional training and consultants’ cost (difficult for me to include this one)
FCoE will require everyone to grasp the fact that everything is running on a single cable, yet the skills that were used to zone a SAN will be used in the FCoE world, they haven’t changed.

I actually blogged about this very topic a few weeks ago.

http://ethernetstorageguy.blogspot.com/2009/03/fcoe-wow-is-there-confusion-on-this-out.html

I totally agree with you. This is Cisco’s way of getting FC under their control because they couldn’t beat Brocade head to head. All the other vendors have jumped on board to simply increase their margins for a bit and make people purchase new equipment or to keep up.

There is no technical reason that anyone can give today for a customer moving from FC to FCoE. Just like they couldn’t give any technical reason for a customer to move from FC to iSCSI.

Quite the interesting thread you have going here.

As far as the software FCoE stack, I am not sure you can simply dismiss it because it is open source–however, that is a whole different debate that I don’t think we need to get into here. At the very least, it gives you the oppty to try out FCoE with minimal investment in your test and dev environment.

As far as the cost savings go, I think you are underestimating the cost savings–it is more than just a couple of HBAs–the capex and opex costs to support multiple parallel network is significant when scales across hundreds or thousands of servers. We have an ROI calculator on cisco.com that you can use to understand the cost impact–I can provide an URL if you want.

Why is FC over Ethernet winning our over IP over FC. First, the economics of Ethernet are more compelling, second layering IP on top of FC is adding a lost of cost and complexity without commensurate benefits.

As far as the standard itself, FCoE is governed by the FC-BB-5 working group under the T11 committee within INCITIS. The standard passed a letter ballot by a vote of 29-4, which represented broad agreement across the industry (Dell, HP and IBM voted “yes”, while Sun abstained). The standard is in the home stretch for completion.

As for the question of protocols, I still say you will see a mix of FC, iSCSI and FCoE in the enterprise. For a mid market customer with no FC in place, iSCSI makes a lot of sense. On the other hand a large enterprise customer with a significant FC SAN investment, FCoE makes a lot of sense–it allows convergence at the server access layer, where there is the greatest oppty for cost savings, while not being disruptive to the existing FC SAN, which is probably happily chugging along.

Finally, as @ced points out, this is really still a discussion about transport–the need to architect, implement, and operate the storage environment still remains in place.

I have a couple of URLs I could post that might be helpful–let me know if you are OK with this and I will add them in a subsequent comment.

Regards,

Omar