BIRD 3.0-alpha0

[Douglas Fischer]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220527/3712510b/attachment.htm>