3 ms·
There's posts about this on a regular basis, every 2 years or so. Every now and again someone looks at Cisco IOS and Juniper JunOS and the various smaller ones
by candiodari 9y ago
There's posts about this on a regular basis, every 2 years or so. Every now and again someone looks at Cisco IOS and Juniper JunOS and the various smaller ones and decides that they just don't work well, because they have subtle bugs, no real tests, etc. (Never mind that both these pieces of software predate TDD by decades, with code in there that has been proven to be incredibly reliable much older than that)
There is no more value in posts like this than there is in the regular academic "we should reimplement the linux kernel in 10000 lines of code" shit that also comes by. Every now and then someone even actually does reimplement it, but it never quite replaces the linux kernel because ... well the linux features are mostly there for a reason. By the time you have an actual workable kernel, it's also far beyond what most developers seem to consider reasonable complexity boundaries.
And so it is for those networking features. In reality there is a reason for all those protocols. They (well, some) also work incredibly well, and, crucially, those protocols that are required from a router all have global footprints and interoperability between dozens of vendors which is not optional. There is a reason for the complexity and there is a cost to cutting out complexity, a cost we won't be willing to pay.
Just to be clear: I don't deny that there is value in trying to reimplement these critical infrastructure programs from time to time. But the value in that is mostly in improving your personal understanding and abilities, they cannot reasonably replace the infrastructure we use. And if they can, well then they are also very complex.
What can we say ? The real world is complex. Mostly ... for good reasons. So if you want to work/program in this space, you'll need to deal with the complexity.
- inopinatus 9y agoThis didn't read to me like a proposal to simplify routing software by simply ripping out protocols, but to refactor the design of the control plane and use more modern engineering processes than the writer saw at previous workplaces. If I read between the lines correctly, he wants to build a microservices-based router for the high end network operator market. The writer is a multiple RFC author, IETF protocol chair and former distinguished engineer at Juniper, i.e. they already do "work/program in this space" and "deal with the complexity", so criticism on that basis might fall a little flat.