Support for machine-readable status output

[Pascal Mathis]

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