At 11:03 23/11/2004 -0500, Alia Atlas wrote:
At 05:08 AM 11/23/2004, mike shand wrote:
One issue that I see for the non-source-routed tunnel based approach is
that it uses the original next-next-hop as a proxy for a set of
destinations. It is possible that the path from the next-next-hop to a
particular destination will not be available because it traverses a link
in the same SRLG.
I think that this may make the destination assignment a bit trickier.
Well, by analogy with the node failure case, one way to deal with this is
to consider a separate repair to the far side of each SRLG. I'm not sure
it is always necessary, but I think it is sufficeient.
But what is the far side of the SRLG?
When you run a normal SPF rooted at S, as you traverse each SRLG you will
find which is the far side.
Trimming the trees after they're computed makes some sense, but then it a
next-next-hop is dependent on the same SRLG to reach a destination, that
destination won't be given an alternate (where there might be one without
It certainly true that proxying reduces your options. Even in the non-SRLG
case it is true that if it were the case that a repair was impossible to a
proxy it may still be possible for all destinations except that proxy.
However, our view is that if the failure is not 100% repairable then it is
irreparable, so rather than giving some destinations poorer service it
would probably be better not to attempt repair at all for that link. Not
that we have seen any such irreparable links in real networks, but that is
the principle behind the proxying.
In the case of SRLG, this might translate to a case where it was necessary
to use secondary repairs because a few destinations could not otherwise be
repaired. What this would mean is that we might use a secondary repair for
some destinations which (if we had done the whole calculation per
destination) could ave been repaired via a single primary repair. This is
also true of node failures (which are of course SRLGs in disguse).
Rtgwg mailing list