Category: SDN

I love Greg Ferro’s characterization of CLI:

We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

However, you do know that most devices’ GUI offers nothing more than what CLI does, don’t you? Where’s the catch?

NEC and a slew of its partners demonstrated an interesting next step in the SDN saga @ Interop Las Vegas 2013: multi-vendor SDN applications. Load balancing, orchestration and security solutions from A10, Silver Peak, Red Hat and Radware were happily cooperating with ProgrammableFlow controller.

A curious mind obviously wants to know what’s behind the scenes. Masterpieces of engineering? Large integration projects ... or is it just a smart application of API glue? In most cases, it’s the latter. Let’s look at the ProgrammableFlow – Radware integration.

Greg Ferro published a great blog post explaining why he decided to use node.js to build his cloud automation platform. While I agree with most things he wrote, this one prickled me the wrong way:

In my view, an Application Programmable Interface(API) is the fundamental change that makes Software Defined Networking (SDN) a “thing”. We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

While I agree with his view on CLI, keep in mind that API is no different.

The true OpenFlow zealots would love you to believe that you can drop whatever you’ve been doing before and replace it with a clean-slate solution using dumbest (and cheapest) possible switches and OpenFlow controllers.

In real world, your shiny new network has to communicate with the outside world … or you could take the approach most controller vendors did, decide to pretend STP is irrelevant, and ask people to configure static LAGs because you’re also not supporting LACP.

I was reading What Network Virtualization Isn’t¹ from Jon Onisick the other day and started experiencing all sorts of unpleasant flashbacks caused by my overly long exposure to networking industry missteps and dead ends touted as the best possible solutions or architectures in the days of their glory:

An individual focused more on sensationalism than content deemed it appropriate to publish an article declaring networking engineers an endangered species on an industry press web site that I considered somewhat reliable in the past.

The resulting flurry of expected blog posts included an interesting one from Steven Iveson in which he made a good point: it’s easy for the cream-of-the-crop not to be concerned, but what about others lower down the pile. As always, it makes sense to do a bit of reality check.

Brent Salisbury sent me a link to a fantastic OpenFlow/SDN presentation Scott Shenker did @ Stanford University a few days ago. It’s a perfect introduction to the fundamental ideas behind SDN and therefore a must-see for everyone vaguely involved in networking.

Here are some of the highlights (from my highly biased perspective):

The SDN industry probably considers me an old and grumpy naysayer (and I’m positive Mrs Y has a special place in their hearts after her recent blog post), so I tried really hard to find a real-life example where OpenFlow could be used to solve mid-market innovator’s dilemma to balance my usual OpenFlow and SDN presentation.

The OpenFlow zealots are quick to point out the beauties of the centralized control plane, and the huge savings you can expect from using commodity hardware and open-source software. What they usually forget to tell you is that you also have to reinvent all the wheels the networking industry has invented in the last 30 years.

NEC demonstrated multi-vendor OpenFlow network @ Interop Las Vegas, linking physical switches from Arista, Brocade, Centec, Dell, Extreme, Intel and NEC, and virtual switches in Linux (OVS) and Hyper-V (PF1000) environments in a leaf-and-spine fabric controlled by ProgrammableFlow controller (watch the video of Samrat Ganguly demonstrating the network).

Does that mean we’ve entered the era of multi-vendor OpenFlow networking? Not so fast.

One of the most pleasant surprises of the recent Interop show was the Tail-f's Network Control System (NCS). I “knew” Carl Moberg (of the NETCONF and YANG fame) for a long time and had the privilege to meet him in person just before the SDN Buyer's Guide panel that I co-hosted with Kurt Marko (who did an excellent job putting the buyer's guide together). Anyhow, what Carl presented during the panel totally blew me away.

Plexxi has a really interesting data center fabric solution that combines CWDM optics with L2+L3 switching. They briefed me on their product just before their public launch; I like their approach, particularly the combination of robust traditional forwarding with controller-based network optimization that you can influence from the outside, but somehow I never quite found the time to blog about them … although I did manage to solve the hard part of the problem: write a Perl script that generates Graphviz graph description to generate schematics of their CWDM inter-switch links.

Operating systems are boring (for most people); it’s the applications that make everyone excited. SDN is no different. Controllers are boring – someone has to reinvent all the wheels that the networking vendors have been inventing for the last 30 years before you can develop the sexy stuff ... but not many people outside of ivory towers would start developing the (supposedly) sexy SDN apps until being sure the underlying platform will not disappear into thin air.

I did a major overhaul of my RIPE 65 SDN presentation prior to MENOG 12 meeting, including a more comprehensive overview of SDN-related technologies sorted by the networking device plane they operate on.

I love(d) listening to the Packet Pushers podcast and came to expect the following rant in every SDN-focused episode: “I’m sick and tired of using CLI to manually provision VLANs”. Sure, we’re all in the same boat, but did you ever do something to get rid of that problem?