Category: SDN

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.

During the Introduction to SDN webinar I covered numerous potential definitions:

• It’s the separation of control and data plane;
• It’s software-based packet forwarding;
• It’s open networking and whitebox switching;
• It’s network programmability and device APIs.

I find all of these definitions too narrow or even misleading. However, the “SDN is a layer of abstraction” one is not too bad (see also RFC 1925 section 2.6a).

Anyone following the popular networking blogs and podcasts is probably familiar with the claim that BGP is way too complex to be used in whatever environment. On the other hand, more and more smart people use it when building their data center or WAN infrastructure. There’s something wrong with this picture.

Gabi Gerber is organizing a Software-Defined Security event in Zurich next week in which I’ll talk about real-life security solutions that could be called software defined for whatever reason, and my friend Christoph Jaggi sent me a few questions trying to explore this particular blob of hype.

For obvious reasons he started with “Isn’t it all just marketing?”

My readers are consistently asking me whether XMPP and OVSDB are control- or management-plane protocols (to make matters worse, publicly available information tends to be confusing).

For example, one of them wrote…

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

The Model-driven Networking seems to be another buzzword riding on top of the SDN wave. What exactly is it, how is it supposed to work, will it be really vendor-independent, and has anyone implemented it? I tried to get some answers to these questions from Jeff Tantsura, chair of IETF Routing Area Working Group, in Episode 55 of Software Gone Wild.

Gabi Gerber (with a bit of help from my side) is organizing another set of SDN events in Zurich (Switzerland) in early June.

In the morning of June 7th we’ll talk about software-defined security:

The BGP-based SDN Solutions webinar triggered another interesting question from one the attendees:

It seems like the BGP route reflector functionality can be implemented as a Virtual Machine. Will a VM have enough resources to meet the requirements of a RR?

Short answer: Yes.

Vendors that slapped API on top of their CLI are quick to claim that they SDN-enabled their boxes.

Not so fast. As I explained in SDN 101 webinar, programmable access to network devices is nice (less so when you're forced to use a vendor-specific API), but it's not SDN.

I’m presenting at two Data Center Interest Group Switzerland events organized by Gabi Gerber in Zurich in early June:

• In the morning of June 7th we’ll talk about software-defined security, data center automation and open networking;
• In the afternoon of the same day (so you can easily attend both events) we’ll talk about VMware NSX microsegmentation and real-life implementations.

I hope to see you in Zurich in a bit more than a month!

One of my readers sent me this observation while reviewing my BGP-Based SDN Solutions webinar:

I am a bit surprised the SDN controller can actually be so lightweight.

Well, that's the benefit of augmenting an existing well-developed ecosystem instead of reinventing the wheel and reimplementing every single bit of functionality we had to develop to make networks work throughout the last 5 decades.

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

After covering the details of PCEP protocol in the BGP-LS and PCEP Deep Dive webinar Julian Lucek focused on how a controller would use PCEP to build MPLS TE paths across a network.

Oh, and don’t forget to explore the rest of the PCEP webinar and other SDN webinars after watching the video ;)

Oliver Steudler from Juniper sent me a link to an interesting Juniper blog post describing zero-bandwidth traffic engineering.

Read the blog post first and then come back for some opinionated rambling ;)

Is the problem real? Yes.