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