Writing filters that change output depending on peer

[Nico Schottelius]

Good morning Maria,

you have a very valid point I haven't though about yet. You are right
that currently filters and functions can just be used in the CLI w/o a
"context".

And maybe that is also the answer as to how bird should behave: if no
"context" (or peer or whatever it will be named in the end) is supplied,
I think bird should behave the same as before.

And we can even formalise this a bit and update the previous
description:


    string proto_to_or_destination_or_better_name

           The name of the protocol in which the filter or function is being
           called in. Allows to match on the destination.

           Might contain the empty string, if the evaluated outside a
           protocol context.

Thus:



Maria Matejka <maria.matejka at nic.cz> writes:
> Let’s have a configuration like this:
>
> function foo() { return proto_to_or_destination_or_better_name = "bar"; }
>
> protocol bgp bar from yippie {
>   ipv6 { import where foo(); export where foo(); };
>   ipv4 { import where foo(); export where foo(); };
> }
>
> and some more irrelevant boilerplate, like the protocol device.
>
> Now, a bunch of more and more cursed questions because I have an evil mind.
>
> * CLI: show route export bar

proto_to_or_destination_or_better_name is unset -> false

> * CLI: show route where foo()

proto_to_or_destination_or_better_name is unset -> false

> * CLI: eval foo

proto_to_or_destination_or_better_name is unset -> false

Now comes a however: however it might be helpful then to add a context
alike syntax:

show route where foo() context proto bar

--> true

show route where foo() context proto foo

--> no routes

> * Conf: protocol bgp yay { require graceful restart ( foo() ); }

proto_to_or_destination_or_better_name is = yay -> false

> * Conf: template bgp yippie { require graceful restart ( foo() ); }

proto_to_or_destination_or_better_name is = yippie -> false


> * Conf: ipv6 table bastu { sorted ( foo() ); };

I'm not familiar with the sorted function, so no clue


> * Conf: function meow() { if foo() then return 1; else return 2; } router id ( meow() );

Same as above, depends on where meow() is called.

I think in the end, the actual value of
proto_to_or_destination_or_better_name should be handled similar to how
"net" is passed down:

- set inside a protocol ...{} context
- empty/unset outside of that context

> I hope that I haven’t botched the syntax, I’m too lazy to try it out. My questions are basically how BIRD would be expected to behave in these situations
> with this feature.

Hope that clarifies above.

> I’m not trying to down the requested feature, and I have a bunch of ideas how this kind of feature may actually behave and what should be implemented
> … but before I disclose that, I wanna see whether the community has
> something maybe better or easier.

Sounds reasonable!

> Thank you for opening this topic!

Thank you for being open and continuing to provide a great software!

Sunny greetings from Lachen SZ,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch