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 < [email protected]> escreveu: > On Wed, 3 Jun 2026 at 18:05, André Dias via NANOG <[email protected]> > 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/[email protected]/message/OPAVVROPAXNFN5VTGB5RDLYQ4HPQGGGT/ -- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/Z53M4HBJ4T6GUYVWWLG2LDWJ4YPB5XMI/
