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
