Babel: Clarifications on seqno request handling in bird

[dxld at darkboxed.org]

Hi Ondrej, Toke, Juliusz and lists,

I'm working on v4 of my bird route selection patch[1] and I just have a
couple babel spec and bird implementation questions.

[1]: http://trubka.network.cz/pipermail/bird-users/2023-January/016621.html

Just a quick recap for anyone not following my "Replace internal route
selection" patch: the idea is to install every feasible route into the bird
core and let it give us a callback (rt_notify) with the optimal route it
picked instead of doing this in the babel protocol.

As Toke noted up to my v3 patch I break sending seqno requests when we
loose the last feasible route (RFC8966 section 3.8.2.1.) because I
accidentally removed the code which deals with that together with the
babel_select_route function.

To fix this I tried to move that code to our rt_notify callback instead. In
testing I've found a major problem with this approach however. Say the
babel proto is currently exporting a route to the core, then a more
preferred route is exported by some other protocol (say "static") and then
the babel route expires.

In this case we ought to send a seqno request when the babel routes go away
but rt_notify doesn't get called since the selected (static) route didn't
change at all.

I don't think RFC8966 is really framed in bird's "multi protocol" mindset
so it's unclear to me whether this is something we have to fix or
not. Section 3.8.2.1. says:

> A node that has lost all feasible routes to a given destination but still
> has unexpired unfeasible routes to that destination MUST send a seqno
> request;

I could for example read this as the above mentioned static route
constituting a feasible route received from a bird "internal" babel
neighbour which would make the behaviour described above perfectly fine,
no?

@Juliusz what's your opinion of this interpretation? Any suggestions on how
to deal with this?

@Bird folks: can anyone think of a way to be notified of any and all
changes in rt_notify? I assume it's not possible from some light reading of
the nest code but figured I might as well ask.

If all else fails I can reinstate parts of the babel proto internal route
selection or try to simply count available feasible routes instead of doing
the full selection, just want to keep things as simple as possible.

--

Further, looking at the code implementing RFC section 3.8.2.2 in
babel_handle_update:

    if (!feasible && (metric != BABEL_INFINITY) &&
        (!best || (r == best) || (metric < best->metric)))
        /*^ */
      babel_generate_seqno_request(p, e, s->router_id, s->seqno + 1, nbr);

It's unclear to me what the (!best) condition corresponds to from the RFC
text. The r==best check clearly corresponds to "... when it receives an
unfeasible update for a route that is currently selected" and (metric <
best->metric) is for "... that is preferable to the currently selected
route". But why do we always send a seqno request when there isn't a
selected route when that isn't called for in the RFC?

Thanks,
--Daniel