Forwarded with permission of the author.
--- Begin Message ---Hi Juliusz and TokeI 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."signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users