[PATCH 0/3] babel: Add support for the RTT extension

[Maria Matejka]

Hello!

On 2/28/23 13:13, dxld at 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