A long while ago, I wrote about the brokenness of socket API and lack of session layer in TCP/IP stack.

It looks like I’m not the only one with heretic opinions; Fred Baker reached similar conclusions in his Happier Eyeballs draft and Brian Carpenter recently published a lengthy article title IP Addresses Considered Harmful which documents (among other things) the history of socket API and the reasons DNS isn’t tightly integrated with it. Both documents are definitely worth reading.

Overlay virtual networks were the first commercial-grade OpenFlow use case – Nicira’s Network Virtualization Platform (NVP – rebranded as VMware NSX for Multiple Hypervisors after the acquisition, and finally rearchitected into VMware NSX-T) used OpenFlow to program the hypervisor virtual switches (Open vSwitches – OVS).

OpenStack is using the same approach in its OVS Neutron plugin, and it seems Open Daylight aims to reinvent that same wheel, replacing OVS plugin running on the hypervisor host agent with central controller.

Does that mean one should always use OpenFlow to implement overlay virtual networks? Not really, OpenFlow is not exactly the best tool for the job.

I know numerous engineers who decided to pursue a career in networking because they didn’t want to deep-dive into programming. Will that change when the Software Defined Everything takes over the world?

TL&DR summary: Of course not.

One of my readers sent me an interesting question:

I have been reading at many places about "throwing more bandwidth at the problem." How far is this statement valid? Should the applications(servers) work with the assumption that there is infinite bandwidth provided at the fabric level?

Moore’s law works in our favor. It’s already cheaper (in some environments) to add bandwidth than to deploy QoS.

Some of the comments I get every time I write about the idea of merging network services deployment with application deployments, and making application developers responsible for the results of their code (aka DevOps) remind me of a very long list of “this will never work” sentiments I encountered in the 30 years I spent in IT and networking. Here are just a few of them:

I’m not sure I wrote about the taxonomy of numerous virtual networking implementations. Just in case, here it is ;)

Layer-2 or layer-3 networks?

Some virtual networking solutions emulate thick coax cable (more precisely, layer-2 switch), giving their users the impression of having regular VLAN-like layer-2 segments.

One of my readers wanted to deploy FCoE on UCS in combination with Nexus 1000v and wondered how the FCoE traffic impacts QoS on Nexus 1000v. He wrote:

Let's say I want 4Gb for FCoE. Should I add bandwidth shares up to 60% in the nexus 1000v CBWFQ config so that 40% are in the default-class as 1kv is not aware of FCoE traffic? Or add up to 100% with the assumption that the 1kv knows there is only 6Gb left for network? Also, will the Nexus 1000v be able to detect contention on the uplink even if it doesn't see the FCoE traffic?

As always, things aren’t as simple as they look.

Last Friday my students attending this year’s Designing Scalable Web Applications course presented their semester-long assignments. I can’t tell you how pleasantly surprised I was – the results were much better and more polished than what I’ve seen during the previous years.

Everyone talks about Linux containers these days like they would be the hottest thing invented this spring. In reality, it’s a pretty old technology that was heavily used by some smart web hosting companies for years (but of course, some people think mentioning Google makes everything look sexier).

If you’re interested in a high-level overview of differences between Linux containers and more traditional virtual machines, watch the video from the Introduction to Virtual Networking webinar.

Recently I was discussing the benefits and drawbacks of virtual appliances, software-defined data centers, and self-service approach to application deployment with a group of extremely smart networking engineers.

After the usual set of objections, someone said “but if we won’t become more flexible, the developers will simply go to Amazon. In fact, they already use Amazon Web Services.”