<div dir="ltr">Ooowwww!<br><br>I've read this 2 times... And it was a lot confusing to me!<br>I can't even imagine the day-to-day of dealing with it...<br><br>I will read that again in a couple of days and reprocess it.<br><br>Thank you very much for your big effort!<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 26 de mai. de 2022 às 17:52, Maria Matejka <<a href="mailto:maria.matejka@nic.cz">maria.matejka@nic.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On 5/26/22 3:48 PM, Douglas Fischer wrote:<br>
> Hello all!<br>
> <br>
> Any news from the front of version 3?<br>
<br>
TL;DR: We're working on it, there is a lot of heavy lifting done and <br>
another lot of heavy lifting still to be done.<br>
<br>
You can also watch my RIPE 84 talk from last week here:<br>
<a href="https://ripe84.ripe.net/archives/video/748/" rel="noreferrer" target="_blank">https://ripe84.ripe.net/archives/video/748/</a><br>
<br>
DISCLAIMER: We don'ŧ promise anything specific, this is a work in <br>
progress and may change without any notice. I'm writing this summary not <br>
only for you (and the list) to know what is in the queue, but primarily <br>
for myself to have something for future to look behind and roll on the <br>
floor laughing how naïve I was in May 2022. And also to remind myself <br>
that I should first write down all the planned work before really <br>
estimating the time needed.<br>
<br>
Anyway, here is the current state dump, written from my perspective.<br>
<br>
Once upon a time, there was a version 3.0-alpha0 which has been released <br>
and found broken soon afterwards. It has three major flaws which we know <br>
about right now:<br>
<br>
1. it can't be easily merged with version 2.0.9<br>
(I tried to do it, believe me, it is impossible.)<br>
<br>
1A. so let's create the next version 3 by merging its commits into 2.0.9 <br>
by short intervals and fix what is broken by these merges [IN PROGRESS]<br>
1B. something in the original branch looks weird, let's do it better as <br>
we now know the goal better [IN PROGRESS]<br>
1C. some of these changes deserve to be merged back into the 2.0.x <br>
branch to avoid future merge conflicts [IN PROGRESS]<br>
1D. oops, now there is the commit with original import/export table <br>
rework which I don't want to merge at all [jump to 3].<br>
1E. dozens of following commits to be merged and fixed [PENDING]<br>
<br>
2. MRT dumps are insecure and will crash your BIRD [PENDING]<br>
(Found out during some internal team call after the release.)<br>
<br>
2A. needs a special service layer<br>
2B. this has to wait until tables are properly threaded<br>
2C. it is better to wait for BMP to be merged to do multithreading of <br>
both of these monitoring services at once<br>
<br>
3. calling ROA check from a filter in 'show route' crashes BIRD.<br>
(Reported by DE-CIX soon after release. Thanks for testing!)<br>
<br>
3A. this is due to lock ordering violation<br>
3B. we wanted to rework the show route anyway to not lock the table <br>
while formatting the route, so let's do it [PENDING]<br>
3C. but there is also a significant performance problem in channel <br>
auxiliary tables (import / export) – the original rework made them more <br>
of a full-size table, which adds lots of unwanted overhead [PENDING]<br>
3D. in fact, the import table may be done by storing the pre-filter <br>
route attributes "under" the actual attributes; filter modifications <br>
would create an overlay over the original route attributes [PENDING]<br>
3E. the export table also deserves some rework and it would help <br>
performance a lot [PENDING]<br>
3F. well, it would be less work in total to first do the import / export <br>
table rework and then the show-route rework [PENDING]<br>
3G. the current route attribute implementation is a two-layer mess <br>
originating in version 1 where everything was an IP route, let's squash <br>
these into one layer [IN PROGRESS]<br>
3H. also the nexthop resolving procedures and flowspec validation <br>
procedures kinda suck, let's make them more obvious, transparent and <br>
thread-friendly [IN PROGRESS]<br>
3I. well, also the current "extended" attribute layer doesn't scale <br>
well, let's fix it [IN PROGRESS]<br>
3J. and finally also the type-value structures are different in filters <br>
and attributes, let's fix it [IN PROGRESS]<br>
<br>
The appropriate branches are (named in a weird way, as common):<br>
* haugesund --> this should become the -alpha1, shouldn't rebase<br>
* haugesund-to-2.0 --> this should merge into 2.0.x soon, code review <br>
and other feedback pending, rebases may occur when some bug is found to <br>
fix the original commit rather than adding a fix commit<br>
* haugesund-types --> here the 3A-3J is being done, it is my working <br>
branch and it receives rebases every other day<br>
<br>
It's quite a lot of work but still just a little compared to the amount <br>
of work needed before to get -alpha0 to release. Most of the tasks <br>
depend on the previous ones deeply so it will still take several weeks <br>
until something can be offloaded. For now, these branches are quite a <br>
one-woman-show (I don't like that).<br>
<br>
Out of the spotlight, Santiago has fixed several bugs in v2.0.9 and <br>
there may be v2.0.10 fixing these bugs soon. He's also preparing BMP to <br>
be merged for v2.0.11, AFAIK.<br>
<br>
I hope you aren't too scared by all of this. There is just some <br>
technological debt and quirky implementations of later features and <br>
after releasing 3.0-alpha1, I hope for no more major flaws.<br>
<br>
Live then happily ever after!<br>
<br>
Maria<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>