I asked for this back in June 2017, but nothing has come yet ( https://bird.network.cz/pipermail/bird-users/2017-June/011356.html) On Tue, 28 Apr 2020 at 09:08, Kees Meijs | Nefos <kees@nefos.nl> wrote:
Hi Pascal,
In short: as a BIRD2 user I would like to add it's a (very) good idea you propose. Probably other users feel this as well.
Regards, Kees
On 28-04-2020 09:17, Pascal Mathis wrote:
Hi everyone,
I am wondering if the official maintainers would accept patches for introducing machine-readable status output to BIRD. I am asking as there definitely is a clear demand for such a solution, as can be seen by these previous mailing list posts and projects:
- https://github.com/mchackorg/birdwatcher (JSON API Server) - https://github.com/inex/birdseye (JSON API Server) - https://github.com/czerwonk/bird_exporter (Prometheus Exporter) - https://www.npmjs.com/package/node-bird-routeparse (JSON Generator) - https://bird.network.cz/pipermail/bird-users/2018-March/012088.html (Previous JSON patch submitted by Alistair Crooks) - https://github.com/sileht/bird-lg (BIRD LG with Python Command Proxy) - https://bird.network.cz/pipermail/bird-users/2017-June/011362.html (Previous mentions of people working on structured output for BIRD) - https://bird.network.cz/pipermail/bird-users/2011-September/002441.html (ML post showing support for JSON output)
All the current solutions mentioned above query BIRD by either running the "birdc" executable or directly interacting with the SMTP-like protocol on the socket, followed by applying regular parsing magic to extract the required information.
While this certainly works, I think adding some kind of structured/machine-readable output (e.g. JSON) would greatly simplify such integrations in the future and people would no longer have to rely on brittle text parsing which can break on any text formatting changes.
Compared to other routing daemons with massive API interfaces (e.g. NETCONF or gRPC), BIRD clearly follows a path of simplicity and robustness, which is probably a reason why a lot of people are relying on it. I personally think that adding a whole API interface for both reading and writing would be overkill, as the configuration can already be easily templated and reliably reloaded.
To cut a long story short, I would appreciate if BIRD2 would be able to output various sorts of information in a structured, machine-readable way, e.g. using JSON to print statistics, bgp peers, route lookups and more. This could be implemented by adding a flag for JSON output to existing commands, as adding a full-blown HTTP server directly into BIRD seems like a bad idea.
Would such patches be considered for upstreaming or was there ever a decision to not implement this kind of feature? Is maybe someone already working on a feature like this?
Thanks in advance for any kind of reply and have a nice day.
Best regards, Pascal