Hello again Maria! Sorry for the sliced talk. I've just watched the video you posted! Congrats! Watching that, I reminded of two topics that I feel to be relevant to mention here. a) Could you please talk a bit more about the cgroups recommendation you have made? P.S.: I feel that this can be related to the use BIRD in containers(maybe dockers) that I think can be a good future to BIRD. b) About the non-blocking reconfiguration. A couple months ago I was chatting with a friend about how using conf files splitted and with includes can be a good way to avoid miss configurations. Mostly when you have a tem working on that config, and also part of that configuration been generated by automatic mechanisms. During your talk(on video) I thought that splitting conf files, mostly variables like prefix-list and AS-Path Regex that are unique by each peer, cloud be a way to reduce the workload of parsing configs on reconfiguration. Imagine a file with several prefixes that did not changed since last reconfiguration... Why spent clocks re-parsing it? Maybe keeping the already parsed files with a stamp of "this was good last time was checked". Yes, I Know that most of those included conf-files has interdependent variables. But, maybe, with the correct definition of how would need to be limitation of contents of a partial config file to enjoy the "feature" of economic-reconfig, this could be efficient. Em qui., 26 de mai. de 2022 às 17:52, Maria Matejka <maria.matejka@nic.cz> escreveu:
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
-- Douglas Fernando Fischer Engº de Controle e Automação