Category: SDN

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.

Google unveiled some details of its new internal network at Open Networking Summit in April and predictably the industry press and OpenFlow pundits exploded with the “this is the end of the networking as we know it” glee. Unfortunately I haven’t seen a single serious technical analysis of what it is they’re actually doing and how different their new network is from what we have today.

The blogosphere has been full of OpenFlow-related articles recently (no wonder - there was Open Networking Summit in Santa Clara), so here's a special OpenFlow edition of interesting links

Let's start with my good friend Greg Ferro. I'm so glad to see him returning back from a sabbatical at OpenFlow Kool-Aid lake. His latest articles are a must-read: OpenFlow might lower CapEx while SDN will increase OpEx and OpenFlow doesn’t undermine Vendors even though it changes everything. We're perfectly aligned, which will make our discussions way less interesting, but I'm glad I'm not the only conservative in the town.

Matt Stone sent me a great set of questions about the emerging Data Center technologies (the headline is also his, not mine) together with an interesting observation “it seems as though there is a lot of reinventing the wheel going on”. Sure is – read Doug Gourlay’s OpenFlow article for a skeptical insider view. Here's a lovely tidbit:

So every few years the networking industry invents some new term whose primary purpose is to galvanize the thinking of IT purchasers, give them a new rallying cry to generate budget, hopefully drive some refresh of the installed base so us vendor folks can make our quarter bookings targets.

But I’m digressing, let’s focus on Matt’s questions. Here are the first few.

HP has recently released OpenFlow support on a few more switches and some people think it’s a big deal. It just might be if you’re a researcher with limited grant budget (which seems to be one of the major OpenFlow use cases today); for everyone else, it’s a meh. Lacking a commercial-grade OpenFlow controller supported by HP (or at least tested with HP switches), OpenFlow on HP switches remains a shiny new toy.

When I was writing about the NEC+IBM OpenFlow trials, I figured out a perfect use case for OpenFlow-controlled network forwarding: SMB data centers that need less than a few hundred physical servers – be it bare-metal servers or hypervisor hosts (hat tip to Brad Hedlund for nudging me in the right direction a while ago)

A reader of my blog sent me this question:

I am a Telecommunication Engineer currently preparing for the CCIE exam. Do you think that in a near future it will be worth to be a CCIE, due to the recent developments like Nicira? What will be the future of Cisco IOS, and protocols like OSPF or BGP? I am totally disoriented about my career.

Well, although I wholeheartedly agree with recent post from Derick Winkworth, the sky is not falling (yet):

After all the laws-of-physics-are-changing hype it must have been anticlimactic for a lot of people to realize what Nicira is doing (although I’ve been telling you that for months). Not surprisingly, there were the usual complaints and twitterbursts:

I didn’t expect we’d see multi-vendor OpenFlow deployment any time soon. NEC and IBM decided to change that and Tervela, a company specialized in building messaging-based data fabrics, decided to verify their interoperability claims. Janice Roberts who works with NEC Corporation of America helped me get in touch with them and I was pleasantly surprised by their optimistic view of OpenFlow deployment in typical enterprise networks.

Three days ago IBM launched Distributed Virtual Switch 5000V, its own distributed vSwitch for VMware ESX platform. On one hand, it proves Cisco has been going the right way with Nexus 1000v (just in case you wondered), on the other hand, things just got way more interesting – IBM is obviously returning to networking.

Whenever the networking industry invents a new (somewhat radical) technology, bandwidth-on-demand seems to be one of the much-touted use cases. OpenFlow/SDN is no different – Juniper used its OpenFlow implementation (Open vSwitch sitting on top of Junos SDK) to demonstrate Bandwidth Calendaring (see Dave Ward’s presentation @ OpenFlow Symposium for more details), and Dmitri Kalintsev recently blogged “How about an ability for things like Open vSwitch ... to actually signal the transport network its connectivity requirements ... say desired bandwidth” I have only one problem with these ideas: I’ve seen them before.

Numerous articles published in the last few days describing how Nicira clashes heads-on with Cisco and Juniper just proved that you should never let facts interfere with a good story (let alone eye-catching headline). Just in case you got swayed away by those catchy stories, here’s the real McCoy (as I see it):

I got intrigued when reading Nicira’s white paper claiming their Open vSwitch can run within vSphere/ESX hypervisor. There are three APIs that you could use to get that job done: dvFilter API (intercepting VM NIC like vCDNI does), the undocumented virtual switch API used by Cisco’s Nexus 1000v, or the device driver interface (intercepting uplink traffic). Turns out Nicira decided to use a fourth approach using nothing but publicly available APIs.

Nicira, the OpenFlow startup behind the Open vSwitch, has finally dropped the stealthy cloak. Congratulations!!! Their web site is still pretty sparse on details, but you can get an initial impression of what they’re doing from a number of white papers describing Network Virtualization Platform and DVNI architecture. Short summary: I was almost right, but being a routing-and-switching bloke missed a few interesting bits – OpenFlow (and Open vSwitch) can easily combine security and forwarding functionality.

Two days ago I described how you can use tunneling or labeling to reduce the forwarding state in the network core (which you have to do if you want to have reasonably fast convergence with currently-available OpenFlow-enabled switches). Now let’s see what you can do in the very limited world of OpenFlow 1.0.