Hi Alexander, David and Sébastien! Sorry to butt in on this, but this is a topic that really interests me. Again, just to give you some context, I'm not a programmer! Just a lazy network operator (in a good way) who sometimes tries to build his own tools to make his life easier. About the patch brought by Sébastien I learned a while ago (the hard way) that parsing outputs is the worst way to interact with other software. And even though it's terrible, sometimes it's the only way we have left. I don't think attaching too many things to birdc right now is wise, but I understand your pain. David, Maria, Ondrej I've been hearing about initiatives in this work regarding the BIRD API. I think the place I see this mentioned most often is on Alice-LG. But I end up not seeing anything in detail about it because I don't have the time I'd like to dedicate to learning by reading code from projects like Bird. I'm wondering how this is being planned, and I imagine other lay people like me are also curious about it. So I decided to ask if the BIRD team could tell me more about this. - In the time I've been following the list, I remember several times the conversations pointed to the direction of netconf/yang. - I also remember a mention of a no-go for gRPC and gNMI, but I don't remember the details. - I also remembered https://github.com/pawelmaslanka/RoutingConfigApi . I confess I didn't analyze anything, but I think it deserves a mention. - And briefly, I remembered that every time XML or JSON was mentioned, Eustace Bagge appeared here on the list. lol. 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. Thank you in advance. Em sex., 5 de set. de 2025 às 14:09, Alexander Zubkov via Bird-users < bird-users@network.cz> escreveu:

Hi all!

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?

Regards, Alexander

On Fri, Sep 5, 2025, 16:04 David Petera via Bird-users < bird-users@network.cz> wrote:

...

Hello Sébastien!

Thanks for sending us these patches, but unfortunately it would *not* be wise to change BIRD's CLI output right now.

We discussed it in our team and the the primary reason is this:

Since BIRD does not yet have well defined API for communication, most automation and tooling around BIRD (including our own) relies on the exact format of the CLI output. These changes would/could break the tooling around BIRD and cause lot of headache for little gain.

We know that this situation is not ideal and thus API for BIRD is being worked on. Once finished we can improve the CLI output without major consequences.

Hope you understand, why we can not accept these patches right now.

Wish you a great weekend and happy routing! David

David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o.

On 8/25/25 14:35, Sébastien PARISOT wrote:

Hello BIRD team!

This simple patch (for branch master) adds a field for the BGP channel gateway mode (direct or recursive) setting in show protocol output. It is is a useful information to have in some troubleshooting scenario.

Example:

bird> show protocol all bgp_test Name Proto Table State Since Info bgp_test BGP --- up 2025-08-12 15:11:54 Established BGP state: Established [...] Channel ipv6 State: UP [...] Gateway: recursive [...]

Thanks! -- Sébastien

-- Douglas Fernando Fischer Engº de Controle e Automação

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 <maria.matejka@nic.cz> 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 maria.matejka@nic.cz. 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.

Thanks for the information, this makes a lot of sense. -- Sébastien ________________________________________ De : Ondrej Zajicek <santiago@crfreenet.org> Envoyé : lundi 8 septembre 2025 16:20 À : Sébastien PARISOT Cc : Maria Matejka; Douglas Fischer; BIRD Users Objet : Re: Display BGP gateway mode in show protocol output On Mon, Sep 08, 2025 at 09:30:28AM +0000, Sébastien PARISOT wrote:

...

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?

We would like to have 'nexthop' as an attribute, with some way of having multiple instances of the attribute (for ECMP), while the body of the attribute will be a list of sub-attributes (for iface, gw, encapsulation, MPLS stack ...), similarly how Linux Netlink is doing that. In the current situation, we store EVPN forwarding entry VXLAN remote address in a gateway field, which is a semantic abuse. Also, it prevent us to implement different encapsulations to L3VPN as we have no place to store encapsulation data for each nexthop. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."

Hello Douglas! On Mon, Sep 08, 2025 at 08:47:46AM -0300, Douglas Fischer wrote:

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

That's, in the end, another good reason to stick to one single API method suited for our most demanding customers (hello IXPs!) … and for everybody who needs something more human readable while being still parseable, there may be an intermediate layer. Yet please note that esp. encoding IP addresses in the intermediate layers has always been an awful mess, so the intermediate layer may happen to behave non-intuitively when some conversions happen.

