Hello all!
There are many cases when the filter reads an undefined route attribute.
We have several variants how to behave then, all of them have their pros and
cons.
The current behavior is inconsistent and sometimes strange.
Variants we thought about when an undefined attribute is to be read:
1 the filter fails with an error.
2 the value is set to default (zero or whatever) and then used
3 it is propagated as undefined until any comparison/match happens,
then the comparison/match is always false
What can happen then?
We thought about several use cases. Let's assume there is a route without the
ospf_metric1 attribute.
A (in config) import where ospf_metric1 > 10;
B (in config) import where ! (ospf_metric1 > 10);
C (in config) import where check();
function check() { if ospf_metric1 > 10 then { return true; } else {
return false; } };
D (in config)
function update() {
if defined(ospf_metric1) then { return; }
if ospf_metric1 > 10 then { bgp_path.append(myasn);
bgp_path.append(myasn); }
}
E (in cli) show route where ospf_metric1 > 10
F (in cli) show route where ! (ospf_metric1 > 10)
We think generally that:
Variant 1 may work in config as the admin shall write the filters correctly but
it is too strict
when it comes to CLI ad-hoc filters.
Variant 2 is used now for BGP communities lists where the default is empty
list. In other cases,
the behavior is undefined. It is convenient as far as the default fits your
purposes. Then it becomes
almost the same as variant 1.
Variant 3 is simple and convenient until you negate the condition. Note that
the following two lines
would do different things:
where bgp_med != 201
where !(bgp_med = 201)
We do not know which variant of filters behaviour is the best. We'd like you
to think about your use cases for Bird's filters and contribute to this thread
with your opinion. Also feel free to suggest other behavior variants if you
think out some.
Thank you!
Maria
