Category: SDN

The “Is CLI In My Way … or a Symptom of a Bigger Problem” post generated some interesting discussions on Twitter, including this one:

One would hope that we wouldn’t have to bring up this point in 2014 … but unfortunately some $vendors still don’t get it.

The first question I tried to answer (and probably failed to) in the SDN 101 webinar was: What exactly is SDN? Is it an architecture with physically separate centralized control plane, or is it more? Does separate control plane make sense, or is it better to program distributed devices? Watch the video recorded during the live webinar session and tell me whether you agree with my answers.

My good friend Ethan recently published a blog post rightfully complaining how various vendor CLIs hamper our productivity. He’s absolutely correct from the productivity standpoint, and I agree with his conclusions (we need a layer of abstraction), but there’s more behind the scenes.

Network tapping and tap aggregation are obviously the OpenFlow equivalent of the Hello World application – almost every OpenFlow controller vendor has a tap aggregation solution. Does that make sense? Sure – tap aggregation network is outside of the production data path and thus a great candidate for semi-production technology pilots.

For more details, watch the Tap Aggregation Networks video recorded during the Real Life OpenFlow-based SDN Use Cases webinar

Almost three years ago the OpenFlow/SDN hype exploded and the Open Networking Foundation started promoting the concept of physically separate control and data planes. Let’s see how far its founding members got in the meantime:

The first part of the Real-life OpenFlow Use Cases webinar focused on controller design and implementation choices that can significantly impact the scalability of an OpenFlow solution:

• Proactive versus reactive flow setup;
• Hop-by-hop versus path-based forwarding;
• State explosion with OpenFlow 1.0;

You could tell we had great fun with these topics: we spent more than half an hour on five slides.

When Open Networking Foundation claimed ownership of Software-Defined Networking, they defined it as separation of control and data plane:

[SDN is] The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Does this definition make sense or is it too limiting? Is there more to SDN? Would a broader scope make more sense?

Software-Defined Networking is clearly a tautological term – after all, software defined networking device behavior ever since we stopped using Token Ring MAUs and unmanaged hubs. Open Networking Foundation claims it owns the definition of the term (which makes approximately as much sense as someone claiming they own the definition of red-colored clouds), but I was always wondering who coined the term in the first place.

After my Clouds, Overlays and SDN: What really matters keynote presentation @ MENOG 12 a few attendees asked me for a recording; one of them said “I want everyone in my organization to watch it.” Alas, wishes don’t always come true: the video team was streaming the presentations, but not recording them.

Fortunately I had the same presentation @ PLNOG 11 and like always the PLNOG organizers did a marvelous job. The video has just been posted on YouTube. Enjoy!

It’s easy to say “SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices,” handwave over the details, and let someone else figure them out. Implementing that concept in a reliable manner is a totally different undertaking.

In 1998, the cover story of ACM netWorker magazine discussed the dawn of the stupid network – an architecture with smart edge nodes and simple packet forwarding code. Obviously we learned nothing in all those years – we’re still having the same discussions.

Here are a few juicy quotes from that article (taken completely out of context solely for your enjoyment).

I had three SDN 101 presentations during last week’s visit to South Africa and had tried really hard to overcome my grumpy skeptic self and find the essence of SDN while preparing for them. As I’ve been thinking about controllers, central visibility and network device programmability, it struck me: we already had SDN in 1993.

In the first Terastream blog post I mentioned Deutsche Telekom decided to use an IPv6-only access network. Does that mean they decided to go down the T-Mobile route and deployed NAT64 + 464XLAT? That combo wouldn’t work well for them, and they couldn’t use MAP-E due to lack of IP address space, so they deployed yet another translation mechanism – Lightweight 4over6.

Even though I questioned the wisdom of writing your own network programming applications, I know I would immediately jump into those waters if I were 20 years younger. If you’re like my younger self, you might want to keep a few guidelines in mind.

Almost a year ago rumors started circulating about a Deutsche Telekom pilot network utilizing some crazy new optic technology. In spring I’ve heard about them using NFV and Tail-f NCS for service provisioning … but it took a few more months till we got the first glimpses into their architecture.

TL&DR summary: Good design always beats bleeding-edge technologies