Converged Networks vs Mononetworks
In 1950 Time magazine published an article about an apocryphal story about former U.S. Senator (D-Florida) George Smathers:
According to the yarn, Smathers had a little speech for cracker voters, who were presumed not to know what the words meant except that they must be something bad. The speech went like this: “Are you aware that [opponent] Claude Pepper is known all over Washington as a shameless extrovert? Not only that, but this man is reliably reported to practice nepotism with his sister-in-law, and he has a sister who was once a thespian in wicked New York. Worst of all, it is an established fact that Mr. Pepper before his marriage habitually practiced celibacy.”
Brilliant! If you were in Pepper’s shoes, would you deny these types of charges? How can you face people who look at you with suspicion when not only are the accusations true, but can actually be the right things to do? (especially in 1950)
I love that story. Even though it’s false (Smathers reputedly offered $10,000 to anyone who could prove that he said it, an offer that went unclaimed up to his death) it provides a cautionary tale of just how someone can use an audience’s confusion against their opponents and yet still be telling the truth at the same time.
What does this have to do with Converged Networks?
As I read through some of the recent blogs and articles the past few weeks, I’ve been noticing a more-and-more obvious attempt to do this very thing of the Smathers Principle. A lot of the criticism that has been levied against Cisco’s true Multihop FCoE has been done this way: there are truths to the criticism, but they rely on the audience “not to know what the words mean except that they must be something bad.”
Cisco has been talking about Converged Networks for a long time now – so much so that it is often accused of “going it alone.” Even a quick cursory glance at the list of vendors working on interoperability shows it’s obvious that there is an industry-wide initiative to provide customers with an Ethernet-based roadmap.
But what does “Converged Networks” actually mean?
See, from Cisco’s perspective, it’s about the goal of converging LAN and SAN onto a consolidated network infrastructure in toto.
“Yeah, yeah, yeah,” I hear you say. “Blah blah blah, FCoE. I get it.”
But think about this for a second. This means that we’re not just talking protocol frames, and not just talking traffic. We’re talking about also taking the design principles, best practices, and tried-and-true methodologies that have made both LANs and SANs successful.
Let me repeat: One of the things that converged networks must do is preserve the best practices of both LAN and SAN designs! Otherwise you’re not converging, you’re annexing!
How do you do this? You ensure that your LAN designs can have the high-availability designs that come from any-to-any connectivity, flow control, and forwarding, and SAN designs maintain the SAN A/B separation, high availability, and flow control that they require.
To do anything else is to subordinate one type of traffic to another.
Some people are completely happy with the idea of subordinating their lesser-understood networking brethren to an “also-ran”.
Take, for instance, this question taken from the blog “This is not the convergence you were looking for:”
More recently, Fibre Channel switch vendors have come up with another solution. Why not run a full Fibre Channel stack on every FCoE switch and make each hop a Fibre Channel Forwarder (FCF) obviating the need for Ethernet to provide the flow control and routing functions? This actually sounds like a very simple idea and addresses the problem of deploying multi-hop FCoE networks without the need for QCN.
But the question has to be asked: Is this really convergence? [Emphasis in the original]
Yes, Virginia, this really is convergence. The reason for it is simple: we are allowing the SAN designs to remain implemented as they have always been.
Mr. Munjal, the author of the blog above, continues to work the “also-ran” angle:
If Fibre Channel switch vendors say you need a layer 3 protocol to reliably transport storage over Ethernet, can we at least choose IP as that layer 3 protocol and maybe use iSCSI instead?
See what I mean? According to Mr. Munjal, storage admins should simply forget all of the Fibre Channel design practices they’ve used for years to get reliable, high-quality service out of their storage networks. (I’m also unsure about the dig at FC vendors: it’s also not clear how someone might run any storage on Ethernet without it being at least Layer 3, but I guess that’s not important right now).
Sit down, shut up, you’ll get your storage when it gets there. And you’ll like it.
By having a fully functional FCF (or FCoE NPV capability), as I’ve described in detail before, the SAN admin gets exactly what he’s been used to: full visibility into his storage fabric at every stage of the network, with complete access to troubleshooting tools.
There are no black boxes that blind them to what’s going on with their FC traffic, security implementations are still in place, and there is no reliance on Ethernet-based forwarding mechanisms to replace what they’ve been doing. In other words, true Converged Networks means you do not have to sacrifice anything. You do not get punished just because you move to another transport mechanism.
So yes, Converged Networks actually do mean that you have to treat both networks equally; you can’t simply say that what’s good enough or appropriate for LAN designs will automatically transfer over to SAN designs. To do so is the height of arrogance and disrespect for years of best practice SAN design.
Can you actually say that you have a converged network if you are not accommodating the design principles for both networks? There seems to be this push for what I call a “Mononetwork:”
When you advocate a goal to subsume the needs and requirements of one network in favor of another, you’re pushing a Mononetwork.
When you try to treat an entire industry’s best practices as insignificant because your proposed solution is “good enough” (to you), you’re pushing a Mononetwork.
When you hope that you are getting the majority of the functionality without actually having to take into account the needs of the other, you’re pushing a Mononetwork.
In my experience those who are the most vocal against FCoE are those who have little respect for, or grasp of, the nature of resilient storage networks.
To them, a converged network isn’t really converged. It’s simply an Ethernet network that oh-by-the-way provides you access to FC storage. There is nothing wrong, they say, with simply borrowing some of the aspects of storage connectivity, but otherwise ignoring the fact that storage networking is actually more than just a network of storage connections.
They don’t care about SAN isolation/separation. They don’t care about maintaining Fibre Channel best practices, high availability, high performance, or troubleshooting mechanisms. They don’t care about offering customers implementation and deployment choices. While they simultaneously recommend their own rip-and-replace solution, they attempt to use this Smathers Principle to indicate that Cisco is somehow doing a Bad Thing™ by keeping consistency across LAN and SAN designs – both past, present and future.
Let me give you another example. I’m afraid I’ve lost the source so I cannot properly cite the original, but someone forwarded me this particular criticism (different vendor than above):
Cisco announced their ability to transport FCoE packets across a Nexus 7000. However that ability cannot use the fabricpath [sic] protocol. Thus they offer a unified fabric for L2 Ethernet traffic, a different fabric for FCoE traffic, and yet another distinct fabric for L3 traffic. It is not clear what part of the term “unified” they do not understand.
It’s difficult to know where to begin with this. The Smathers Principle is in full effect here, as this little bit of word mis-direction is true (up until the last sentence, that is, and I’m not really sure what exactly they mean by a L3 fabric to be honest, but I’m willing to give them the benefit of the doubt for the sake of argument).
Apparently our anonymous author is mistaken the notion of “unified” in the same way as Mr. Munjal, albeit with a different execution. That is to say, yes, these statements are true for the most part, but it’s said in a way that is supposed to make people think this is a bad thing.
We maintain that it is important to keep the OSI Layers separate (they are separated on the OSI model for a reason). It’s not clear what benefit the author believes Cisco will gain by breaking years of well-understood design principles and known interoperability.
The key thing to “unified,” or “converged,” is the fact that you can do all of these fabrics using the same equipment and infrastructure.
Doh! Wait a minute! You’re telling me you can unify these different topology scenarios onto one physical infrastructure? You mean that it’s completely interoperable with the exact same design principles and best practices that have become well-understood in both the LAN and SAN industries?
Sorry, my friend. It does not appear that Cisco is the one who has a misunderstanding of what the phrase “unified” or “converged” means.
If you don’t take the design principles of both network infrastructures you cannot claim to have a converged network. At best, you are merely subordinating one for the sake of the other. This is not converged networking, this is creating a Mononetwork with the hope that you are getting the majority of the functionality without actually having to take into account the needs of the other.
If we take the lesson from Smathers’ legend, we can see that we need to understand more than just the fact that it’s said in a manner that implies that it must be bad, or undesirable. Most people I know what to take what they have and move forward, not replace the systems they have in place with a Mononetwork that merely approximates the end result but ignores the rest.
The key, as I’ve said before, is to provide choice without forcing people to choose. That is what Converged Networks do, and Mononetworks don’t.Tags: