Saku, I don’t frequently agree with your posts, but I agree with this. FRR is embedded in a lot of systems, and sometimes is somehow buried underneath a second CLI. These layers of config files frequently cause configuration de-sync issues. So the top level configuration that I see, is different from the configuration that FRR is using. I realize it is somewhat different, but it similar to the entire issue of “commit” versus “commit full”. You can commit a configuration, which may not be fully applied to the hardware, or you can “commit full” and really commit that change. Its just because the outer most configuration layer, doesn’t know what is going on the lower layers of configuration. But as a mid-sized ISP, and with route reflectors having the ability to identify new EVPN instances, and routers having the ability to signal to the RR, which EVPN and L3VPN instances they are part of, how much programmability would I need? Other than modifying global policy, perhaps I never need to modify the RR configuration? I certainly don’t need to modify it, to add a new EVPN or new L3VPN? Tom
On Jun 4, 2026, at 12:59 AM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
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...