Category: OpenFlow

Continuing the how real is the decade-old SDN hype thread, let’s try to figure out if anyone still uses OpenFlow. OpenFlow was declared dead by the troubadour of the SDN movement in 2016, so it looks like the question is moot. However, nothing ever dies in networking (including hop-by-hop IPv6 extension headers), so here we go.

Why Would One Use OpenFlow?

Ignoring for the moment the embarrassing we solved the global load balancing with per-flow forwarding academic blunders¹, OpenFlow wasn’t the worst tool for programming forwarding exceptions (ACL/PBR) into TCAM.

I thought I was too harsh every now and then, but I’m a complete amateur when compared to Minh Ha’s take on OpenFlow.

Indeed Quantum Computing and OpenFlow have a lot in common. They both create stories that have emotional appeal, they both require invention of new physics, and they’re both filled with grand vision, grandstanding, and empty promises. But there’s no shortage of PhDs, high hopes, cash infusion from VCs, and a Cambrian explosion of research papers, many of which content is not even worth the papers it’s printed on.

I read an excellent rant by prof. Victor Galitski describing the current explosion of Quantum Computing hype, and couldn’t help being reminded of the OpenFlow brouhaha we experienced almost a decade ago – you could do a simple search-and-replace and the article would have been equally valid.

Enjoy… and remember the details for the next time your beloved vendor comes along with Quantum Computing slide deck.

This podcast introduction was written by Nick Buraglio, the host of today’s podcast.

In the original days of this podcast, there were heavy, deep discussions about this new protocol called “OpenFlow”. Like many of our most creative innovations in the IT field, OpenFlow came from an academic research project that aimed to change the way that we as operators managed, configured, and even thought about networking fundamentals.

For the most part, this project did what it intended, but once the marketing machine realized the flexibility of the technology and its potential to completely change the way we think about vendors, networks, provisioning, and management of networking, they were off to the races.

We all know what happened next.

Remember how Nick Buraglio tried to use OpenDaylight to build a small part of SuperComputing conference network… and ended up with a programmable patch panel?

This time he repeated the experiment using Faucet SDN Controller – an OpenFlow controller focused on getting the job done – and described his experience in Episode 101 of Software Gone Wild.

We started with the usual “what problem were you trying to solve” and quickly started teasing apart the architecture and got geekily focused on interesting things like:

A while ago I sent out an email to my SDN and network automation mailing list (join here) asking whether anyone uses Open Daylight in anything close to a production environment (because I haven’t ever seen one).

Among many responses saying “not here” I got a polite email from VP of Marketing working for a company that sells OpenDaylight-related services listing tons of customer deployments (no surprise there).

I rarely get OpenFlow questions these days; here’s one I got not so long ago:

I've just spent the last 2 days of my life consuming the ONF 1.3.3 white paper in addition to the $vendor SDN guide to try and reconcile what features it does or does not support and have come away disappointed...

You’re not the only one ;)

On November 7th SDx Central published an article saying “OpenFlow is virtually dead.” There’s a first time for everything, and it’s a real fun reading a marketing blurb on a site sponsored by SDN vendors claiming the shiny SDN parade unicorn is dead.

On a more serious note, Tom Hollingsworth wrote a blog post in which he effectively said “OpenFlow is just a tool. Can we please find the right problem for it?”

Got this set of questions from one of my readers:

I just met up with DELL guys for Big Switch SDN. They claim there is no routing running on leaf switches, the BCF is purely OpenFlow.

Almost true. It is based on OpenFlow, but they use tons of their own OpenFlow extensions to get stuff to work. That’s also why you have to install their agent on the switches.

In one of my ExpertExpress engagements the customer expressed the desire to manage their firewall with OpenFlow (using OpenDaylight) and I said, “That doesn’t make much sense”. Here’s why:

Obviously if you can't imagine your life without OpenDaylight, or if your yearly objectives include "deploying OpenDaylight-based SDN solution", you can use it as a REST-to-NETCONF translator assuming your firewall supports NETCONF.

A while ago I discussed whether XMPP is a control- or management-plane protocol (spoiler: it depends). How about OVSDB? Here’s another question from one of my readers:

Why is Openflow considered as control plane protocol and OVSDB management plane protocol if both are relying on SDN controller? Is it because Openflow can directly modify the dataplane?

SDN controllers can use control- or management-plane protocols to get the job done.

Network Computing recently published an article with a promising title “Network Disaggregation: Opening the Last Back Box” and a subtitle I could totally relate to: “switch ASICs must be opened up to provide real networking flexibility.”

My beloved source of meaningless marketing messages led me to a blog post with a catchy headline: are open-source SDN controllers ready for carrier-grade services?

It turned out the whole thing was a simple marketing gig for Ixia testers, but supposedly “the response of the attendees of an SDN event was overwhelming”, which worries me… or makes me happy, because it’s easy to see plenty of fix-and-redesign work in the future.

I got an interesting question from one of my readers:

If every device talking to a centralized control plane uses an out-of-band channel to talk to the OpenFlow controller, isn’t this a scaling concern?

A year or so ago I would have said NO (arguing that the $0.02 CPU found in most networking devices is too slow to overload a controller or reasonably-fast control-plane network).

This article was initially sent to my SDN mailing list. To register for SDN tips, updates, and special offers, click here.

Usman asked a few questions in his comment on my blog, including:

At the moment, local RIB gets downloaded to FIB and we get packet forwarding on a router. If we start evaluating too many fields (PBR) and (assume) are able to push these policies to the FIB - what would become of the FIB table size?

Short answer: It would explode ;)