Category: OpenFlow

Is OpenFlow Still Kicking?

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 blunders1, OpenFlow wasn’t the worst tool for programming forwarding exceptions (ACL/PBR) into TCAM.

read more see 7 comments

OpenFlow Realities, 2021 Edition

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.

read more see 1 comments

Quantum Computing and OpenFlow

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.

see 3 comments

Faucet Deep Dive on Software Gone Wild

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.

read more add comment

Using Faucet to Build SC18 Network with OpenFlow

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:

read more see 2 comments

Is Anyone Using Open Daylight?

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

read more see 12 comments

Response: On the Death of OpenFlow

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?

read more see 6 comments

OpenFlow and Firewalls Don’t Mix Well

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.

read more add comment

Is OVSDB a Control- or Management-Plane Protocol?

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.

read more see 2 comments

Response: Are Open-Source Controllers Ready for Carrier-Grade Services?

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.

read more see 3 comments

Scalability of OpenFlow Control Plane Network

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

read more see 3 comments

Table Sizes in OpenFlow Switches

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 ;)

read more add comment