At 20:33 22/11/2004 -0500, Alia Atlas wrote:
At 05:35 PM 11/22/2004, Curtis Villamizar wrote:
My point was that the node disjoint problem is a subset of the SRLG
problem. It is a subset because you can define a SRLG to be all links
adjacent to a given node and therefore define the node disjoint case
as an SRLG case. The local SRLG problem is also a subset of the SRLG
Local SRLGs and node disjoint are easier cases to handle than general
SRLGs. Certainly, if one solves the general case, those can come for free.
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.
So far only MPLS/TE fully addresses SRLG and it does so very cleanly.
In a full overlay, MPLS/TE requires a CSPF per IGP node.
If we were willing to accept an SPF per node in the topology, then looking
at SRLGs would be a lot simpler!
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.
The computational complexity for MPLS/TE can be quite large, depending on
the number of tunnels to be considered. Sure, one can use techniques to
minimize the impact, but it is there.
I'd say it's clear that for IP FRR, there's a desire to have substantially
fewer SPFs than 1 per node.
Yes, given that some of the networks we have been looking at have getting
on for 1000 nodes, that would seem a reasonable assumtption.
There is the basic fact that without source-based routing, it might not be
possible to find an alternate.
Yes this is always the problem with what are effectively loose source
routing methods (with various restrictions).
If the general SRLG problem is not addressed, the failure to address
the problem should at least be acknowledged in the documents. If SRLG
is not a requirement for IP FRR, that should at least be stated in the
framework document, but the limitations should also be acknowledged.
Normally it would be sufficient to list something as future work in
the framework but that should be done where algorithms are known and
only the protocol bits need to be defined later (and if needed). In
this case there is question about whether feasible algorithms exists
so the limitation should be acknowledged and not just dismissed.
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.
Rtgwg mailing list