Forwarded with permission of the author.
--- Begin Message ---
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."
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
