BIRD 3.0-alpha0

[Maria Matejka]

Hello!

On 5/26/22 3:48 PM, Douglas Fischer wrote:
> Hello all!
> 
> Any news from the front of version 3?

TL;DR: We're working on it, there is a lot of heavy lifting done and 
another lot of heavy lifting still to be done.

You can also watch my RIPE 84 talk from last week here:
https://ripe84.ripe.net/archives/video/748/

DISCLAIMER: We don'ŧ promise anything specific, this is a work in 
progress and may change without any notice. I'm writing this summary not 
only for you (and the list) to know what is in the queue, but primarily 
for myself to have something for future to look behind and roll on the 
floor laughing how naïve I was in May 2022. And also to remind myself 
that I should first write down all the planned work before really 
estimating the time needed.

Anyway, here is the current state dump, written from my perspective.

Once upon a time, there was a version 3.0-alpha0 which has been released 
and found broken soon afterwards. It has three major flaws which we know 
about right now:

1. it can't be easily merged with version 2.0.9
(I tried to do it, believe me, it is impossible.)

1A. so let's create the next version 3 by merging its commits into 2.0.9 
by short intervals and fix what is broken by these merges [IN PROGRESS]
1B. something in the original branch looks weird, let's do it better as 
we now know the goal better [IN PROGRESS]
1C. some of these changes deserve to be merged back into the 2.0.x 
branch to avoid future merge conflicts [IN PROGRESS]
1D. oops, now there is the commit with original import/export table 
rework which I don't want to merge at all [jump to 3].
1E. dozens of following commits to be merged and fixed [PENDING]

2. MRT dumps are insecure and will crash your BIRD [PENDING]
(Found out during some internal team call after the release.)

2A. needs a special service layer
2B. this has to wait until tables are properly threaded
2C. it is better to wait for BMP to be merged to do multithreading of 
both of these monitoring services at once

3. calling ROA check from a filter in 'show route' crashes BIRD.
(Reported by DE-CIX soon after release. Thanks for testing!)

3A. this is due to lock ordering violation
3B. we wanted to rework the show route anyway to not lock the table 
while formatting the route, so let's do it [PENDING]
3C. but there is also a significant performance problem in channel 
auxiliary tables (import / export) – the original rework made them more 
of a full-size table, which adds lots of unwanted overhead [PENDING]
3D. in fact, the import table may be done by storing the pre-filter 
route attributes "under" the actual attributes; filter modifications 
would create an overlay over the original route attributes [PENDING]
3E. the export table also deserves some rework and it would help 
performance a lot [PENDING]
3F. well, it would be less work in total to first do the import / export 
table rework and then the show-route rework [PENDING]
3G. the current route attribute implementation is a two-layer mess 
originating in version 1 where everything was an IP route, let's squash 
these into one layer [IN PROGRESS]
3H. also the nexthop resolving procedures and flowspec validation 
procedures kinda suck, let's make them more obvious, transparent and 
thread-friendly [IN PROGRESS]
3I. well, also the current "extended" attribute layer doesn't scale 
well, let's fix it [IN PROGRESS]
3J. and finally also the type-value structures are different in filters 
and attributes, let's fix it [IN PROGRESS]

The appropriate branches are (named in a weird way, as common):
* haugesund --> this should become the -alpha1, shouldn't rebase
* haugesund-to-2.0 --> this should merge into 2.0.x soon, code review 
and other feedback pending, rebases may occur when some bug is found to 
fix the original commit rather than adding a fix commit
* haugesund-types --> here the 3A-3J is being done, it is my working 
branch and it receives rebases every other day

It's quite a lot of work but still just a little compared to the amount 
of work needed before to get -alpha0 to release. Most of the tasks 
depend on the previous ones deeply so it will still take several weeks 
until something can be offloaded. For now, these branches are quite a 
one-woman-show (I don't like that).

Out of the spotlight, Santiago has fixed several bugs in v2.0.9 and 
there may be v2.0.10 fixing these bugs soon. He's also preparing BMP to 
be merged for v2.0.11, AFAIK.

I hope you aren't too scared by all of this. There is just some 
technological debt and quirky implementations of later features and 
after releasing 3.0-alpha1, I hope for no more major flaws.

Live then happily ever after!

Maria