At 10:57 AM 10/21/2004, mike shand wrote:
At 12:10 20/10/2004 -0400, Alia Atlas wrote:
Olivier & Mike,
I agree that what you are describing works for a node failure if the node
is the root for the RSPT.
My question/confusion is what is actually done for a node failure. Mike
seems to indicate that a separate RSPT is computed for each end connected
to each down link. The RSPT must be computed on the topology before
any of the failures occurred. Then I guess that a node takes its
furthest hop-count to use as its position.
Yes. If the arrival of a second (or subsequent) LSP causes you to increase
your delay, then you do so, but if it would cause you to decrease it you
keep the existing delay. Note that if you have already made a change with
no delay, this can only have affected destinations which would not be
affected by the subsequent LSP.
That doesn't make sense to me. The further away (in hopCount) one is, the
shorter the delay, right, b/c you are removing the dependency. In the ECMP
cases, it seems entirely possible that one will want to decrease the
delay. I'm thinking of the case where there's a broadcast link that
fails. Otherwise, there's a race condition that depends on when the LSPs
Also, why would a change made with no delay have affected only destinations
that wouldn't be affected by the subsequent LSP? I'm clearly missing
There is an assumption that all the LSPs concerning the failure arrive
within the first delay period. If this is not the case, then even link
failure loop protection cannot work. i.e. if some router somewhere doesn't
receive an LSP until after the other routers around it have already waited
their delay, there will be de-synchronization.
Sure. There's definitely a required information gathering delay.
Rtgwg mailing list