[PATCH] babel: Rework seqno request handling to track sender, not destination

[Juliusz Chroboczek]

>> 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