Category: OpenFlow

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

I spent the first half of the Introduction to SDN webinar explaining various attempts at defining SDN, and the obvious place to start was the centralized control plane mantra.

This part of the webinar is now public; to access the rest of the webinar, register on my web site.

Nick Buraglio used OpenDaylight and OpenFlow-enabled switches to build a part of the exhibition network of a large international supercomputing conference and was kind enough to talk about his real-life experience in Episode 47 of Software Gone Wild.

We covered:

Yesterday I described the theoretical limitations of using OpenFlow for load balancing purposes. Today let’s focus on the practical part and answer another question:

@colin_dixon @ioshints and for a fair comparison: Would a $100k OF switch be able to act as proper LB?

— Kristian Larsson (@plajjan) December 3, 2015

I wrote about the same topic years ago here and here. I know it’s hard to dig through old blog posts, so I collected them in a book.

It all started with a tweet Kristian Larsson sent me after I published my flow-based forwarding blog post:

@ioshints sure but can't OpenFlow be used to implement an LB? It feels like a mix of terms here

— Kristian Larsson (@plajjan) December 3, 2015

When writing the Packet- and Flow-Based Forwarding blog post, I tried to find a good definition of flow-based forwarding (and I was not the only one being confused), and the one from Junos SRX documentation is as good as anything else I found, so let’s use it.

TL&DR: Flow-based forwarding is a valid technical concept. However, when mentioned together with OpenFlow, it’s mostly marketing fluff.