We got pretty far in our data deduplication in network data model journey, from initial attempts to network modeled as a graph… but we still haven’t got rid of all the duplicate information.

For example, if we have multiple devices connected to the same subnet, why should we have to specify IP address and subnet mask for every device (literally begging the operators to make input errors). Wouldn’t it be better (assuming we don’t care about exact IP addresses on core links) to assign IP addresses automatically?

The No Scripting Required to Start Your Automation Journey blog post generated lively discussions (and a bit of trolling from the anonymous peanut gallery). One of the threads focused on “how does automation work in real life IT department where it might be challenging to simplify operations before automating them due to many exceptions, legacy support…”

Here’s a great answer provided by another reader:

Roy Chua (SDx Central) published a blog post titled “Where Have All the SDN Controllers Gone” a while ago describing the gradual disappearance of SDN controller hype.

No surprise there - some of us were pointing out the gap between marketing and reality years ago.

It was evident to anyone familiar with how networking actually works that in a generic environment the drawbacks of orthodox centralized control plane SDN approach far outweigh its benefits. There are special use cases like intelligent patch panels where a centralized control plane makes sense.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

At the end of my vNIC 2018 keynote speech I made a statement along these lines:

The moment you start using GUI with an SDN product you’re back to square one.

That claim confused a few people – Mark left this comment on my blog:

Approximately two years ago I tried to figure out whether aggressive marketing of deep buffer data center switches makes sense, recorded a few podcasts on the topic and organized a webinar with JR Rivers.

Not surprisingly, the question keeps popping up, so it seems it’s time for another series of TL&DR articles. Let’s start with the basics:

Remember the avoid duplicate data in network automation data models challenge and the restructuring we did to represent a network as a graph.

Well, I was not happy with the end result - I hated the complexity of supporting Jinja2 templates that had to check left- and right nodes of a link, so I generalized the data structure a bit, and all of a sudden I could model stub interfaces, P2P links and multi-access networks.

A while ago, I had an interesting consulting engagement: a multinational organization wanted to migrate off global Carrier Ethernet VPN (with routers at the edges) to MPLS/VPN.

While that sounds like the right thing to do (after all, L3 must be better than L2, right?), in that particular case, they wanted to combine the provider VPN with an Internet-based IPsec VPN. Doing that in parallel with MPLS/VPN tends to become an interesting exercise in “how convoluted can I make my design before I give up and migrate to BGP.”

Found a fantastic list of common logical fallacies. It's a must read for anyone having at least occasional interaction with non-Vulcans... and when you stop laughing (or screaming, or both) make sure you go through the companion web site to understand bugs in your wetware that sabotage your attempts at being perfectly logical.

I’m always amazed at how fast the time flies. I have no idea where May disappeared to, it seems like it was only yesterday when I was writing about webinar plans in 2019… and yet it’s only a month till ipSpace.net Summer Break™.

During June 2019 I’ll continue updating Designing the Private Cloud Infrastructure webinar, and start a new pet project: How Networks Really Work – I’m literally minutes away from traveling to a quiet spot in the middle of nowhere where I’ll work on the materials. In between these webinars you’ll find me in Zurich where I’ll run Microsoft Azure Networking workshop on June 12^th in parallel with SIGS Technology Conference.

I hate listening to “this is what we were doing this year” podcasts as they usually turn into pointless blabbering, self-congratulations and meaningless plans (think New Year resolutions). The Full Stack Journey Episode 28 with Scott Lowe was an amazing deviation from this too-common template.

If you don’t have time to listen to the podcast (but you OUGHT TO do it) here’s what I loved most: “When faced with the onslaught of new technologies, don’t panic. Wait a few months to see which ones survive”.