I'm not protesting the count of BGP implementations, the more the merrier. I'm protesting the lack of BGP libraries. On Fri, 5 Jun 2026 at 16:25, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Regarding the multiplicity of daemons for BGP.
I believe it's only necessary to say that there are daemons with different purposes. - FRR, for instance, most of the time doesn't allow you to break what the protocol proposes. To do that, you have to go down several layers, which isn't simple. - ExaBGP, for example, is designed so that you can do "anything you want" with the routes, regardless of whether they respect basic BGP criteria.
And both are necessary.
Em qui., 4 de jun. de 2026 às 05:00, Saku Ytti via NANOG <nanog@lists.nanog.org> escreveu:
On Wed, 3 Jun 2026 at 18:05, André Dias via NANOG <nanog@lists.nanog.org> wrote:
I use FRR a lot in ISPs that I work for, but in cases of RR I prefer to use GoBGP or BIRD. I prefer GoBGP or Bird instead FRR because they are easier to automate.
It boggles my mind that someone goes 'I'm going to write this very complex daemon' and then they proceed to write monolithic tightly coupled CLI+daemon+logic.
So we have a huge collection of BGP implementations, as mentioned just here, frr, gobgp, bird, rustybgp, openbgp, exabgp and many many others. But we don't really have any BGP library approaching a similar maturity level. While to me it seems it should have been an obvious win for any project, to start day1 with decoupled library, cli and daemon as separate libraries, i see it reducing work day1 due to forcing more maintainability in design.
Then instead of using low performance, lacking or non-existing APIs in your automation, you could write your own BGP worker using the library to have superior flexibility and performance, and exactly the behaviour you want. Many things you cannot do at all, because you don't have a library, like fuzzing, the daemon won't allow you to do wrong/bad things.
So please, the next person planning to write BGP or whatever project they're thinking of, separate the logic and daemon. Thank you.
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OPAVVROP...
-- Douglas Fernando Fischer Engº de Controle e Automação
-- ++ytti