Hi Vincent, Erik and the list,

long story short, we have had other fish to fry, and the SRv6 is a hard thing to integrate smoothly. Specifically, while it’s often possible to implement whatever into BIRD which works for that specific purpose, at the same time, it is often not acceptable for a general release.

On Mon, Aug 03, 2026 at 08:32:20AM +0200, Vincent Bernat via Bird-users wrote:

On 2026-08-02 23:27, Erik Stomp via Bird-users wrote:

I’m currently experimenting with Segment Routing and was curious If there are any plans to support Segment Routing with BIRD. I found a message from Matyáš Kroupa on this mailing list regarding his diploma theses and he gave a talk at this years CSNOG.

As the talk is in Czech, I’m struggling to understand it. Are there any public available information about his work (maybe a development branch) or current plans to merge his implementation to the official code of BIRD?

Sébastien Parisot posted a working implementation of SRv6 (https://bird.network.cz/pipermail/bird-users/2026-February/018650.html), but unfortunately, it did not generate much interest. There was also a mention of another existing implementation but no code (https://bird.network.cz/pipermail/bird-users/2025-September/018390.html).

Generally there are several major problems of getting any implementation into upstream BIRD:

  1. Code review from the maintainers is the immediate cost. We’re trying to prevent most problems by reading the code and assessing whether it actually fits well with the overall architecture, and thinking about possible corner cases when integrating with other parts of BIRD, even in weird scenarios.

(1A) Sometimes, and SRv6 is definitely the case, the maintainers have to sit down in the meeting room for a long period of time, and have a thorough discussion about the semantics of all the things involved, so that a corner case bugfix wouldn’t cause a half-rewrite.

(1B) I’ve skim-checked some of the earlier SRv6 communication, and there is an obvious collision with at least one internal API / architecture rework pending, which is the local next hop storage. This is needed for EVPN anyway, and it will happen soon. With that, I would say that literally anything touching the next hop structure is a no-go until we fix that. And that’s blocked by another internal rework, which is the filter type system refactoring. It’s in my plan for the upcoming months, let’s see how it goes.

  1. Test suite coverage and overall maintenance adds to the long-term costs. Not only one has to run more CI jobs with more features, that would be acceptable, but one has to create the CI jobs, get them right, and whenever updating the underlying test suite, also convert the jobs.

  2. When something new is about to be added afterwards, this implementation needs to be taken in account. While BIRD is pretty well compartmentalized now, it may stop being the case as soon as people cross the boundaries and invent new ad-hoc APIs and update common data structures.

As we write in our contributions document, we’d like people to communicate before they start implementing larger things, as we often have some architectural insights which are neither documented nor inferrable from the source code itself. We’d like to document these insights but it’s hard to dump this knowledge and then maintain it, so that it doesn’t get rotten, as the programmer’s doc kinda is now.

The implementation of BGP auto-spawn based on received router advertisements is a good example of just this. The author messaged us upfront, we discussed the overall architecture, and the feature got upstreamed pretty fast. There were still several hiccups which we couldn’t foresee, but it was way smoother than when somebody sends a full-blown implementation out of the blue.

I hope this helps.

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