[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: mike shand
Date: Tue, 23 Nov 2004 16:26:55 +0000
At 10:58 23/11/2004 -0500, Alia Atlas wrote:

The percentage that is missing is then those that require a single primary tunnel for repair? These are the number for repair for node failure?
Yes, this is all node failure

sec %   df%     LFA%
0.79%   4.6%    69.4%

So what this tells us is that 69% of the repair paths required didn't need a tunnel (to get to the nnh), so 31% did require a tunnel. Of these 4.6% need DF as well, and 0.8% required a secondary repair (which itself may have been satisfied by LFA or required DF).

I'm trying to get a sense of what the benefit from LFA is versus the tunnels versus the DF versus the secondary, etc. I'm interested in the different benefits for link protection and for node protection.

I may have some numbers for link protection....

I should probably re-run the simulations with some better stats, but these will do for now.
LFA     DF
82%     1%
78%     12%
73%     20%
89%     1%
79%     0%
78%     1%

All give 100% protection if DF is used where necessary. Of course secondaries are not necessary for link repair (except perhaps for the case of SRLG).
SO what this

LFA     DF
82%     1%

means is that 82% of links can be repaired without using tunnels. 18% require tunnels and these are split with 17% not requiring DF and 1% requiring DF.

In a somewhat related question, I understand that you are using a next-next-hop to proxy for destinations.

Is it possible that you miss a viable LFA to a destination because of this? I.e., the neighbor may be LFA with respect to the destination but not the next-next-hop?
Yes, but that is why I say that in practice we skim the LFA reachable
destinations off the top, since that computation falls out of the rest.
That way we only tunnel traffic that HAS to be tunnelled. It would of
course work if we put this traffic in the tunnel, but it seems sensible to
avoid using a tunnel where possible.

Also, how do you handle the ECMP cases where you may have multiple next-next-hops (even from the same next-hop)? That seems like a per-destination decision.
OK, so you have


Traffic for destination D is split through X and Y. You have a choice. If you want to preserve (some semblance of) the ECMP, then you split the traffic between the repair for X and the repair for Y. Or you can simply arbitrarily choose either of X or Y. You have to determine which nnh is used for which destination anyway to do the traffic assignment to the correct repair even when there is no ECMP. You can do this by noting the nnh when you run the normal SPF at S.


At 04:40 AM 11/23/2004, mike shand wrote:
Alia, these may not be in the form you would like (but since I have them to hand....).
These are the same networks as before. df% is the percentage of repairs
which required directed forwarding (the same as before, the fraction of
individual repairs which needed DF). LFA% is the percentage which simply
used LFA (i.e. no tunnels)
Note that is no tunnels for ALL traffic. This doesn't mean that this is
the percentage of traffic which would not be tunnelled. That would be
much higher, since we can easily do per destination LFA determination.
In case that is not clear, let me elaborate for the simple link failure
case. We can compute a repair for the failure of SE. Sometimes we can
repair ALL traffic (even that with a destination of E) by using LFA.
Other times we will need a tunnel to get to E. However, in that case, we
can compute the set of destinations which have LFAs, and we would only
use the tunnel for the remaining traffic. Of course it would
theoretically be possible to compute different tunnels for different
destinations, but that is not computational feasible.

sec %   df%     LFA%
0.79%   4.6%    69.4%
13.77%  41.9%   45.5%
3.98%   19.1%   66.3%
1.47%   1.2%    59.3%
0.50%   1.3%    79.4%
4.64%   1.3%    61.9%
0.00%   0.0%    62.6%

Rtgwg mailing list
[email protected]

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