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.
