[email protected]
[Top] [All Lists]

Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels

Subject: Re: node disjoint and SRLG was: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Alia Atlas
Date: Mon, 22 Nov 2004 20:33:48 -0500

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.

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.
There is the basic fact that without source-based routing, it might not be
possible to find an alternate.
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>