Another point that came to mind is the use of BIRD in Kubernetes CNI environments. I remembered Calico using BIRD 1.6[1]. [...] [1] P.S.: Does anyone have any information on whether Tigera has commented on this? Did they look for newer versions?

I have seen literally no communication from them ever and I have stopped trying to reach out to them. All in all, it's valid to use old unsupported versions if that does what you want. I personally occasionally play abandonware games as well.

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.

I would very much say that one should simply always compile the new config file and run `birdc conf`. BIRD does its comparison internaly and if the config file isn't like a gigabyte or so (hello IXPs again), this is very fast. There are also some efforts to extend the API also to configuration but please do not expect it in near future unless somebody really throws a bunch of money on that and much more. This is a really big fish to fry. Have a nice day! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

On Mon, Sep 08, 2025 at 09:17:17AM +0000, Sébastien PARISOT wrote:

Hello David,

To be honest I expected this kind of answer for the first 2 patches :) I thought this one would be ok as it only adds a new field/line in the output and do not touch the existing output, but sure I understand. Relying on text output is always fragile and any change is risky.

Hello You are right, this is more an answer for the first 2 patches. We are generally okay with adding a new line to 'show protocols all' from the compatibility point of view. But our rule of thumb here is that we do not want to add a line here that is purely configuration data without a good reason, as this command should mainly show runtime data. People could argue that half of BGP configuration options are important enough to be shown here and we would like to avoid adding them all, especially when these command outputs are manually implemented. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."

Hello Łukasz, On Mon, Sep 08, 2025 at 04:24:33PM +0200, Łukasz Jarosz wrote:

Would like to chime in with my two cents about remote control. IMHO, BIRD should have standardized (or at least well documented) protocol for control, so anyone can implement "birdc" alternative as they see fit.

