After we get rid of the QoS FUD, the next question I usually get when discussing overlay networks is “how should these networks treat IP TTL?”

As (almost) always, the answer is “It depends.”

OpenStack seems to have a great architecture: all device-specific code is abstracted into plugins that have a well-defined API, allowing numerous (more or less innovative) implementations under the same umbrella orchestration system.

Looks great in PowerPoint, but to an uninitiated outsider looking at the network (Quantum, now Neutron) plugin through the lenses of OpenStack Neutron documentation, it looks like it was designed by either a vendor or a server-focused engineer using NIC device driver concepts.

I must have confused a few readers with my blog posts describing Arista’s VARP and Enterasys’ Fabric Routing – I got plenty of questions along the lines of “how does it really work behind the scenes?” Let’s shed some light on those dirty details.

Ed Horley, an awesome IPv6 geek I had the privilege to meet at NFD6, wrote an interesting blog post arguing against IPv6 ULA usage (particularly when combined with NPT66). We would all love to get rid of NAT, however ...

Not surprisingly, the unorthodox ideas of Tore Anderson generated plenty of questions, so he spent ~20 minutes answering them.

Fast advances in networking technologies (and the pixie dust sprinkled on them) blinded us – we lost our gut feeling and rule-of-thumb. Guess what, contrary to what we love to believe, networking isn’t unique. Physicists faced the same challenge for a long time; one of them was so good that they named the whole problem category after him.

Every time someone tries to tell you what your problem is, and how their wonderful new gizmo will solve it, it’s time for another Fermi estimate.

Every mid-sized company usually has legal counsel on staff (we have two lawyers for ~100 employees, but we might be a bit specific), that will escalate to an external law firm as necessary. Usually this would be when dealing with extraordinary events such as lawsuits or negotiation of a complex agreement.

Plexxi has an interesting problem. They have a shiny new solution that requires unorthodox approaches to network forwarding and allows them to implement potentially cool concepts like affinities (traffic engineering in disguise). They also need to sell these new concepts to the customers, and the first question I would ask after recovering from a hefty dose of cool-aid is "and how do I configure these affinities?"

I'll be talking about overlay virtual networks and clouds @ PLNOG 11 (September 30th - October 1st in Krakow) - if you're there and would like to chat with me, send me an email or a tweet.

Also, the organizers sent me this great promotional picture - I simply have to publish it ;)

The primary benefit of SDN (as claimed by its promoters) is a geek’s dream: the ability to program the network (or, more precisely, control network’s behavior through programmable tools).

Sounds great – we’ll finally be able to fix that pesky detail the vendor never wanted to implement (probably for a good reason). But should we REALLY do that?