>> Of course, if there are no feasible routes to a given destination, then >> the neighbours will perform an end-to-end search for a loop-free route, >> but that's the neghbours' problem, not ours.
> I can't say I agree with the "their problem" mentality. The way I see it > during graceful shutdown we're still responsible for in-flight traffic > anyway. What I mean is that after our neighbours receive our retraction, they'll no longer be sending traffic to us, whether they have a feasible route or not. If you're really keen on avoiding disruptions, you should first increase the metric to something very lare (say, 2^15), then wait a couple of seconds, then send a retraction, then wait 200ms. But I think that's too much hassle, I like your current approach better. > In my mind it doesn't matter if babeld takes 500ms or 15sec to shutdown if > that buys me a rock solid network. I think the default should be 300ms or so. > The note about the ACKs was simply supposed to be reasoning for why an > ad-hoc delay rather than having neighbours ACK the retractions. > >> - should the granularity be lower? A second for local signalling is >> a lot, I'd expect 300ms to be enough in most cases; > I have no problem changing it to millisecond granularity if that suits you? Please. -- Juliusz _______________________________________________ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users