Hello!
On 2/28/23 13:13, d...@darkboxed.org wrote:
Hi Toke,
On Tue, Feb 28, 2023 at 12:20:22PM +0100, Toke Høiland-Jørgensen wrote:
I've thought about this some more, I think we absolutely shouldn't expose
the smooted metric to filters. It's an implementation detail. There's a
bunch of other valid ways to implement this sort of dampening/hysteresis no
reason to expose it to filter users really.
How would you even use this for any practical filtering anyway? Reject
routes based on `smoothed_metric - metric > threshold` or even better,
increase metric based on smoothed_metric difference (oscillations galore
haha). Hardly seems useful to me :)
AFAICT it's perfectly fine to have EAs that filters can't access though,
that's the situation we're currently in for the router-id after all so
that's not really a blocker.
My thinking was that filters may want to do something like:
if (metric == smoothed_metric)
metric += 100; /* route is stable, we can apply our policy */
but I honestly don't know if that's useful for anything in reality :)
Hmm, I suppose that is a valid use-case. I'd rather expose a boolean flag
for that rather than the smoothed metric itself.
There is also some internal discussion in the core BIRD team about the
sole principle of exposing or not exposing protocol-internal attributes.
One side of this discussion says that by exposing internal attributes,
we lock ourselves inside that specific implementation and can't simply
change it to some else where such internal attributes make no sense at all.
The other side says that users should get all the possibilities to
customize what they want, log these values from filters, consume all
their memory and CPU and shoot their own leg if they wish.
That said, expose whatever you think is useful. We haven't decided yet.
[...]
I think you're looking at this from the wrong angle. By not having a
smoothed metric attribute we have to update to begin with we save on all
this timer logic that would constantly re-announce routes to core. This way
the number of core announcements stays exactly the same as before and we
don't really loose anything.
Only think I'm still missing is a way to reframe the metric smoothing
math such that I can install a timer for when the next scheduled route
update should go through, though perhaps polling in the global timer
hook is fine?
I think it's probably simpler to just re-announce any route that's still
converging every time we go through the routing table.
Simpler, yes, but I do want to be able to maintain internet scale routing
tables through babel eventually so slashing every little bit helps :)
In version 2, update of non-best route is propagated only to some
protocols like pipes, add-path BGPs and alike. In version 3, this is
even more smoothed as all updates of one prefix are exported
asynchronously to each protocol, being notified after your Babel ends
the task (event, socket, timer), dampening best route oscillation or
other flaps.
This way, I'm not so scared about Babel periodically updating many
routes. BIRD has to withstand it.
Maria
