Interoperate or Die: On Brocade & Open, Standards-Based SDN


During a recent briefing with Brocade about the 2.0 release of the Brocade SDN Controller product, I took the opportunity to clarify their commitment to openness in the software defined networking world. My concern is this. I see a great deal of activity in the SDN space, but I don’t see as much settling as I’d like to see just yet. Most solutions are proprietary. There are a lot of ideas that are vendor specific. There are still many competing standards (or wannabe standards) that do the similar things to one another.

To get past all the chest thumping and whitepapers that continue on after five years, I believe the industry needs to rally around a smaller number of standards, move to a predictable way of accomplishing SDN, and give customers SDN frameworks that don’t lock them into a vertically integrated vendor stack. While I doubt we’ll ever get away from vendor lock-in completely, the networking industry can certainly put products out there that minimize complex dependencies.

At least, I hope it can. And I think that’s where Brocade, for one, is positioning itself when it comes to SDN. Adhere to standards. Minimize dependencies. At least that’s the impression I get. Here’s why.

Is multi-vendor support important to a software-defined network?

In a survey performed by Heavy Reading, Brocade reports that,

Ninety percent of respondents … said that a truly open SDN controller with support for multiple vendors is an essential or important factor in SDN deployment plans.

I asked Brocade to articulate their thoughts on this. Does “multiple vendors” just mean switch vendors, or multiple vendors up and down the stack (switching, ADC, security)?

Their response was “all of the above.” If a device speaks one of the southbound protocols supported by the Brocade SDN Controller, then the device is supported. Over time, there will be an official Brocade list of sorts saying, “we tested these devices and they work.” When a device doesn’t work as expected, Brocade will take responsibility to resolve the issue by sorting out where communication is breaking down.

Therefore, Brocade assumes standards compliance on both their part and on the part of the device they are communicating with. In addition, Brocade will take the lead if there’s a problem. Implicitly, they’ll sort out who’s not compliant with the standard and drive a resolution.

What SDN standards?

But what do we mean by SDN standards? Well, that is a complex issue, and one that could cause a bit of controversy depending on who’s reading the question and formulating the answer. But I’ll answer the question in our context here. The answer is simple enough.

OpenFlow. No, OpenFlow doesn’t do everything for everyone as an SDN southbound protocol (and there are other southbound protocols). But it certainly does a lot. It’s certainly in use in many contexts. Development continues. And there are well-defined standards to be adhered here, as well as a conformance program. In my conversations with Brocade over the last couple of years, I believe OpenFlow to be the most important SDN standard in their point of view. Yes, there are other protocols worth discussing as SDN standards (and that Brocade supports), but OpenFlow is the crux in a Brocade context.

Privileged citizens?

I also asked Brocade if their hardware receives any special treatment when being managed by the Brocade SDN Controller. The context is that most management platforms issued by networking vendors work best with that networking vendor’s hardware, despite being marketed as multi-vendor. Of course, those were the bad old days of vast SNMP MIB branches with obscure (and badly documented) OIDs. So, you’d expect those sorts of management platforms to work best with in-house hardware, assuming relatively easy access to the developers that built the MIBs. And screw the competitors’ hardware, because who has the time to build those sorts of integrations?

With that backdrop, what about Brocade, SDN controllers, and OpenFlow? Do Brocade switches and NFV appliances get special treatment in the Brocade SDN Controller? The answer is…not exactly. The fact is that when a device conforms to the OpenFlow 1.3 specification, then it does. Whether that switch is branded Brocade or something else, it doesn’t particularly matter to Brocade.

That said, Brocade can provide integrations with their own gear that don’t run OpenFlow — for example, there is an EMS app for the Brocade SDN Controller that manages Brocade Vyatta vRouters. Why a special EMS app? The vRouter needs a special NETCONF configuration to be gracefully managed. But that’s more of a gear problem as opposed to a philosophical one, and the same problem any vendor might have that’s not OpenFlow conformant.

Portable SDN applications?

Another question I asked Brocade about was the portability of their SDN applications. Brocade’s SDN Controller is, more or less, OpenDaylight. Brocade developers work in the context of ODL, and are major contributors to the project. The Brocade SDN Controller major releases are done in tandem with the ODL major releases. Therefore, Brocade applications are portable to the OpenDaylight controller.

So, what do I mean that the Brocade SDN Controller is “more or less” OpenDaylight? Well, ODL is a controller made up of several different projects. Brocade might not use every project that’s a part of the official ODL releases. And, it’s possible they’ll add some of their own projects that don’t end up as part of the ODL package. For example, in the 2.0 release announced on 15-September-2015, Brocade has deprecated the ODL-standard DLUX UI, replacing it with a custom Brocade-branded UI.

Why the change? Brocade believes their own UI (built using react.js) gives them more flexibility to deliver other UI-intensive applications. To wit, they’ve released Topology Manager and Flow Manager applications that leverage the Brocade-branded UI. Are Topology Manager and Flow Manager portable to other ODL controllers? No, due to the UI dependency.

So…is Brocade committed to open, standards-based SDN?

I think Brocade is committed to this open, standard-based path. But let’s not kid ourselves — this isn’t about altruism. Brocade doesn’t have a lot of market share in the Ethernet switching business, and the fiber channel business won’t last forever. SDN is a long-term play, and going the “open” route appeals to existing and potential customers who aren’t entirely pleased with the more locked-in road Cisco, Juniper, or HP might want to take them down, at least so far.

My view is that Brocade is doing everything it can to drive software defined networking down a predictable, standards-oriented path. They have a business to run. They will use sales of the Brocade SDN Controller to drive hardware sales and vice-versa.

Even so, there’s a difference in selling a vendor-branded SDN controller that only works with that same vendor’s hardware and selling an SDN controller that genuinely will work with other vendors’ hardware. Brocade is betting big on open, standards-based SDN playing into their hand in the long term.

Interoperate or die.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.



Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.