[Babel-users] Some notes on seqno requests in Babel

[David Schinazi]

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 <jch at irif.fr> wrote:
> 
> Forwarded with permission of the author.
> 
> From: Ondrej Zajicek <santiago at crfreenet.org>
> Subject: Some notes on seqno requests in Babel
> Date: October 26, 2017 at 05:15:02 PDT
> To: Juliusz Chroboczek <jch at irif.fr>, Toke Høiland-Jørgensen <toke at 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: 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."
> 
> 
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20171026/e7c880ae/attachment.html>