At 11:48 AM 11/23/2004, mike shand wrote:
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.
And store all of them and use them as proxies? What about SRLG links in
series? I guess you'd need to trim the trees as well.
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.
I think I disagree with that argument. Consider a case where one wants to
protect VPN traffic, but not necessarily all traffic. In that case, as
long as all sources to the set of relevant PE routers are protected, it
doesn't matter (as much) that the other destinations aren't
protected. There can definitely be cases where one or more particular
destination nodes are of the most importance; think of protecting a
valuable video broadcast stream, for instance.
It does seem to me that the proxying at just a next-next-hop won't work
well for SRLGs. Doing the proxying at the end of each link of the SRLG and
then deciding which to use for each destination might.
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).
Where would you do the secondary repair to? It couldn't be the
next-next-hop normally used, because that path is at risk of failing due to
the same SRLG (for some sub-set of the destinations). Also, on the
secondary repairs, didn't you have some concerns about the computational
feasibility of them?
Node failures aren't general SRLGs in disguise; they're local SRLGs in
disguise and that makes all the difference. The main difference is that
distance comparisons don't help at all for SRLGs. The only way to tell
that a path traverses an SRLG is to track it! SRLGs are random attributes
of a link. For node failures or local SRLGs, one can simply avoid the
relevant node. If you've got a local SRLG and no node-protection, then
it's back to tracking, but a hopefully more limited set of SRLGs.
Do you know a cleaner way to handle them? We can't prune them beforehand
(b/c the routers in the network consider them for their SPFs) and one can't
prune them during the SPF, b/c the path across a particular SRLG isn't
known to be the shortest. One could poison the path at a certain distance,
but the poisoning would be SRLG dependent.
Rtgwg mailing list