Cisco Blogs

Brocade’s “My Cousin Vinny” Approach to FCoE

November 24, 2010 - 0 Comments

When Brocade announced their “end-to-end native FCoE” solution, and read some of the stuff they were peddling to the trade magazines, I was reminded of the scene in “My Cousin Vinny” where Marisa Tomei’s character is put on the witness stand and challenged by the prosecution to answer a trick question (warning: link contains explicit language).

In a nutshell, in order to show that Tomei’s character doesn’t know anything about cars, the prosecutor attempts to use a lot of fancy language that sound legit but counts on people not understanding how things really work.

Attorney Trotter: Alright, alright. Now, Miss Vito, being an expert on general automotive knowledge, can you tell me what would be the correct ignition timing be on a 1955 Bel Air Chevrolet with a 327 cubic engine and a 4-barrel carburetor.

Vito (Tomei): Nobody could answer that question!

Trotter: Your Honor, I move to disqualify Miss Vito as a expert witness.

Judge Chamberlain Haller: Can you answer the question?

Vito: No. It is a trick question.

Judge Chamberlain Haller: Why is it a trick question?

Vito: ‘Cause Chevy didn’t make a 327 in ’55. The 327 didn’t come out til ’62. And it wasn’t offered in the Bel Air with the 4-barrel carburetor til ’64. However, in 1964 the correct ignition timing would be 4 degrees before top dead center.

It’s a beautiful exchange, underscoring the reliance on people to talk all jargon-y and expect people to simply nod their heads and bow to the “you know better than I do” bullying of high-tech talk.

Looking through the various announcements and reprinting of these claims by Brocade, I started to suspect that they were engaging in a bit of “My Cousin Vinny.”

After reading the article in Network Computing, I had a long talk with Mike Fratto over the phone and we started talking about what some of these terms actually mean. I’m all for having a conversation and a debate, after all, but let’s get on the same page and understand just what it is that we’re talking about. In other words, let’s define our terms better.

Part of the confusion surrounded three specific phrases:

  • Native FCoE
  • Multihop FCoE
  • End-to-End FCoE

Let’s take a look at these and understand what is meant by this, versus what Brocade is claiming.

Native FCoE

Okay, so Brocade is saying that they do “native FCoE,” meaning that you can “traverse a network with FCoE frames intact.” Thing is, it’s not clear what this means. The Brocade data sheet doesn’t reveal all that much on the issue. What’s the alternative, ripping the FCoE frames apart in flight?

The implication is that other FCoE fabrics do something to the frame that’s “non-native.”

So, let’s work this one out. How do we determine if something is “native” versus “non-native?” Perhaps we should go back to the source information of how FCoE works, the FC-BB-5 document.

Hey, it’s such a crazy idea it just might work!

So, according to the standard specification for FCoE, a frame is sent from a source (like a converged network adapter) over a lossless link to a FCF (which is a fully functional Fibre Channel switch inside an Ethernet switch). The FCF decapsulates the FCoE frame so that it can work its magic on Fibre Channel (e.g., adhering to zoning rules, using FSPF for forwarding, etc.), then re-encapsulates the frame to send it along the lossless Ethernet wire to either its destination or another FCF.

That’s what “native” FCoE is, according to the standards specification. Brocade says that it doesn’t do this.

Tell me again how Brocade sends along “native” FCoE, then?

Brocade’s datasheet mentions that it does “Native FCoE forwarding.” Again, it’s not clear what this means, but it does bring us to our next point:

Multihop FCoE

Interestingly enough, the FCoE standard does not use the word “Multihop” or “Multi-hop.”

In this case, the notion of “hops” comes from the Fibre Channel world, where there is a limitation on how many switches you can have in between a source and it’s final destination. Each switch was considered a “hop” if it changed the Domain ID, and you could only do that a limited number of times (fortunately, proper topology configurations have really meant that most deployments don’t even come close to hitting this limit).

So, take a pretty straight-forward technological term for Fibre Channel and let’s place into another context (Ethernet) and let’s see if it blows up.

Whaddya know. It doesn’t quite fit perfectly. I’m shocked, shocked I tell you!

In the Ethernet world, we don’t really have the same concept of “hops” the way we do in Fibre Channel. We talk in terms of “broadcast domains” in Layer 2 and “subnets” in Layer 3, but not really “hops.”

So, let’s mix-and-match, shall we? Hilarity ensues.

Quite frankly, the concept of “multihop” is too vague, so it’s not surprising that no two people are using it the same way, and it’s not even in the freakin’ standard to begin with. It really should be retired from use.

Why? Because it doesn’t really have any meaning. Look, from an FCoE perspective the only thing that a frame cares about is:

1) it travels on a lossless link, and
2) it gets to the next FCF (or VN_Port, the final destination).

If 1) and 2) are taken care of, that’s all FCoE cares about. It doesn’t matter what happens to the Ethernet underneath. FCoE sees the pathways between FCFs, not between the underlying Ethernet switches that may or may not be in the middle. Again, as long as 1) and 2) are covered, FCoE is happy (this is why you don’t need additional Ethernet magic, such as TRILL, in order to run FCoE over multiple switches).

Brocade is trying to say that you do need to take into account all those underlying switches. Now, there are some issues that I have with this.

