Thanks for the comments Ondrej! I agree with the points you raise, and I think we've improved this in RFC6126bis: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis <https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis>
Could you take a look at the updated document and let us know what you think? Thanks, David > On Oct 26, 2017, at 07:47, Juliusz Chroboczek <j...@irif.fr> wrote: > > Forwarded with permission of the author. > > From: Ondrej Zajicek <santi...@crfreenet.org> > Subject: Some notes on seqno requests in Babel > Date: October 26, 2017 at 05:15:02 PDT > To: Juliusz Chroboczek <j...@irif.fr>, Toke Høiland-Jørgensen <t...@toke.dk> > > > Hi Juliusz and Toke > > I am fixing some issues in Babel code in BIRD related to seqno requests > and i found that parts of the Babel RFC less than clear. > > 1) 3.2.6. The Table of Pending Requests > > The table of pending requests contains a list of seqno requests that > the local node has sent (either because they have been originated > locally, or because they were forwarded) and to which no reply has > been received yet. This table is indexed by prefixes, and every > entry in this table contains the following data: > > The paragraph says that the table is indexed by prefixes. I would assume > it means that prefix is a unique key for the table, so no two entries > have the same prefix. That would work for forwarded requests, but IMHO > there may be multiple pending locally originated requests for the same > prefix with different router-id resulting from actions by section > 3.8.2.2. Dealing with Unfeasible Updates. > > I guess it could be handled by keeping only the request related to the > route with the best metric, or should we keep multiple pending > requests with different router-ids? > > BIRD currently uses (prefix, router-id, seqno) as a key, where different > seqno values are clearly not necessary. > > > 2) 3.8.1.2. Seqno Requests > > If the requested router-id is not its own, the received request's hop > count is 2 or more, and the node has a route (not necessarily a > feasible one) for the requested prefix that does not use the > requestor as a next hop, the node SHOULD forward the request. It > does so by decreasing the hop count and sending the request in a > unicast packet destined to a neighbour that advertises the given > prefix (not necessarily the selected neighbour) and that is distinct > from the neighbour from which the request was received. > > I am not sure why the paragraph emphasises 'node has a route (not > necessarily a feasible one) for the requested prefix that does not use > the requestor as a next hop' and what means '(not necessarily the > selected neighbour)', when in earlier paragraphs it is established that > seqno forwarding is only done if there is a selected route with the same > router-id. > > I guess it is because the selected route may be one with the requestor as > a next hop and and in such case a different route (with the same router-id) > has to be used? > > > 3) In appendix B, there are no hints about resending and expiration of > requests - suggested timeout values and number of resend attempts. > Are there any suggested values? > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@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." > > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
_______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users