This paragraph is not entirely clear to me. Do you mean that the neighbour on behalf of which we're forwarding the request has gone away?
Yes.
[...]
Oh, and the reason we don't need to keep track of all neighbours is that when we satisfy a request we just trigger a global (multicast) update for the prefix instead of sending it individually to all neighbours we forwarded requests on behalf of.
Right. Babeld does the same. But in that case, I don't understand why you need to keep track of the neighbour in the first place. I haven't looked at this code in some time, but I seem to recall that in babeld, we simply retain the information that there's a pending request, we don't need to know on whose behalf it's being made.
Hmm, right, well my reasoning was also that receiving an unfeasible update is not as "urgent" because we most likely have another route for the same prefix that is feasible already. Or is this intuition not correct?
Consider the case of a well-connected cloud that is connected to the source through just one router: B1 / | / | S ---- A --B2 \ | \ | B3 If the metric of the route S-A increases by more than max_i(d(A,B_i)), then all of the updates sent by A become unfeasible for all of the B_i. Hence, all of the B_i remain unreachable until S originates a new seqno. A will forward a request on behalf of the B_i, and due to duplicate suppression, it will be forwarded only once. If the request A->B is lost, then you're waiting until the next unfeasible update sent by A. -- Juliusz