This blog post was written in 2014 (and sat half-forgotten in a Word file somewhere in my Dropbox), but as it seems not much has changed in the meantime, it’s time to publish it anyway.

I was listening to the fantastic (now gone) SDN Trinity podcast while biking around Slovenian hills and almost fell off the bike while furiously nodding to a statement along the lines of “I hate how every SDN vendor loves to bash networking engineers.”

Few years ago a bunch of engineers agreed that the customers need a comprehensive “IPv6 Buyer’s Guide” and thus RIPE-554 was born. There are also IPv6 certification labs, US Government IPv6 profile and other initiatives. The common problem: all these things are complex.

However, it’s extremely easy to get what you want as Ron Broersma explained during his presentation at recent Slovenian IPv6 meeting. All it takes is a single paragraph in the RFP saying something along these lines:

Now that we know which definitions of SDN make no sense (and which one might) let’s see what a typical architecture of an SDN solution might look like.

I described some of them in the SDN 101 webinar, for more details watch the SDN Architectures and Deployment Guidelines webinar.

One of my readers was listening to the Snabb Switch podcast and started wondering “whether it’s possible to leverage and adopt these bleeding-edge technologies without a substantial staff of savvy programmers?”

Short answer: No. Someone has to do the heavy lifting, regardless of whether you have programmers on-site, outsource the work to contractors, or pay vendors to do it.

Russ White wrote an awesome response to my Complexity Sells post:

[…] What we cannot do is forget that complexity is real, and we need to learn to manage it. What we must not do is continue to think we can play in the land of dragons forever, and not get burnt. […]

Now go and read the whole blog post ;)

A few days after I published a blog post arguing that most service providers cannot possibly copy Google’s ideas Giacomo Bernardi wrote a comment saying “well, we managed to build our own gear.”

Initially I thought they built their own Linux distribution on top of x86 server, but what Giacomo Bernardi described in Episode 59 of Software Gone Wild goes way beyond that:

Remember our journey toward two-switch data center? So far we:

• Virtualized all workload we could;
• Removed legacy technologies.

Time for the next step: read a recent design guide from your favorite hypervisor vendor and reduce the number of server uplinks to two.

Not good enough? Building a bigger data center? There’s exactly one seat left in the Building Next Generation Data Center online course.

Reading my Directed ARP and ICMP Redirects blog post you might have wondered “how did Directed ARP ever get into ***redacted***?”

I searched for “directed ARP cisco” and found this gem, which really talks about unicast ARP behavior, an ancient mechanism documented in RFC 1122 (it’s not my Google-Fu, I got the reference to RFC 1122 in this blog post).

When someone tells you that “TCP is a lossy protocol” during a job interview, don’t throw him out immediately – he was just trusting the Internet a bit too much (click to enlarge).

Everyone has a bad hair day, and it really doesn’t matter who published that text… but if you’re publishing technical information, at least try to do no harm.

Three years ago I was speaking with one of the attendees of my overlay virtual networking workshop @ Interop Las Vegas and he asked me how soon I thought the overlay virtual networking technologies would be accepted in the enterprise networks.

My response: “you might be surprised at the speed of the uptake.” Turns out, I was wrong (again). Today I’m surprised at the lack of that speed.