BIRD Journey to Threads: Chapter zero of a blogpost series

[Maria Matejka]

Hello!

On 3/15/21 6:07 PM, Douglas Fischer wrote:
> That part about "Filter Rework" made me a bit anxious!
> I don't know exactly means the part:
>   "we decided to preprocess the filter internal structure to another 
> structure which is much easier to execute"...
> But, to me, it sounds like fragmenting, even more, the "test, mark, and 
> actuate" on the filters... Right?

This is a work that has been already included in v2.0.x for x ≥ 4 as far 
as I can remember. The filter is simply converted (in config time) from 
an infix structure with lots of pointers to a stack-oriented postfix 
bytecode.

That bytecode is somehow similar to Lua. We also thought about using Lua 
itself as a filtering language, anyway we had problems with Lua stack 
initialization. A simple run of an empty filter took at least 2 us on 
our testing machine, compared to 35 ns of our empty filter.

> Talking about BGP, I love Bird because only with it I know how to do 
> what I call "2 cycles filtering"...
> 
> - I create several Small Tests, where each route is tested and marked 
> somehow...
> - On each Peer-Type, import or export(but mostly on import), and I 
> define which tests will be called to be executed on that route, and live 
> their mark on each route.
>    - I here I test, Mask-lenght, AS-Set, AS-Origin, AS-Path, 
> foreigner-communities, internal-communities, a lot of Regex, and all 
> those multiple complex things...
> - And at the end of the filter-police I do an "IF" that tests on a 
> combined And+Or the marks lived by the previous tests, and based on that 
> do the accept, reject, add-communities, adjust MED/Local-Pref/Etc...

This stays the same, the filter language didn't change, we just reworked 
the interpreter. To add to this, there are also custom route attributes. 
It is quite common to do the small test on import, store the results to 
BGP communities, decide on export based on them and then filter them 
out. For this use, you can define your own route attributes and you 
don't mess with the communities at all. (And these are also faster than 
community list manipulation.)

We are thinking about more filtering features like iterating over the 
community lists or multipath nexthops. Don't worry, the filters are 
going to stay the same or better.

Thank you for your input!

Maria