Hi During testing of Babel we noticed a strange behavior and we are not sure if it is a problem in the implementation or in the specification. The sequence of events is like: 1) Router A is running, originated some routes with seqno old_seqno and propagated them to a router B. 2) If router A (or Babel protocol) is restarted, the seqno counter used for originating routes is also reset to 1. 3) Then routes are originated with seqno 1 and propagated to router B. 4) Router B already has these routes with old high seqno, so the update is considered unfeasible and for selected entries, so it is ignored (3.5.4). 5) The routes in the router B's table slowly expire. 6) When routes expire, router B sends seqno request (3.8.2.1) with old_seqno+1. 7) Router A receives seqno request, increases seqno to 2 (3.8.1.2), originates routes with seqno 2 and sends them to router B. 8) Router B still ignores them as 2 < old_seqno. 9) Subsequent updates are still ignored as router B holds old timeouted entry as a selected entry with unreachable metric (as there is no other one) until GC time. I have two questions w.r.t. this sequence of events: 1) How is router restart and seqnos supposed to be handled without waiting for route timeout? 2) If a route is selected, then becomes unreachable/retracted, and there is no other route to be selected, is it still considered selected? I would say that no as the selection process (3.6) forbids retracted routes to be selected, but the BIRD implementation keeps the old selected route (now unreachable) in this case. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."