Systems Approach

A few weeks ago we published the draft of Computer Networks: A Systems Approach (7th edition) and asked for feedback. One of the most helpful responses was from a networking practitioner who commented on our treatment of network operations. His point was that we had focused too much on the perspective of large cloud operators and not enough on the "real world" of traditional network operators. In this week's newsletter we wrote about the difference, which has a lot to do with how much you can make the network conform to a "clean" model versus needing to deal with the messiness of heterogeneous systems in the real world. https://systemsapproach.org/2026/07/27/reality-based-network-operations/ 🧵 1/n

We occasionally hear that writing textbooks is no longer worthwhile when everyone can get their information from large language models (LLMs). We engage with this viewpoint rather than just writing books as we have for the last 30 years. In this post we lay out what we think our value proposition is: a big-picture view and systems thinking. https://systemsapproach.org/2026/06/01/textbooks-in-tokenland/

@huitema@social.secret-wg.org Fair point. I guess you can add that to the long list of things that DNSSEC doesn't solve. Our intent was to show why securing DNS might be worthwhile, not to suggest that DNSSEC was a good solution (hence the "failed experiment" comment)

@adamshostack@infosec.exchange You get a DRM-free ebook in epub format if you click the "buy ebook" link If you want to preview the book, you can visit the web version or the github repo first

Seems like a good day to revisit our "DNSSEC is a failed experiment" post: https://systemsapproach.org/2025/07/14/does-dns-security-matter/

Last week I was working on yet another chapter for our new edition, on the topic of Virtual Networks. Having spent much of my career focused on various flavors of virtualization, I decided to pick up that topic and run with it. Virtual networking has at least one thing in common with our last post: debate about terminology.

https://systemsapproach.org/2026/05/04/literally-virtualized/

@fivetonsflax@tilde.zone @ricci@discuss.systems We gave some thought to this approach but found it gets very hard to explain something like ARP or selecting the next hop in IP forwarding if you have reduced every forwarding device to a switch. It really matters whether it has an awareness of IP once you get into the details. When we call something a switch, we have left a lot of its behavior unspecified. Note that both Venn diagrams agree that the overall class of devices is "switch" - it's just that we can't leave it at that for the whole book.

The more important issue here is that the Internet has changed a lot since our first edition. While the Internet Protocol was invented to allow interconnection of different network technologies and the networks of different organizations, its success has meant that IP is often just used to forward packets among homogeneous links inside a single organization. That doesn't change the meaning of "router", it just illustrates one of many ways the Internet has changed. The adoption of BGP for routing inside datacenters is another example of how different the Internet and its protocols are today. This is the challenge we face in writing this new edition: to be correct and precise in our descriptions of technology while admitting that the Internet of today is different than the one we described in our first edition. And to do that in a way that leaves the reader understanding the technology without being overwhelmed by the complexity of today's networks. More in the newsletter: https://systemsapproach.org/2026/04/20/not-your-fathers-internet/ 4/4

This exposed two issues: first, is there a difference between an L3 switch and a router? And second, when modern switches can be configured to forward on either the Ethernet header or the IP header, how do we best talk about them? On the first question, we ultimately decided to let context be the determining factor. Even while there is no technical difference between an L3 switch and a router, the most common usage in the datacenter context favors "switch". For ISPs, router is still the preferred term. The configurability of modern devices, especially those based on programmable forwarding silicon, means we have to be clear in our discussions to separate what a device is capable of doing versus what it is configured to do. 3/n

Here are two images by the two authors representing different views of the naming issues: 2/n

We had a spirited debate in recent weeks regarding the right way to refer to modern networking devices, particularly those found in datacenters. One of us (Bruce) argued that, if it forwards IP packets, it's a router. Larry pushed back: shouldn't a router interconnect heterogeneous networks, or sit on the border between different autonomous systems?

Further confounding the discussion is conflicting usage by industry players: most networking devices in datacenters, even those forwarding IP packets, are called switches. Put a similar device inside a service provider's backbone? Most people call those things routers—so what's the rule for when to use each term?

This might seem like a trivial thing, but when writing a textbook, it's important that we use terminology precisely and consistently if we want our readers to understand the technology fully. Being inconsistent with standard industry practice would help no-one, even if we believe our stance to be "correct". The good news is that we resolved the issue to our satisfaction, and along the way we gained some insights into how much the Internet has changed since we wrote our first edition in 1995. More in this week's newsletter:

https://systemsapproach.org/2026/04/20/not-your-fathers-internet/

🧵 1/n

RE: @Drbruced@aus.social

Here's a funny story about creating the images for this week's newsletter. How generative AI fails to understand what "transparent background" means.

Our latest piece on QUIC has appeared in The Register:
https://www.theregister.com/2026/04/16/quic_explained/?td=rt-3a