At 09:38 AM 10/22/2004, Alia Atlas wrote:
At 08:02 AM 10/22/2004, mike shand wrote:
SO now going back to your analysis of the pt-pt link case. I think you
may have misunderstood how the reverse SPF is used. Remember that it is
ONLY the portion of the RSPF which crosses the link under consideration
which is interesting.
Are you saying that you only take the branch of the RSPT that goes across
the failed link? Presumably this is to reduce the set of affected nodes,
which makes sense.
Looking at the following ECMP example, I think we may be arguing the same
[ I ]-----------------------|
5 | |
| 2 2 |
[ S ]----[ A ]----[ B ] |
| | 2 |
| [ C ] |
| 15 | 2 |
| [ E ] |
| | |
| | 2 |
| 5 10 | |
[ H ]----[ G ]----[ F ] |
| 5 |
[ D ]--------------|
In the above topology, D is the destination and G is the node which
fails. Before the failure, S has two equal-cost paths to D, via H-G-D
or via A-B-C-E-F-G-D. According to the Ordered SPFs idea, when G
fails, each router will do three reverse spanning trees (based on
distance), from each of H, F and D, and only take the branch that goes
across the particular failed link (H-G, F-G and D-G).
Assume that S hears about the H-G failure first. S will compute its
hopCount as 1; the maxHorizon is 2. So the delay is 1.
Then S hears about the F-G failure. Now, S will compute its hopCount
as 5 and the maxHorizon is 6. So the delay is 1.
I was thinking of computing the delay essentially based on the final
hopCount and the final maxHorizon. Instead, I think you are taking the
delay based on each hopCount and maxHorizon, for each failed link, and then
taking the max.
Sorry for being confused; I do think this needs substantially more description.
Rtgwg mailing list