Early Bird Discount until October 15: ✓ Save up to €100 ✓ 10% Team Discount

Blog

iSAQB Software Architecture Gathering

radia-perlman
Radia Perlman
Fellow at Dell Technologies
Published on September 11, 2026

Question Everything: Radia Perlman on Rethinking the Networks We Take for Granted

In anticipation of Radia Perlman’s SAG 2026 keynote “Network Protocols: Myths, Missteps, and Mysteries,” we asked the networking pioneer to challenge some of the assumptions behind today’s networks, from historical decisions that still shape the Internet to protocols she would redesign or even retire altogether.

1. Your keynote challenges some long-held assumptions about networking. If you could erase one networking myth from every engineer's mind tomorrow, which one would it be, and why?

That computer network protocols make sense and need to be as complicated as they are. If someone is trying to learn about how things work today, they will be very confused, unless they just memorize details without thinking about them. In fact, network protocols evolved, with the industry sometimes making bad decisions, and then people devising workarounds without going back and fixing mistakes. If we started over, could we make things much simpler? Probably, but I compare it to English. What a terrible language! All the spelling, grammar, and pronunciation exceptions! Could one design a better language? Certainly, but there is no incentive to change to a newly designed language given that English can pretty much express anything we need to say, and English can always be evolved with more words and exceptions.

2. You argue that today's networking stack carries a lot of historical baggage. If you had the chance to redesign today's networking stack from scratch, which historical design decision would you keep, and which one would you leave behind?

I think one of the worst decisions was not to convert from IPv4 to CLNP in 1992 when it was obvious that IPv4 addresses were too small for how big the Internet would be. CLNP had 20 byte addresses. Even if the world fully converts to IPv6 with its 16 byte address, CLNP had important advantages over IPv4 or IPv6 (I’ll just use the term “IP” to refer to both IPv4 and IPv6). IP routers have the property that if you move from one side of a router to another you need to change your IP address. So it is impossible to have a cloud such as a data center, where virtual machines can move around without changing their address. CLNP did allow that. An IP router delivers a packet to what it perceives as a single link. Various technologies disguise a multilink cloud to IP routers to look like a single link, such as spanning tree Ethernet. Then the IP router needs to shout into the cloud an ARP request (called ND in IPv6) to find out the destination’s address within the cloud, so the IP router can add an extra header onto the packet before transmitting it into the cloud.

In contrast, in CLNP, the top 14 types is a prefix shared by all the nodes within a large multi-link cloud. When a CLNP router reaches the destination cloud, it just injects the packet into the cloud, and the cloud routes based on the bottom 6 bytes. The destination can move around within the cloud without changing its address. Given that “Ethernet” today does not involved shared CSMA/CD links, and is all pt-to-pt links (connected with “switches” or “bridges”), if the world had converted in 1992, we would not be using the Ethernet header, or bridges. Everything would be connected using CLNP routers.

There was no legitimate technical reason not to convert to CLNP in 1992, other than “not invented here”. Had the industry done this, we not only would be using larger addresses today (even bigger than IPv6), but things would be so much more efficient and self-configuring.

3. In your keynote, you suggest that making the "wrong" decisions sometimes led to valuable innovations. Looking back, is there a mistake in the history of networking that ultimately turned out to be a blessing?

I wouldn’t call it a blessing, exactly, but I think that two protocols that might not have been invented if the world had converted to CLNP in 1992 are DHCP and NAT. Both of these would work fine with CLNP, and in fact would have made CLNP even better, but I’m not sure people would have thought of NAT (given that CLNP had plenty of addresses), or DHCP (given that CLNP had a mechanism for autoconfiguration).

4. You helped shape technologies that are still at the heart of modern networks decades later. Looking at today's trends, are there any technologies or architectural decisions that you believe future generations will look back on and wonder, "Why did we ever do it this way?"

I hope that people look back and wonder “why did we do it this way” about everything. Most network protocol books, and teachers, teach network protocols as “memorize how it works today and just assume everything is perfect”. The only way to understand today’s networks without giving yourself a very bad headache is to understand the history, and that not all decisions were good. Learning it is much more interesting that way. Plus, if you ever need to design something new, it is really important to understand today’s protocols critically, and to have learned about and understood the good technologies that are no longer deployed.

5. Many engineers treat protocols as fixed standards that simply have to be accepted. Your keynote seems to encourage questioning them instead. Do you think today's software engineers challenge established technologies often enough, or have we become too comfortable following conventions?

I hope they challenge established technologies, but I suspect things are so complicated that it uses all their energy just to memorize the idiosyncrasies of what is deployed.

6. If you could retire one protocol, technology, or architectural idea from today's networking stack, what would it be, and why?

I’d get rid of BGP. BGP is very fragile, configuration intensive, and slow.

When I mention that the world didn’t need BGP, one reason people give is for scalability, since OSPF or IS-IS could not scale to the entire Internet. This argument is incorrect. IS-IS allowed many levels of hierarchy. So the Internet could be partitioned into pieces that IS-IS called “areas” and BGP calls “domains” or “autonomous systems”. Let’s just call them “domains”. Rather than needing a different protocol to connect domains to each other, IS-IS allowed levels of hierarchy.

The other reason people give for “needing BGP” is “policies”. When I complain about BGP, people say “could you design something better?” And I believe I can, but I don’t like designing solutions before I understand the problem to be solved. So I’ve given the industry homework of “describe which policies you need, and which ones would be nice but you could live without.” Unfortunately, BGP is so entrenched that people can only think of what BGP policies they use today.

But BGP doesn’t do all policies I’d think you’d want. For example, if some router R is between me and the destination, I have to live with whatever path it chose to get to the destination. A different source might need/want a different choice. For example, I might want my data delivered via a path that just goes through NATO domains, whereas some other source might need a path delivered through non-NATO domains. BGP lets R choose the path, and everyone on the other side just has to live with it.

So really, which “policies” are essential?

I’d suspect that policy-based routing could be implemented more efficiently with a protocol like IS-IS where the Internet would choose some set of paths, and anyone that needed a different path (because the chosen path did not meet the desired policy) could set up an additional path.

Many thanks to Radia for the great interview!
More from the speaker

Network Protocols: Myths, Missteps, and Mysteries (Keynote by Radia Perlman)

Network Security, Cryptography, and Quantum (Workshop by Radia Perlman & Charlie Kaufman)

Return to Overview