Category: worth reading

Before we managed to recover from the automation cargo cults, a tsunami wave of cargo cult AI washed over us as Edlyn V. Levine explained in an ACM Queue article. Enjoy ;)

Also, a bit of a historical perspective is never a bad thing:

Impressive progress in AI, including the recent sensation of ChatGPT, has been dominated by the success of a single, decades-old machine-learning approach called a multilayer (or deep) neural network. This approach was invented in the 1940s, and essentially all of the foundational concepts of neural networks and associated methods—including convolutional neural networks and backpropagation—were in place by the 1980s.

Bruce Schneier wrote an excellent essay explaining why we need trustworthy AI and why we won’t get it as long the AI solutions are created by large tech companies with you are a product business model.

Michele Chubirka published a must-read article on technology fallacies including this gem:

Technologists often assume that all problems can be beaten into submission with a technology hammer.

As I’ve been saying for ages (not that anyone would listen): all the technology in the world won’t save you unless you change the mentality and rearchitect broken processes.

I mentioned IP source address validation (SAV) as one of the MANRS-recommended actions in the Internet Routing Security webinar but did not go into any details (as the webinar deals with routing security, not data-plane security)… but I stumbled upon a wonderful companion article published by RIPE Labs: Why Is Source Address Validation Still a Problem?.

The article goes through the basics of SAV, best practices, and (most interesting) using free testing tools to detect non-compliant networks. Definitely worth reading!

I wrote dozens of blog posts debunking disaster recovery fairy tales (mostly of the long-distance vMotion and stretched clusters variety) over the years. They are collected and sorted (and polished a bit) in the new Disaster Recovery Resources page. Hope you’ll find them useful.

I attended ITNOG 7 last week, and thoroughly enjoyed a full day of interesting presentations, including how do you run Internet services in a war zone by Elena Lutsenko and Milko Ilari.

The morning was focused primarily on BGP:

Nicola Modena had an interesting presentation describing how you can use BGP FlowSpec for traffic steering and service insertion during the recent ITNOG 7 event (more about the event in a few days).

One of the slides explained how to use three different aspects of BGP (FlowSpec, MPLS/VPN and multipathing), prompting me to claim the presentation title should be “BGP is the answer, what was the question?” 😉 Hope you’ll enjoy the PDF version of the presentation as much as we did the live one.

In case you ever wondered how old the “keep network simple and do complex stuff at the endpoints” approach is, read the End-to-End Arguments in System Design article from 1981.

For whatever reason (hint: profits), networking vendors keep ignoring those arguments, turning the network into a kitchen sink of complexity.

Fun tidbit: the article describes a variant of relying on layer-2 checksums will corrupt your data. Some things never change.

Want to know some details behind the CloudFlare SD-WAN implementation? You might find them in From IP packets to HTTP: the many faces of our Oxy framework.

I don’t know enough about Linux networking to figure out whether one could use those details to build something similar, but CloudFlare blog posts keep begin much better than Google’s Look How Awesome We Are recruitment drives.

Avery Pennarun published a lovely rambling on magic, science, engineering and a pinch of AI. You might enjoy reading it¹ with your Sunday morning coffee 😎.

While I was developing Network Automation Concepts webinar and the network automation online course, I wrote numerous blog posts on the Network Infrastructure as Code (NIaC) concepts, challenges, implementation details, tools, and sample solutions.

In March 2023 I collected these blog posts into a dedicated NIaC resources page that also includes links to webinars, sample network automation solutions, and relevant GitHub repositories.

Bruce Davie continues documenting the tradeoffs we had to make in networking, this time with Was MPLS Traffic Engineering Worthwhile? I found this bit particularly familiar:

It wasn’t hard to make a theoretical argument that MPLS-TE could improve network performance and average link utilization, by moving traffic from congested links to uncongested ones. The hard part was proving that it would actually do a better job in practice than the more traditional methods such as using link weights and multipath routing to achieve the same ends.

Years ago I loved ranting about the stupidities of building stretched VLANs to run high-availability network services clusters with two nodes (be it firewalls, load balancers, or data center switches with centralized control plane) across multiple sites.

I collected pointers to those blog posts and other ipSpace.net HA cluster resources on the new High Availability Service Clusters page.

Jeff McLaughlin wrote a nice blog post on the death of CLI (and why it has been greatly exaggerated):

The GUI-based layout tool [for iOS app development] is going away in favor of UI-as-code! The black screen always comes back!

As I’ve been saying for ages: people optimizing their productivity use CLI.

I have blog post ideas sitting in my to-write queue for over a decade. One of them is why would you need a VRF (and associated router) between virtual servers and a firewall?

Andrea Dainese answered at least part of that question in his Off-Path firewall with Traffic Engineering blog post. Enjoy!