This is indeed our intent with the API efforts. Yet, making it useful, complete, well-performing and most notably long-term maintainable, is on the harder part of the scale. With that, there is some internal tooling work on the way (because people around Netconf didn't bother to think about performance, let aside maintainability) and as soon we have this, at least an experimental API is gonna be there quite fast. The actual tooling is UYTC YANG To Code which should enable you to create local specification aligned with a local YANG file, and then generate well-performing encoders and decoders to be included within your app. And with that, in the end, we expect to ship BIRD with a Python package exporting actually full-blown route objects and protocol objects instead of parsing the CBOR / JSON / XML. I hope this explains our plans well. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Hola!

...

With that, there is some internal tooling work on the way (because people around Netconf didn't bother to think about performance, let aside maintainability) and as soon we have this, at least an experimental API is gonna be there quite fast.

The actual tooling is UYTC YANG To Code which should enable you to

Doing google (not the best for this atm) on "UYTC YANG To Code" returns a I mistyped this it must be UTC YANG ... the rest of the returned data is utterly garbage , Is there a url for this tooling you speak of ?

Well, there is just a git repo with pieces of code in a very being-worked-on state. Not much to actually see for now, there are just several branches of dirty python code for now. https://gitlab.nic.cz/labs/uytc/ Yet, this thing is, in the end, going to have a module for creating C code. But first we have to digest through all the funky RFCs around YANG, CBOR and whatever else blocks us, including drafting some new stuff, to make everything actually fly the reasonable way. Once, Donald E. Knuth said: »So, I just have this philosophy that there will be always some people who are more interested in quality than others, and I wanted to make TeX good for them.« (pg. 349 https://www.tug.org/TUGboat/tb17-4/tb53knun.pdf) And we wanna make this right, and minimize the oversights which would be too late to fix later. The original architecture of BIRD was good for 20 years, saved us a lot of hair, and many parts of it are actually still there. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Hi everybody, This thread has awaken some evil thoughts I have had since long ago. I know this might be forbidden here, but still, I could not sleep well until I did it. Please don't beat me for that. :) So here is the patch (applies to "thread-next" branch). It is definitely ugly, ineffective, untested, requires a lot of polishing, etc. It was mostly created as a proof of concept for now. It seems to be working at least on my simple tests with device, kernel, pipe, bgp protocols. With it you can send "json protocols" command and get a dump of protocols in JSON. It also adds "-q" option to cli to hide the "BIRD ..." header, so you can do things like: $ ./birdc -q "json protocols" | jq '.protocols.bgp1.Channels.ipv4["Gateway mode"]' "recursive" I know we all long for a great API to come. But unitl that we sill have to parse the text cli output. So why not to parse for example JSON isntead? :) It is safer to extend and not to break compatibility with text parsers. This and other benefits are mostly well-known. Of course it is ugly piece of code added to the codebase, that needs to be maintained, etc. All the minuses has also been well described here already. Anyway, I do not expect it to be included upstream, just had some strange need to do this coding exercise. :) On the other hand if it looks appealing, I can polish/improve it if needed. Also "routes" variant could be added. Any feedback is welcome! And I can give more comments on the contents, of course. PS. Also another idea has come to my mind. What BIRD team think about introducing a practice of adding experimental features, i.e. those that have no guarantee to remain compatible between versions, or to remain at all. It is often said that adding new features is a hard process because they need to be maintained, harden merges between versions, need thourough study right away because further redesign can break compatibility. So I think calling it experimental and giving yourself an opportunity to "undo" it, could break the tie and give some "sandbox" for the feature to mature or perish. PPS. I'm not advocating my json patch with that idea. :) Regards, Alexander On Wed, Sep 10, 2025 at 1:02 PM Douglas Fischer <fischerdouglas@gmail.com> wrote:

https://gitlab.nic.cz/labs/uytc/-/blob/dirty/examples/00_leaf/expected.outpu... 😍

Em ter., 9 de set. de 2025 às 20:56, Maria Matejka via Bird-users < bird-users@network.cz> escreveu:

...

Hola!

With that, there is some internal tooling work on the way (because people around Netconf didn’t bother to think about performance, let aside maintainability) and as soon we have this, at least an experimental API is gonna be there quite fast.

The actual tooling is UYTC YANG To Code which should enable you to

Doing google (not the best for this atm) on “UYTC YANG To Code” returns a I mistyped this it must be UTC YANG … the rest of the returned data is utterly garbage , Is there a url for this tooling you speak of ?

Well, there is just a git repo with pieces of code in a very being-worked-on state. Not much to actually see for now, there are just several branches of dirty python code for now.

https://gitlab.nic.cz/labs/uytc/

Yet, this thing is, in the end, going to have a module for creating C code. But first we have to digest through all the funky RFCs around YANG, CBOR and whatever else blocks us, including drafting some new stuff, to make everything actually fly the reasonable way.

Once, Donald E. Knuth said: »So, I just have this philosophy that there will be always some people who are more interested in quality than others, and I wanted to make TeX good for them.« (pg. 349 https://www.tug.org/TUGboat/tb17-4/tb53knun.pdf)

And we wanna make this right, and minimize the oversights which would be too late to fix later. The original architecture of BIRD was good for 20 years, saved us a lot of hair, and many parts of it are actually still there.

Maria

– Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

-- Douglas Fernando Fischer Engº de Controle e Automação

Hello Ondrej, I see your point. I do think every configuration option should be displayed in the show commands though, it makes it easier to find their value instead of searching the configuration file and documentation for default values. I think it can also help to spot bugs if somehow a runtime value does not match the value from the configuration file (should be pretty rare, but maybe it can happen it something is missing on the reconfiguration code?). But yes I agree it is cumbersome to implement manually given the number of configuration options. For the gw mode specifically, I added it because its default value depends on an other configuration variable (multihop), so it may not be obvious from the configuration file what value it actually is if one forgot about that. Thanks for the feedback. -- Sébastien ________________________________________ De : Ondrej Zajicek <santiago@crfreenet.org> Envoyé : lundi 8 septembre 2025 16:08 À : Sébastien PARISOT Cc : bird-users@network.cz; David Petera Objet : Re: Display BGP gateway mode in show protocol output On Mon, Sep 08, 2025 at 09:17:17AM +0000, Sébastien PARISOT wrote:

Hello David,

To be honest I expected this kind of answer for the first 2 patches :) I thought this one would be ok as it only adds a new field/line in the output and do not touch the existing output, but sure I understand. Relying on text output is always fragile and any change is risky.

Hello You are right, this is more an answer for the first 2 patches. We are generally okay with adding a new line to 'show protocols all' from the compatibility point of view. But our rule of thumb here is that we do not want to add a line here that is purely configuration data without a good reason, as this command should mainly show runtime data. People could argue that half of BGP configuration options are important enough to be shown here and we would like to avoid adding them all, especially when these command outputs are manually implemented. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."