[email protected]
[Top] [All Lists]

Re: ordered SPFs

Subject: Re: ordered SPFs
From: Alia Atlas
Date: Thu, 21 Oct 2004 11:25:48 -0400

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
are received.
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
something here.
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>