Display BGP gateway mode in show protocol output

[Douglas Fischer]

Hello Maria!
Thank you very much for your thoughtful reply.

Even though I'm a layman, I can clearly understand the constraints and
difficulties the BIRD team is currently facing.

I completely agree with the option of not embedding an HTTP layer. That's
not the role of a routing daemon.

On the other hand, I see that there's no way to leave BIRD without enabling
this type of more standardized interaction with configurations and
monitoring. Which leads me to believe it makes sense to consider finding a
solution for this through a set of other software.
I know almost nothing about programming, but I see that in one way or
another, tools like ARouteServer, birdwatcher, pathvector, or
RoutingConfigApi... are already doing this, the hard way, but they do it.
I imagine it makes sense for there to be some kind of intermediate layer
that can be used by software like the ones mentioned.

Another point that came to mind is the use of BIRD in Kubernetes CNI
environments. I remembered Calico using BIRD 1.6[1].
I don't even know if they still use that version. But I'm willing to bet
that maintaining the legacy version has something to do with this parsing
effort.
If I understand correctly... They somehow use confd to retrieve the
necessary objects and attributes from etcd and assemble the bird
configuration. And in the same way, they cyclically compare these two
things to implement some configuration resync.

[1] P.S.: Does anyone have any information on whether Tigera has commented
on this? Did they look for newer versions?

Em sáb., 6 de set. de 2025 às 07:59, Maria Matejka <maria.matejka at nic.cz>
escreveu:

> 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.
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250908/2abc1276/attachment.htm>