BIRD 3.0-alpha0

[Maria Matejka]

> 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.

Just a strong recommendation to make administrative measures to keep 
yourself able to maintain the machine. BIRD may spawn lots of threads 
and you probably don't want your SSH to become unresponsive. For 
illustration, a multitable route server configuration with 1000 peers 
spawns 3002 threads if I count correctly.

I don't know whether Docker is a good idea to run BIRD in, I neither 
recommend nor discourage it.

> 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.

First, this would need quite a substantial rework of config as we 
suppose that all data in config is allocated from one pool and when 
reconfiguration is finished, we dispose of them at once.

Second, I'm afraid this kind of constraint on what is allowed for 
include is be a can of really huge and disgusting worms. Maybe simply 
just the prefix trees, but …

… but third, there should be some extension of RTR-RPKI protocol to 
allow for this kind of data to be fed into a routing daemon externally. 
For now, we'd like to stick with this approach to get rid of these 
blocks of constants at all.

Hope this is a sufficient explanation for you.

Maria