I spy FUD

When I see things which are blatantly FUD; I get really annoyed! And every now and then, I am going to call it! Hu posts on SVC, it's always a bad start when you dedicate an entire article to a competitors product, it can never end well.

And there is a big, whopping piece of FUD in the article and I quote Hu here!

"I asked why they were converting from Brocade to CISCO, and their answer was that they were planning ahead for FCoE. I pointed out that the SVC may work well in a FC SAN, but may have to do a lot more work to guarantee delivery of packets in a lossy network like Ethernet. The SVC will have to be reworked in order to work in a non FC environment, where packets may be dropped when the network gets congested.   Since the USP V does its virtualization in the storage controller, we would be able to convert the front end ports to FCoE ports and not do a major revision of the storage virtualization functions."

Yes, you can if you are insane run FCoE over non-DCE; you can run it over 1 GbE if you insist (I have for experimentation purposes at home) but the whole point of running FCoE is that you run it over DCE which is lossless; it implements flow control!

FCoE is fibre channel! IBM are not going to support FCoE over anything else apart from DCE! FCoE is fibre-channel! Perhaps Hu has confused iSCSI with FCoE?

So is Hu going to go back to that customer and apologise? What he should have done was said, why are you converting to Cisco to get FCoE? Brocade has a roadmap to support FCoE, you may have good reasons to go to Cisco but FCoE at this point probably should not be the driver!

Comments

[Barry Whyte]

Thanks Martin, it means more when an indie points out FUD. I'd also question several points Hu makes, and maybe the customer should be in contact with IBM.

SVC supports all the major switch vendors (past as well as present) and we have many mixed vendor SANs in our test labs and don't see issues.

However, how does this actually lead to the conclusion that SVC virtualizes the SAN? SVC manages and virtualizes DISKS... not VSANs, Zones etc

As you say... FUD... you should see the "How to Sell against SVC" presentation they have - its full of it - and so makes it really easy to go in and sell against USP because the customer soon realises that we are talking fact, and they are trying to spread fiction.

[inch]

what the deuce?

I mean really...

Someone might like to read the spec for fcoe......

[Martin G]

Inch, it's worrying; are we going to see a load of FCoE FUD from HDS?

[Etherealmind]

As in ALL FUD, there is an element of truth. Cisco will support pre-standard Data Centre Bridging (DCB). Let me explain.

IBM uses the term Converged Enhanced Ethernet (CEE) for their pre-standard DCB ethernet, and Cisco uses the term Data Centre Ethernet (DCE). Note that CEE and DCE are trademarked terms by their respective companies. DCB is the IEEE standards terms for the unfinished standards.

Cisco will have an FCoE solution using prestandard DCB with all the QoS and features needed in place long before Brocade/Foundry will. Foundry is a little bit behind here and have publicly stated that they will not have DCB support until the standards are completed.

The standards were supposed (according to Omar Sultan from Cisco) to ready this month, however, it is probably another year away.

So, if you want FCoE soon, you will have to choose Cisco and pre-standard implementation. On the other hand, waiting a year or so..... wont make any difference to most people.

Which is all a storm in a teacup, since the rise of iSCSI will probably make FC storage unviable anyway. DCB enables iSCSI very nicely and is a lot easier to use than FCoE.

[Joshua Sargent]

Martin - right on. Here is the response I posted on Hu's blog, but it's currently....awaiting moderation. =)

----

Wow, Hu…I’m not sure where to begin with this post! =)

The SVC most certainly does not sit in the middle of “two SANs.” It also definitely does not require “another SAN” just for the ports on the SVC cluster. It requires two fabrics for redundancy, just like every other storage environment, including Hitachi’s.

The SVC does not “virtualize the SAN.” It virtualizes volumes, pure and simple.

SAN switch migration with the SVC is not a problem if done correctly, and don’t take that to mean that it’s some complex operation, either! I’ve done several McData -> Brocade and McData -> Cisco, and yes, Brocade -> Cisco migrations for SVC customers without much planning and always without issue.

And who is planning to implement FCoE on a lossy Ethernet network?! This customer you reference surely knows what you have missed - that FCoE gets deployed on lossless CEE, not standard Ethernet. You suggestion that the SVC will have to be “reworked” for a non-FC environment is pure FUD.

Sorry Hu - this post is wrong in so many ways, you should honestly consider retracting the post altogether.

Josh

[Barry Whyte]

Martin, here's some more - since you allow comments on your blog - and Hu it likely to filter out both Joshua's and mine ...

---

Here we go again…

So a few points :

a) If the customer is aware of us and reading, please contact me as there should be no issue in converting between switch vendors - we support mixed SAN environments and I’m sure we can help. As Martin G point out in his “I spy FUD” post, Brocade have a great roadmap for FCoE and there is no reason to convert just for this reason alone.

b) I guess you don’t quite understand FCoE (maybe this was another ghost written post - or was this one your own?) As Martin points out FCoE is over DCE not GigE fabrics. This is fibre channel - lossless. Not iSCSI. Your suggestions that SVC can’t support FCoE easily in the future. I’d suggest that we can support it much easier than USP. Simply swap the FC PCIe card in the node with an FCoE HBA and et-voila. OK, so there are necessary software updates that will go along with that. However, if we wanted we could offer this as a field upgrade to existing hardware… would you do the same with USP?

c) I’m also struggling to understand your conclusion. How does this statement mean you can conclude (incorrectly again) that SVC virtualizes the SAN? Do we manage VSANs? Do we manage Zones? No. We virtualize DISK. Its not all just about moving luns around, maybe you should come for an SVC customer pitch and you will see its as capable as USP, and in some cases more so.

[Martin G]

Barry, probably not the place but as I haven't had a briefing on SVC futures so am not under NDA, I am going to speculate that you have actually got FCoE working in SVC in the labs?

I would also speculate that with an iSCSI offload engine, you could also do iSCSI if you felt there was the market.

I guess this is one of the beauties of building your storage devices out of modular and commodity hardware.

[Barry Whyte]

:)

[the storage anarchist]

For a so-called "Chief Technical Officer", Hu is about as out of touch with reality as one could imagine.

Earlier this week, he demonstrated his abject ignorance of the Symmetrix architecture (both V-Max AND earlier implementations); now he's trashing FCoE and SVC with abject ignorance again. And he decided to censor my feedback (as per HDS policy); I expect he won't post any feedback from SVC-supporters either.

As BarryW says, the stoopid stuff that Hu and HDS arms their sales force with really makes for fun customer presentations. We don't even have to try hard to discredit Hitachi any more - customers actually ask us to help them understand the facts on the way in the door...they know Hitachi is misleading them from the outset.

So I gotta say - stop pointing out Hu's ineptitude - he's making it easier to compete successfully against the archaic monolithic wanna-bee.

[Steven Ruby]

"...So I gotta say - stop pointing out Hu's ineptitude - he's making it easier to compete successfully against the archaic monolithic wanna-bee..."

While I agree that FUD and/or mis-representation on a Blog by a CTO is probably not the best way to spend an afternoon, your "wanna-bee" comment is blatantly ignorant. The archaic monolith has proven itself to be far from a "wanna-bee" as it pertains to enterprise storage and storage virtualization.