Either Brocade is not using the FCFs in their switches to move FCoE from source to destination, rather they are “tunneling” through their VCS network (and, as a result, not behaving according to the “native FCoE” model they espouse), or they are using the FCFs to do “native FCoE” switch-to-switch communication according to the FC-BB-5 standard, in which case there is no technological reason why they should need VCS to do it.

You can’t have it both ways.

What it does do, though, is underscore the uselessness of “multihop” as a descriptor. If there are no FCoE switches involved, or if there’s only one FCoE switch involved, can it really be considered a “hop,” much less a “multihop?” This is a Fibre Channel term, after all.

Brocade doesn’t make the mechanics of this clear, so we shall have to wait to see how they are planning on answering this question. If it’s an Ethernet “tunnel,” from source to destination (which makes sense if they’re claiming you don’t have to decapsulate the FCoE frame until it gets to its destination), using the phrase “multihop” would be quite disingenuous.

All of these terms seem to be a bit more confusing depending on who is talking about it. Clear as mud, right?

End-to-End FCoE

So, Brocade claims that they’re “first vendor to bring end-to-end Fibre Channel over Ethernet” to the marketplace. Personally, I don’t care who is first, who is second, etc. What I do care about is what is being implied: that somehow Cisco’s products weren’t “real” FCoE, or that the Nexus 5000-series switches haven’t been able to do what we’ve been claiming they can do.

Both assertions are simply factually inaccurate.

In its simplest form, an “End to End” FCoE solution involves a host, a switch, and a target, all using FCoE. This type of “end-to-end” solution has been technically available – in products available for purchase – since late 2008. Since that time, as vendors have continued to improve their products, they have taken great pains to work together to increase the number of products and their interoperability.

Well, most vendors, at least.

The FCIA FCoE Plug-fest, held at the UNH Interoperability Labs, have been going on for several years now. From time to time, Brocade participates. But this time around, they were a no-show.

Brocade is, in effect, saying that the Cisco approach to FCoE has been “non-native,” proprietary, and that if you want “true” FCoE you need to go with their VDX solution. Given that there are several instances where other vendors are working very hard to create standards-based, interoperative technologies, Brocade’s position is, well, curious to say the least.

So they want us to believe that they’re using the “real” FCoE to accomplish end-to-end FCoE, and everyone else who works in an interoperable mode is not.

Um, okaaaaay.

Not only that, they aren’t even saying how to do that.

  • Their VDX solution uses a multipathing solution not based upon TRILL specifications, even though they’re throwing the acronym around like it’s Holy Water (TRILL is based on IS-IS, VCS is based on FSPF)
  • They cannot connect to their existing FCoE blades in their DCX switches
  • In order to go from switch to switch, you need to have a VCS solution, completely bypassing the FC-BB-5 standard
  • They claim that they don’t encap/decap FCoE frames, which is how FC-BB-5 identifies how FCoE works. How are they forwarding these frames, then?

Additional Questions

What’s also not clear is how Brocade expects its customers to incorporate this new VCS system into existing infrastructures. One of the benefits of FCoE is that it is Fibre Channel, just running on an Ethernet wire. That means that you are able to maintain all the services and features of FC (including zoning, etc.) with FCoE.

But Brocade admits that the VDX loses visibility into the FC network.

Wait. What?!

So you have a technology that can’t communicate with their existing FC SANs, can’t use the management tools for Fibre Channel, can’t use the troubleshooting tools that SAN admins are used to. Brocade promises that this is a “roadmap” feature.

Also, the VDX doesn’t have any FC ports, nor does the VDX integrate with Brocade’s other FCoE switch, the 8000.

How can this not be a completely siloed solution? All the conversations that I’ve had with customers and partners have focused around as little interruption as possible with their existing infrastructures. They don’t want to learn new tools, have new specialized staff, or increase the number of network and storage silos in their data center.

How can implementing a VCS/VDX solution be non-disruptive, with a completely new management solution, completely different hardware solution, and a non-standards compliance for both FCoE and TRILL? How can their customers evolve their data center over time, folding in legacy architectures into a new converged one and keep all of it running under a single management scheme?

All Hail Marisa Tomei

Many of these questions could be answered with some configuration and design guides as they emerge from Brocade over the up-coming months. Perhaps they do have a “bridging” plan from going from FSPF to IS-IS when using TRILL-based multipathing. Maybe they do have a standardized means for FCoE FCF-to-FCF (called a VE_Port, in FCoE jargon) which will enable true “native” FCoE solutions.

Perhaps. Maybe. Could be. Possibly.

But it certainly starts to sound as if whatever those solutions might be, it’s going to be somewhat convoluted. VCS/VDX appears to have its own ecosystem that will need to be somehow create yet-another managed environment for customers to deal with. It won’t work with Brocade’s existing environments, and when/if it does, it’s not clear how or how easy it will work.

But I gotta say, be careful when people start throwing a lot of technobabble at you in the attempt to bullying you into taking what they say at face value without questioning what they mean.

Because sometimes, just sometimes, an out-of-work hairdresser can come out of the blue and completely smoke the fancy-pants lawyer’s sleight-of-hand tactics with some plain-talking, down-to-earth, Plain English.

(Oh, and Ms. Tomei? You’re awesome. Call me.)

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.