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.

Virtual Firewalls is the featured webinar in June 2016, and the featured videos (marked with a star) explain the difference between virtual contexts and virtual appliances, and the virtual firewalls taxonomy.

To view the videos, log into my.ipspace.net (or enroll into the trial subscription if you don’t have an account yet), select the webinar from the first page, and watch the videos marked with star.

If you're a trial subscriber and would like to get access to the whole webinar, use this month's featured webinar discount (and keep in mind that every purchase brings you closer to the full subscription).

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.

Long time ago in a podcast far far away Greg and Ethan pondered whether networking solutions need to scale or not, and obviously one cannot disagree with their generic conclusion that enterprises need just-good-enough solutions and not Google-scale architectures.

However, do keep in mind that:

A few weeks after I published Docker Networking podcast, Brent Salisbury sent me an email saying “hey, we have experimental Macvlan and Ipvlan support for Docker” – a great topic for another podcast.

It took a while to get the stars aligned, but finally we got Brent, Madhu Venugopal, John Willis and Nick Buraglio on the same Skype call resulting in Episode 57 of Software Gone Wild.

A. Friend sent me a long list of questions after listening to excellent Future of Networking podcast with Martin Casado because (as he said) he prefers “having a technical discussion with arguments and not just throwing statements out there.”

He started with “Martin's view seems to be that network is all plumbing and all the intelligence should be in the applications.”

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…

One of my readers working as an enterprise data center architect sent me this question:

I've just finished a one-week POC with Arista. For fabric provisioning and automation, we were introduced to CloudVision. My impression is that there are still a lot of manual processes when using CloudVision.

Arista initially focused on DIY people and those people loved the tools Arista EOS gave them: Linux on the box, programmability, APIs… However

In our journey toward two-switch data center we covered:

• The overall idea;
• The need for high-density server virtualization (most of the times).

It’s time for the next step: get rid of legacy technologies like six 1GE interfaces per server or two FC interface cards in every server.

Need more details? Watch the Designing Private Cloud Infrastructure webinar. How about an interactive discussion? Register for the Building Next-Generation Data Center course.

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

Occasionally I get feedback that makes me say “it’s worth doing the webinars ;)”. Here’s one I got after the layer-2 session of Leaf-and-Spine Fabric Designs webinar:

I work at a higher level of the stack, so it was a real eye opener especially with so much opinionated "myths" on the web that haven't been critically challenged such as [the usefulness of] STP.

There’s more feedback on this web page where you can also buy the webinar recording (or register for the next session of the webinar once they are scheduled).

One of my readers left a comment on my “optimize your data center by virtualizing the servers” blog post saying (approximately):

Seems like LinkedIn did it without virtualization :) Can enterprises achieve this to some extent?

Assuming you want to replace physical servers with one or two CPU cores and 4GB of memory with modern servers having dozens of cores and hundreds of GB of memory the short answer is: not for a long time.

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.