A few days ago I had a nice chat with Christoph Jaggi about private and public clouds, and the mistakes you can make when building a private cloud – the topics we’ll be discussing in the Designing Infrastructure for Private Clouds workshop @ Data Center Day in Berne in mid-September.

The German version of our talk has been published on Inside-IT; those of you not fluent in German will find the English version below.

A friend of mine sent me an interesting problem:

I noticed recently that my IOS routers aren't sending ICMP (unreachable; frag needed) messages in response to too-big IPv4 multicast packets with DF-bit set. They're just dropping these packets silently, breaking PMTUD.

Unfortunately, that’s not a bug but a FAD (Functions-as-Designed).

My first ride with Uber was a love at first sight – the amount of friction they managed to remove from using-a-taxi process is unbelievable.

However, every love story eventually faces real-life issues, and what really matters is how you handle them at that point.

Robin Harris described an interesting problem in his latest blog post: while you can reduce the storage access time from milliseconds to microseconds, the whole software stack riding on top still takes over 100 milliseconds to respond. Sometimes we’re optimizing the wrong part of the stack.

Any resemblance to SDN in enterprises or the magical cost-reduction properties of multi-vendor data center fabrics is obviously purely coincidental.

A link on Bruce Schneier’s blog pointed me to the latest article by the truly awesome James Mickens, this time making great fun of security researchers. Exactly what you need with your coffee on a Saturday morning. Enjoy!

After introducing the concepts of Cumulus Linux in the Data Center Fabrics update session, Dinesh Dutt described the typical data center architectures implemented with Cumulus Linux and the lessons everyone should learn from large-scale web properties.

Henk left a wonderful comment on my SDN will not solve real-life enterprise problems blog post. He started with a bit of sarcasm:

SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

However, he thinks (and I agree) that this vision doesn’t make sense:

Open Networking Foundation has this nice and crisp definition of SDN:

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

Using this definition it was easy to figure out whether certain architecture complies with ONF definition of SDN. It was also easy to point out why it was ridiculous.

In the Can Virtual Routers Compete with Physical Hardware blog post I mentioned that SSL termination remains one of the few bastions of hardware acceleration.

Based on the comment made by RPM, it looks like I was wrong.

Here’s his reasoning:

One of my readers wondered how long my NFV webinar is supposed to take (and I forgot to add that information to my web site), so he sent me this question: “How long is this webinar? An hour? Two hours? If it says "webinar" does that imply a 60 minute duration, so I shouldn't ask?”

Short answer: live webinar sessions usually take between 90 minutes and 2 hours depending on the breadth of the topic, however…