Quick suggestion about enable/disable protocol

[Maria Matejka]

Hello!

>>> 1. Allow enable/disable to be part of the config, so that a 
>>> protocol can be disabled by default, and needs a manual poke via
>>>  CLI command to enable it.
> [...]
> 
>> This is already in config, use "enabled" and "disabled" keywords.
> 
> Aha! I didn't find that previously in the docs - of course now I can
>  see it. I did try "disable" as per the CLI command, but obviously 
> that slightly different directive doesn't work. Perhaps a note could
>  be added to the CLI docs to mention that it can be set 
> semi-permanently in the config?

Well, yes. Patches are welcome.

>>> 2a. When reloading config, preserve the current state of a 
>>> protocol that has been disabled. (I'm trying to debug a config, 
>>> which involves disabling
> [...]
> 
>> We don't like to change what BIRD does by default as it may confuse
>> others who aren't familiar with the changes and both variants of
>> behavior have their appropriate use. Yet we may consider something
>> like  a "keep protocol states" option to explicitly disable
>> protocol disabling/enabling on config reload.
> 
> Yes, I did intend to mean that it would be an option, rather than a 
> (potentially dangerous) change in default behaviour. For now, I'll 
> just try to remember to uncomment "disabled" in the block before I 
> start fiddling. :)

Fine, then we are on the same side. Or, it may be even better to make
this an option of the "configure" CLI command, as we already have the
"configure soft" which doesn't reload changed filters.

> Whilst I have your attention, there is one other thing that doesn't 
> seem to be explicitly mentioned in the docs: what happens when you 
> have multiple import/export filters listed for the one protocol? Does
> the first accept/reject win, and exit any further filter processing,
> or is there some other behaviour? Are the multiple filters evaluated
> in config order, or some other order?

I think only the last one is used and executed. The parser just doesn't 
care about previous filters and overwrites them. There are some plans to
allow filter chaining, yet for now, I suggest using functions instead.

> Initially I was trying to make separate filters for 0.0.0.0/0 and 
> x.x.x.0/24, for import and export via BGP respectively, and combine 
> them to allow both routes to be advertised locally (without needing a
> third filter)... but it doesn't work, possibly because both filters
> have an unconditional reject at the end.

Something like this:

function the_zero_route() { ... }
function the_other_route() { ... }

... export filter {
	if the_zero_route() then accept;
	if the_other_route() then accept;
	reject;
};

Maria