Thanks Raymond, cursory look makes it look quite usable. There are purpose-built BGP libraries, but they're all more or less unmaintained, as they're not part of dog-fooding by building daemon around it, which seems crucial for survival.
e.g. https://github.com/Nat-Lab/libbgp https://github.com/jeanmichel-gh/bgp4r https://github.com/wladwm/zettabgp (many many other, but none, afaik, anywhere near maturity of any of the daemons we've discussed) On Tue, 9 Jun 2026 at 07:54, Raymond Burkholder via NANOG <[email protected]> wrote: > > On 2026-06-04 01:59, Saku Ytti via NANOG wrote: > > 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. > > You may not think of them like Internet APIs, but there is a kind of > tightly bound library access to FRR: > https://docs.frrouting.org/projects/dev-guide/en/latest/library.html > > FRR does have some hooks for customization. It also has a Lua scripting > interface: > https://docs.frrouting.org/projects/dev-guide/en/latest/scripting.html > > There is an ability to add your own callback hooks, command line > additions, ... and other stuff. > > Link State API > https://docs.frrouting.org/projects/dev-guide/en/latest/link-state.html > > Northbound API > https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northbound.html > > Zebra Neighbor API > https://docs.frrouting.org/projects/dev-guide/en/latest/zebra-neigh-api.html > > Mind you, all this access probably requires you have the FRR source code > open, but given the complexity of the daemons and networking in general, > this access is probably as close to API as possible. > > > 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. > > https://docs.frrouting.org/projects/dev-guide/en/latest/fuzzing.html > > > So please, the next person planning to write BGP or whatever project > > they're thinking of, separate the logic and daemon. Thank you. > > > I'm not an FRR developer, just a satisfied user with a programming bent. > > Raymond Burkholder > https://blog.raymond.burkholder.net/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/FHTU5M5OFXXJ4S3SLIFWSNH4AM4BUJJ4/ -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/7N5YRSSKNDVC6M2OHE2546NKD7KG2E7H/
