Monday, June 6, 2005, 12:59:13 AM, mike shand wrote:
> At 09:26 04/06/2005 +0100, Stewart Bryant wrote:
>>In the past this was a garbage collection activity with no topology
>>significance, and did not need to be synchronized. We are now making
>>it a topology significant event that needs to be synchronized so that
>>max-time is synchronously removed across the network.
> But it IS already synchronized to the same degree that "live" LSP
> propagation is synchronized, in IS-IS at least... I assume also in OSPF.
Yes, in OSPF too.
> Remember that as soon as the first copy of the LSP ages out it performs a
> zero age purge of any other copies in the network. This propagates at the
> same rate and with the same synchronization properties as any other LSP.
Right. Though there maybe some momentary differences in router LSDBs, they
get synchronized within a finite period of time (absent more frequent
changes, strictly speaking).
> However, this does raise a problem...
I believe considering behavior of update-delay announcements in the light
of topological events is a wrong direction. Update-delay information has no
correlation with topological activity and only changes due to an
administrative action, and the fact that it would share the same transport
with topological information is coincidental from this perspective.
Yes, it is probable that some topological event will happen right at the
moment when an old LSP is being purged or a new one is flooded. However, it
happening won't be less probable than if the times were changed on all
routers manually, and not more probable than if they were configured via
> Ageing out of LSPs occurs asynchronously with any real topology change
> events in the network. Hence it is possible that an LSP requiring the
> largest delay happens to age out at approximately the same time as some
> real event which we are trying to protect against looping. This could have
> the effect that some routers use different values for the delay for the
> real event because they received the purge of the LSP at different points
> (we assume that even in implementations which [IMHO] wrongly do not remove
> the contents of a zero aged LSP, we would still not take notice of a delay
> value advertised in a zero age LSP). This could be minimized by recomputing
> the maximum delay every time a new LSP arrives even if it is determined
> that it is one which does not trigger an SPF. But this means we need to
> perform extra scans of the LSP database at times we would not usually do so.
> I'm still not convinced that even using the set in the current SPT will
> unconditionally protect against this sort of error.
> I suspect that any errors introduced by the "automatic" scheme are smaller
> than those which are very likely to be introduced by any manual scheme,
> especially when it becomes necessary (as it inevitably will) to change to
> delay values. This leads me to think that the "automatic" way is the right
> way to go, but I am still uncomfortable about it.
Rtgwg mailing list