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

[Ondrej Zajicek]

On Sat, Dec 17, 2022 at 03:54:32PM +0100, Juliusz Chroboczek via Bird-users wrote:
> > 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.

Well, it is written in RFC:

 3.2.7. The Table of Pending Seqno Requests 

  ... This table is indexed by triples of the form (prefix, plen,
  router-id), and every entry in this table contains the following data:

  * the prefix, plen, router-id, and seqno being requested;

  * the neighbour, if any, on behalf of which we are forwarding this request;

  * a small integer indicating the number of times that this request will
    be resent if it remains unsatisfied.

But it is true that since forwarded requests are not resent, i also do not
see the need for this information.


> Yep, that's the intent of RFC 8966 Section 3.8.1 (I agree it's not
> perfectly clear):
> 
>    A single request MUST NOT be duplicated: it MUST NOT be forwarded to
>    a multicast address, and it MUST NOT be forwarded to multiple neighbours.

I think that the text of section 3.2.7 (The Table of Pending Seqno
Requests) is confusing with regard to this, as it describes resent
counter for each entry without any qualifier that it is only used for
originated requests and not for forwarded requests).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."