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 <[email protected]> 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
