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.
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..