Your Momma Is So Proprietary
October 20, 2011 10 Comments
Let’s talk about a very sensitive subject for both networking admins and networking vendors: The subject of proprietary technologies.
The word proprietary in most cases has a very negative connotation. Most network designers would prefer that everything be based on open standards, like OSPF and (shudder) Spanning Tree. After all, IP and Ethernet are open standards, and those along with many other open standard technologies, make the Internet and industry what it is today. But at the same time, we can be a bit hypocritical, in that we also tend to want awesome features that are often on the propriety side.
Conversely, most network vendors would love to come up with the Kernel’s Secret Recipe that makes their stuff so awesome, that no sane engineer would dare use anything else. But they also like to say they’re open, in order to allay fears that a customer might have of being “locked in”. So when vendors go after customers, you’ll hear “open” a lot. When vendors go after each other, you hear “proprietary” thrown about as an epithet. And when a vendor is accused of being proprietary, they often lash out into an epic battle of “your momma is so proprietary”.
Proprietary Bad!
So last week there was a discussion on Twitter between former Cisco employee and new Dell Force10 employee Brad Hedlund (@bradhedlund), and former Cisco employee and new Juniper employee Chistopher Hoff (@beaker). (By the way, they are both people I admire and respect.)
I believe they were talking about the different approaches their respective companies were taking solve the evolving needs of modern data centers. Juniper’s solution is QFabric, while Dell Force 10 is going the NVGRE/VXLAN/OpenFlow route. Brad cited QFabric as proprietary, and Christopher Hoff countered that Cisco’s FEX is also proprietary. And while true, something about that bothered me a bit.
QFabric and FEX are both proprietary, but the effect of the proprietary is very different. With QFabric, you can build a huge network fabric, without worrying about spanning-tree, and have one control plane for a whole mesh of switches. With FEX, you can plug what looks like a switch into a Nexus 5000 or Nexus 7000, and that switch looks like a line card on the 5000/7000. FEX affects the next hop. QFabric can affect your entire data center.
FEX is pretty limited, and honestly I think it’s fairly inconsequential in terms of its proprietariness. You can use FEX, or just hang another Cisco switch off a 5K/7K, like a Nexus 3000 (with its merchant silicon) or even an Arista or Juniper box. Even if you use FEX, the effect is limited to one switch hop away. How concerned would a designer be about the effect of proprietary FEX? Pretty much it would have little effect.
The effect of QFabric, however, is potentially far more wide ranging.
That’s no moon, that’s a data center fabric
From the Packet Pushers episode (episode 51) on QFabric, Abner Germanow talks about 500 10 Gigabit Ethernet port where QFabric makes sense, which is a pretty large investment. If you figure roughly $2,000 a port, that would make it a $1,000,000 decision. If you order enough FEX/Nexus switches, you can spend that much, but you can go step by step and back out if you want.
With the proprietary versus open debate, it’s quite understandable that Juniper is very sensitive to the word “proprietary”. However, it’s tough to classify QFabric as anything but, as Ivan Pepelnjak says, “completely proprietary“.
Right now there are several open standards, such as TRILL, SPB, OpenFlow, VXLAN, FCoE, NVGRE and others looking to solve many of the same data center problems that QFabric looks to solve. And from the looks of it Juniper has been rather dismissive of some of the open fabric standard technologies, such as the much discussed “Why TRILL Won’t Work For The Data Center” argument (requires registration, fuck you TechTarget). Juniper is also taking a wait-and-see approach to VXLAN.
Even so, I don’t think Juniper should care if people call it proprietary. Yes, it’s proprietary. And yes, the effect of this proprietary-ness is huge compared to Cisco’s FEX because it affects more of the data center. But that’s a good thing.
Right now, because these open standards are mostly brand-spanking new, and no one is bat-shit crazy enough to build a multi-vendor fabric based on these new standards.
OK, maybe there is someone is crazy enough to build a multi-vendor Ethernet fabric
So QFabric has the advantage there, since even open standards are likely to be vendor-locked for now. And QFabric is a bit more mature than most of the new standards, in that it’s at least impelemtend and released. (Despite the terrible, and I mean just awful PR move bashing Juniper. Seriously, Cisco, that shit reeks sophomoric desperation. I feel cheep even linking it.)
What we do have to consider, however, is that in time the interoperability and maturity situation will be different, as it is for mature open standards today. It’s very common to have multi-vendor 802.1Q, OSPF, IS-IS, BGP, and spanning-tree deployments, without thinking twice about it. There will likely be a day when whatever new standards we’re dealing with now succeed and evolve to the point where we wouldn’t think twice about building say a TRILL fabric with multiple vendors like we do now with spanning-tree.
So QFabric is proprietary, and is not going to play well with others. That doesn’t discount it as a solution, but it is a serious consideration, more so than something like proprietary FEX. Proprietary has its advantages, and disadvantages, and the effect can be substantial or inconsequential, all factors to consider. I won’t even hazard a guess at this point as to how it’s going to play out, but like a good twitter battle, I’m going to enjoy watching.
The Data Center Overlords 
I don’t see how QFabric’s proprietary-ness is any worse than the FEX architecture. You say the QFabric is worse because it touches more of the data center. However, If you built a FEX fabric equal in size to a QFabric would they not touch the same amount of data center? The only real difference is that the QFabric is a larger initial investment, while the FEX architecture can be initially rolled out with a single 5500 and FEX. You also say that QFabric won’t play well with others, and in terms of the fabric itself you’re absolutely right, BUT a Cisco FEX won’t play any better. However they both play fine at the edge of their fabrics.
The point I’d like to make here is that proprietary is proprietary is proprietary. Pick your poison and drink up. There is no lesser of 2 evils, only a cheaper initial sin.
I didn’t say QFabric was worse, only further reaching, and thus required more consideration.
Why would I care that FEX doesn’t play with others? It’s just one Cisco switch to another. Whatever you plug into either of those switches can be any vendor, or you can just not use FEX at all, and hang a 3000 off a 5000, or a Juniper ToR off a 5000. FEX can *only* extend one possible layer. You can’t build a mesh with it.
Honestly, I don’t find FEX all that useful for switches. The real place where FEX is interesting is in Cisco’s blade system. And blade systems, whether they’re from HP, IBM, Cisco, Dell, or whomever, is the land of proprietary (although hell froze over and HP is reselling a Cisco FEX to plug into their C-series chassis).
Right now anything beyond STP and OSPF is going to be de-facto proprietary anyway. The only difference between QFabric and the open standards is the open standards might be truly interopable in the future.
In networking, we’re all stepping in proprietary all the time. It’s not necessarily a bad thing (although it can be, Token-Ring), and it certainly isn’t binary.
“In networking, we’re all stepping in proprietary all the time.”
Amen.
Great write-up by the way.
Pingback: Multi-Hop FCoE Is Not Ready For Prime Time (Yet) – @SFoskett – Stephen Foskett, Pack Rat
The Cisco N2K fabric extenders (FEX) don’t compare to Juniper QFabric.
In a design, you may only use N2Ks for out of band management traffic or not at all. I believe they can be useful for cerain applications but since they are not switches, they don’t compare to QFX3500s.
While I agree that vendor-A-bashing-vendor-B advertising campaigns are generally useless, I do feel inclined to point out that Cisco going after Juniper is hardly novel. Juniper paid a cartoonist for 5 years to write cartoons that very often attacked Cisco by name. Anyone remember these?
http://www.ashimmy.com/2009/02/they-fired-the-juniper-cartoon-guy.html
Personally I’d prefer that vendors spend more time discussing what problems their products solve rather than hitting out at the the competition’s (perceived or real) weaknesses. On the other hand, I’d say the same about political ads but the analysts all say negative campaign ads actually work. Sigh.
Vendor-on-vendor violence is a time honored tradition, and I’m not saying it’s not amusing, effective, or worthwhile. The low road is sometimes a fun place to be, and sometimes gets you where you need to go.
But Cisco’s execution on that particular front was abysmal. For one, Cisco has the dominant market position. For them to be bashing a competitor like Juniper shows they’re scared (or their marketing department is looking for something to do). And that’s not a burn in a power point slide, either (which would be appropriate) that’s a full on marketing (6 figures most likely) push.
FEX extends as far as you want it. QFabric also extends are far as you want it to as well.
Trying to say say that FEX is “less-propritary” or “less-evil” is asinine.
Qfabric solves a lot more problems than FEX does and it’s scale is larger but if you want a Qfabric design that old extends to your private cloud blade racks and run EX or even F10 or Cisco switches to the rest of the data center it is COMPLETELY valid to do so.
Problem with the FEX on the other hand is it doesn’t/can’t scale since it’s a centralized forwarding model. Remember how chassis switches evolved. Centralized forwarding –> distributed forwarding. FEX is centralized forwarding. QFabric is the next-generation with distributed forwarding.
I do think that OF and other technologies will solve a lot of these issue in the future, but they just aren’t ready for main stream, just buy it and plug it in, deployments yet. In the mean time there is Qfabric.
QFabric’s propritaryness comes from one thing: predictability. If you control the architecture and the protocol then you can make claims like 5 usec from any node to any node. If you control which nodes can be plugged into the fabric then you know exactly the size of the FIB, the size of the MAC table, how many QoS queues, etc. You can do advanced features like entire DC VOQ.
It will take awhile for a technology like VXLAN (which I don’t think solves even a quarter of the requirements for DC “fabric”) and Openflow to bake out. When they are fully baked I will be very exicted to see where networking is going (and there is no reason why QFabric couldn’t be included there).
The key part here is that QFabric DOES play well with others. It’s not like you are giving up your network to EIGRP and despite QFabric’s proprietary fabric there is very little vendor lockin.
“And QFabric is a bit more mature than most of the new standards, in that it’s at least impelemtend and released.”
Really?? Brocade VCS has been shipping since September 2010 and there are a lot of customer implementations. Cisco FabricPath has been out for a while even if it only just came out for the Nx5500. QFabric just came out. How exactly is QFabric mature?
I think he’s comparing QFabric to standards such as VXLAN, TRILL, or SPB, which have seen very little real-world implementation. VCS and FabricPath have been publicly available longer than QFabric, but QFabric has been running in trial customers for some time. It’s just recently been released to the public.