On Mon, Apr 27, 2015 at 04:36:09PM +0100, Paul Jakma wrote: > As an RFC mostly, I havn't actually tested this. Current code sets R-bit only > for a certain amount of time after startup. It seems to me that might not be > right.
The R bit is intended to be based on wallclock time. While setting the R bit doesn't break anything per se, setting the R bit is not intended by the spec when bringing up a new session. In particular, if bringing up a new session from a "good" router (non-restarted recently) to a restarted router, setting the R bit will cause extraneous incoming update noise from the restarted router to the good router. (If the good router doesn't set the R bit as intended by the spec, the restarted router will defer sending updates until it has received sufficient EORs, thus the good will only receive the final full table. But if the R-bit is set for new sessions, this will inadvertedly trigger the deadlock-avoidal mechanism and send all updates as they arrive, causing potentially many incoming updates for each individual net.) > Also interesting is that the R-bit in the OPEN is global, but the EoRs are > per-AFI/SAFI - slight conceptual mismatch in the spec maybe. Nope, the R-bit is overall deadlock-avoidal, it's not tied to an AFI or SAFI. All in all, the old code seems correct - and beautiful in its simplicity. While the new code isn't technically wrong and won't cause persistent issues (as far as I can see), there is the downside of above scenario where it causes extra load - and I can see no upside? -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
