Brocade: Yet Another SDN Strategy
We knew Brocade has OpenFlow support in its devices for at least a year; now it’s official: OpenFlow is supported on its MLX-series routers. But wait, there’s more: that’s just the first step in Brocade’s long-term SDN strategy, according to their press release. Let’s take a deeper look at that strategy.
Please read quietly; a unicorn might
occasionally cross this blog post.
For an easy start ...
Brocade will be the industry's first network vendor to deliver OpenFlow in hybrid mode. With Brocade Hybrid Mode, customers can simultaneously deploy traditional Layer 2/3 forwarding with OpenFlow.
Ships-in-the-night mode (where certain ports use OpenFlow and others use traditional forwarding) has always been a pretty common feature (otherwise it would be impossible to deploy OpenFlow pilots on semi-production gear), and (as I was writing almost nine months ago) Juniper has the ability to use OpenFlow to push traffic into routing tables or other logical entities.
How about this one?
Specifically, Brocade is delivering industry-standard OpenFlow for Layer 2/3 forwarding and the Brocade OpenScript™ engine for Layer 4/7 switching to unlock the network to increase service velocity for highly customized services.
OpenFlow protocol already allows you to specify matching on a 12-tuple (which includes, among other things, the traditional source and destination TCP/UDP ports), so L2-4 forwarding is inherent to OpenFlow. Were they trying to admit that MLX doesn’t support full 12-tuple flows but only lookups on source and destination MAC/IP addresses or was it just a MLX-versus-ADX positioning exercise? It was more probably the latter, but still it doesn’t sound nice.
Brocade products have a tunnel technology-agnostic design that supports overlay technologies such as Network Virtualization using Generic Routing Encapsulation (NVGRE), STT, and VXLAN as well as emerging standards.
We all know that NVGRE, VXLAN and STT use IP as the transport mechanism, so what they’re effectively saying is that their products can bridge or route IP.
More interesting ones
OpenFlow runs on MLX routers today. How about OpenFlow support on VCS fabric? This is what Brocade’s strategy says about that:
Resilient and auto-forming Ethernet fabrics will enhance SDN. Brocade VCS® Fabric technology is optimized […the usual “what is fabric”].
Reading the rest of their strategy, I understood Brocade considers SDN being tightly coupled with OpenFlow. I would love to see how VCS fabric will enhance OpenFlow; after all, the whole idea of OpenFlow is to remove the intelligence from the switches and concentrate it in a central controller.
Maybe the answer lies in the following statement:
In addition, multiple switches that make up the fabric can be managed and programmed as one logical switch, dramatically reducing operational complexity and improving SDN controller scalability.
I see two problems with this claim:
- Apart from Automatic Migration of Port Profiles (AMPP), VCS fabric is still not “managed and programmed as one logical switch” even though this feature was promised ~18 months ago.
- Inserting OpenFlow flows from SDN controller into a virtual switch will be a highly interesting exercise. I could imagine it being done with MPLS (because MPLS gives you virtual-circuit-like capabilities), but not exactly how Brocade VCS fabric could do it with TRILL. I’m anxiously looking forward to this particular unicorn turning into a real-life beast.
Brocade is providing a single common cloud management and orchestration interface through northbound standards-based plug-ins and standards-based RESTful interfaces.
I would love to know what those standards are; lots of us would have an easier life if the cloud management and orchestration interfaces would be standardized.
It’s nice to see OpenFlow support on yet another platform and MLX is one of the few (if not the first) OpenFlow platforms with 100 GE interfaces ... but I fail to see anything exciting in the rest of the strategy. However, I know Brocade has great engineers (who will likely get upset halfway down this blog post) and interesting products, so I hope to be proven wrong..
Full disclosure, I do work for Brocade.
For some additional color on Brocade's "SDN Strategy", see the following:
and this on what the buzz words don't mean.
We do have "yet another" SDN strategy. (Perhaps having a strategy is better than having none?)
As a strategy, it tells a story of how point technologies such as OpenFlow, OpenStack, VCS Fabric, etc., could be combined to simplify large scale networks. And, IMHO, an important goal of network architecture is to enable a network that is simple. But, as Scott Shenker points out, the current network engineeing paradigm worships complexity and the networking gurus who can read the entrails and advise the business. This isn't desirable, scalable nor profitable. Thus, fundamental changes including the idea of the control plane as a programming abstraction, instead of a protocol "mashup", might prove promising.
We agree. Hence our investment, our strategy and delivery products that support that strategy.
As is always the case in the practical world (sadly, the one without unicorns and their tears ;-)) real engineering and design takes real time and real money. So, functions, features and products aren't available all at once. Hence, the value of talking about our strategy is so customers have an appreciation of what our views are and the direction we are heading. Details maybe lacking, but they become apparent as products are deliverd, so "all good things in their time."
AFAIK, the MLX is indeed the first 100GE capable router with OpenFlow support. And, we use an OpenFlow controller we didn't write ourselves. That demonstrates that "proprietary" ASICs don't limit companies like Brocade from delilvering OpenFlow value to those of our customers who need it. Interestingly enough, the ones who need 100GE also need OpenFlow.