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
