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