Display BGP gateway mode in show protocol output

[Maria Matejka]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250906/a624406c/attachment.htm>