Ben Cartwright-Cox has published a post detailing a recent BGP incident that had a fairly widespread impact on the global Internet routing system. The issue stemmed from how different routing platforms handled malformed, and therefore ‘unknown’ BGP payloads. Specifically, Juniper’s Junos software forwarded the malformed message, while other systems, like Arista’s EOS, discarded it. When a Junos router passed such a message to an Arista system, the Arista router responded by resetting all of its BGP sessions with peers.
Ben’s write-up is worth reading. He provides a solid walkthrough of the incident, explaining how he observed the behaviour and offering some reflections on BGP’s approach to error handling, something he’s written about on his blog before.
Meanwhile, over on Hacker News, an adjacent conversation has emerged, less about the incident itself and more about the broader philosophy of protocol design. The discussion touches on John Postel’s famous saying: “Be liberal in what you accept, and conservative in what you send.” That principle has guided Internet protocol development since the early days of the IETF. It’s so foundational that it’s often treated as a principle of good protocol behaviour.
However, some are now asking whether that same philosophy may be contributing to a growing problem called ‘protocol ossification’.
BGP is now 36 years old, dating back to 1989. It’s had to evolve continuously to support longer messages, extended communities, 32-bit ASNs, RPKI, and other security enhancements. But each time we add to or modify BGP, the protocol becomes harder to change. Its critical role in the Internet ecosystem makes operators reluctant to update or risk breaking it. So BGP hardens — ossifies — even as demands on it grow.
In effect, legacy protocols tend to resist change. Sometimes, that resistance is a good thing as it provides stability. But other times, as the Hacker News discussion points out, it becomes a serious obstacle to progress.
As Ben concludes in his post: “I have no happy ending for this.” There is often no clean outcome with ossification. The tension between stability and adaptability isn’t new, and it’s not going away. We’re living with both forces at once: The need to keep the Internet stable and the need to evolve it to meet new challenges.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
The larger the Internet grows, the harder it is to make pervasive changes to all its components. IPv6 is a good example. While there is an obvious fix to the Arista/Juniper mismatch, the general problem is real. A good example of evolution to new methods comes from QUIC which runs in user space, so OS mods were not needed to support it. Spread could be incremental. Whether there is a way to replicate BGP functionality in a new and incremental way is an open question worth asking. The Arpanet was the scaffold on which the Inernet was built. Dedicated telephone lines helped to build the Arpanet (and Internet) and now Internet packet voice carries a great deal of voice traffic for the telephone system. ps. it’s JON Postel.