> I think I understand. If there is the potential for a loop (advertised
> distance >= babel router’s former distance), babel will wait for the
> next sequenced route from the source.
Exactly.
>So, the loop-free guarantee is at the expense of potentially faster
>convergence.
In principle, yes. However, that's where the mechanism outlined in slide
17 kicks in -- the starving router will send a request for a sequence
number increase, which follows the potentially looping route. There are
two cases:
* if the route was in fact non-looping, the request will reach the
source, which will increase its sequence number straight away and
trigger an update;
* if the route was in fact looping, then the request will loop just
once before it is discarded by duplicate detection.
The result is that, in the absence of packet loss, you clear the
starvation in time 20ms per hop (the amount of jitter applied to forwarded
requests). With a five-hop route, that's just one tenth of a second.
With lossy links, you're going to get timeouts, which will indeed slow
down reconvergence. See however the experimental data in
http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers
where, in a relatively small but lossy mesh network, an older version of
Babel consistently exhibited packet delivery above 99% and convergence
times on the order of three hello intervals (which is the expected time
needed for the wireless link quality estimator to converge).
(And if you think that this looks like EIGRP's active phase -- you're
right, except that it's less brittle in the presence of packet loss, since
there's no requirement for a global synchronisation, and provides weaker
time bounds in the presence of packet loss, since there's no requirement
for a global synchronisation. Sometimes you're stuck between a rock and
a hard place.)
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
