At 05:10 AM 11/26/2004, Stewart Bryant wrote:
If I were even willing to accept an SPF per neighbors' neighbor, it would
be completely clear how to do SRLGs for U-turn alternates.
I can see how with one SPF per node you can increase the reach of
U-turn, but surely to do SRLG you need to carry some vector in the
packet to steer it at critical places?
There's no need for a vector in the packet. There needs to be a path from
S to the node from which the SPT will be followed. The path from that node
on the SPT needs to avoid the SRLG.
Whether one can find this depends on the topology.
I'd say it's clear that for IP FRR, there's a desire to have
substantially fewer SPFs than 1 per node.
That is a desire, although I have some personal doubts at the validity of
that constraint. Remember that when we designed link state
protocols we were using CPUs that were three orders of magnitude slower
than those that we use today.
Which means we can do a handful of SPFs, not 100s or 1000s.
I guess it depends on the particular technique considered, but there are
feasible algorithms for some of them.
For loop-free alternates, one can track the SRLGs traversed by each
neighbor, and decide whether to use a loop-free neighbor based on whether
the SRLGs of concern are passed.
We can do the same for tunnels, and you can do the same for U-turn.
The general approach is that you must check that you do not go over
an SRLG member during the period that you control the packet, and
then make sure that it does not go over one after it is released. The
issue is what to you do if it does.
Give up on that as an alternate and hunt for another one?
Rtgwg mailing list