Hello, I understand your pain, implementing an API and all the bindings is indeed a very tedious and unrewarding work. Also I agree with your point about HTTP, it is a bit scary to have it directly in a daemon such as a routing software.
I think one very important point when defining an API is stability. Every API function needs to be designed as much as possible to avoid incompatible changes in the future. I won't tell names but in some commercial routers from popular vendors we use, it happens regularly that some API are changed in a backward incompatible way with new OS versions (field names are changed, value type are changed from single value to array, and other things). It is a pain to use, you have to get the OS version first and manage every possible case and retest everything for every new version. So, sadly, at the end of the day using the CLI text output is easier and actually more stable. > Note: We have to refactor the nexthop implementation quite heavily soon This is interesting. I understand the refactor work will happen after EVPN is released? Do you have some idea of what you would like to do already? Thanks. -- Sébastien ________________________________________ De : Maria Matejka <[email protected]> Envoyé : samedi 6 septembre 2025 12:59 À : Douglas Fischer Cc : Alexander Zubkov; David Petera; Sébastien PARISOT; BIRD Users; Ondrej Filip Objet : Re: Display BGP gateway mode in show protocol output Vous n’obtenez pas souvent d’e-mail à partir de [email protected]. Pourquoi c’est important<https://aka.ms/LearnAboutSenderIdentification> Hello! On Sat, Sep 06, 2025 at 07:19:54AM -0300, Douglas Fischer wrote: * In the time I’ve been following the list, I remember several times the conversations pointed to the direction of netconf/yang. We expect to implement a superset of a subset of coreconf/yang. There might be a possibility to attach a netconf-coreconf or restconf-coreconf intermediate, yet we don’t expect implementation in the daemon itself because of performance reasons. * I also remember a mention of a no-go for gRPC and gNMI, but I don’t remember the details. The main problem with API is the internal binding and data gathering from the internal structures. That’s either a tedious error-prone manual labour, or a tedious binding specification, or both, all with uncertain performance outcome. The other part is HTTP, which is the transport layer under gRPC (and gNMI). That is something we don’t like having inside a routing daemon, and the more I’m reading Daniel Stenberg’s blog, the more I’m convinced that we should never allow HTTP inside BIRD. * I also remembered https://github.com/pawelmaslanka/RoutingConfigApi . I confess I didn’t analyze anything, but I think it deserves a mention. Haven’t yet studied but it’s in the queue. Even though JSON and gRPC are somewhat forbidden topics here, I’d like to ask if they ever considered using LSP (which isn’t the MPLS LSP, haha). Language Server Protocol. I was close to a project where a friend who used LSP transformed a specific software API into something almost like its own CLI, with smart autocompletes and other very advantageous features from the operator’s perspective. I’m completely unaware of that. Could you please provide a link to that thing doing that with API? What I could find by quick search, was just smart programming language autocompletion. What about adding a selector to show only certain kind of “something”. “Something” - because there is no actual way to show channels, and a protocol can contain mixed channel types, so we cannot filter “show protocol” by channel type. But I think it is possible to add a selector for routes to see only direct/recursive ones. If we cannot mark them in the output because of the compatibility, we can at least select only certain kind to know who is who. I think it could be even not “show route …” selector, but some route attribute to be used in a filter. Maybe being able to understand the kinds of the routes would work for Sébastien too? Yes, adding a route selector this way should work; in BIRD 3, you may probably ask by a filter like where defined(hostentry) but I’m not sure whether this attribute is actually exported to filters in any way. If not, this may be quite an “easy” update to filter/f-inst.c for both BIRD 2 and 3, worth contributing. Note: We have to refactor the nexthop implementation quite heavily soon; with the upcoming EVPN support there are things getting much more hacked in than before, and we are slowly but surely converging to maintenance hell. There is still an awful lot of work to do on BIRD, and as I said at RIPE 90, one can’t expect anybody to contribute “externally” a large-scale refactoring needed to implement things well, because that work needs coordination, time, flexibility and very high frustration tollerance. Hoping that this helps. Maria – Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
