-
Notifications
You must be signed in to change notification settings - Fork 4
/
brocade-yet-another-sdn-strategy.html
32 lines (30 loc) · 5.41 KB
/
brocade-yet-another-sdn-strategy.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
---
url: /2012/05/brocade-yet-another-sdn-strategy/
title: "Brocade: Yet Another SDN Strategy"
date: "2012-05-24T07:17:00.000+02:00"
tags: [ SDN,OpenFlow ]
---
<p>We knew Brocade has OpenFlow support in its devices <a href="http://blogs.wsj.com/digits/2011/05/03/arista-brocade-open-to-networking-apps/">for at least a year</a>; 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, <a href="http://newsroom.brocade.com/easyir/customrel.do?easyirid=74A6E71C169DEDA9&version=live&prid=890051&releasejsp=custom_184">according to their press release</a>. Let’s take a deeper look at that strategy.<!--more--></p>
<div class="separator" style="clear: both; text-align: center;"><img src="/2012/05/s200-Unicorns.png" style="border-style: none"/><br/>Please read quietly; a unicorn might<br/>occasionally cross this blog post.</div>
<h4>The obvious</h4><p>For an easy start ...</p>
<blockquote class="cite">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.</blockquote>
<p>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) <a href="/2011/11/openflow-deployment-models/">Juniper has the ability to use OpenFlow to push traffic into routing tables</a> or other logical entities.</p>
<p>How about this one?</p>
<blockquote class="cite">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.</blockquote>
<p>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.</p>
<p>Finally,</p>
<blockquote class="cite">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.</blockquote>
<p>We all know that <a href="/2011/09/nvgre-because-one-standard-just-wouldnt/">NVGRE</a>, <a href="/2011/08/finally-mac-over-ip-based-vcloud/">VXLAN</a> and <a href="/2012/03/do-we-really-need-stateless-transport/">STT</a> use IP as the transport mechanism, so what they’re effectively saying is that their products can bridge or route IP.</p>
<h4>More interesting ones</h4><p>OpenFlow runs on MLX routers today. How about OpenFlow support on VCS fabric? This is what Brocade’s strategy says about that:</p>
<blockquote class="cite">Resilient and auto-forming Ethernet fabrics will enhance SDN. Brocade VCS<span style="vertical-align: super; font-size: 80%;">®</span> Fabric technology is optimized […the usual “what is fabric”].</blockquote>
<p>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.</p>
<p>Maybe the answer lies in the following statement:</p>
<blockquote class="cite">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.</blockquote>
<p>I see two problems with this claim:</p>
<ul class="ListParagraph"><li>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.</li>
<li>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.</li>
</ul>
<p>Finally:<a name="_GoBack"></a></p>
<blockquote class="cite">Brocade is providing a single common cloud management and orchestration interface through northbound standards-based plug-ins and standards-based RESTful interfaces.</blockquote>
<p>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.</p>
<h4>Conclusion</h4><p>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 <a href="/2012/05/brocade-vcs-fabric/">interesting products</a>, so I hope to be proven wrong..</p>