[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 09:40:33 +0000
At 16:05 22/11/2004 -0500, Alia Atlas wrote:

I think that Mike's numbers are for the percentage of node failures that can't be repaired with a single primary tunnel+directed forwarding.
Correct. Yes I was puzzled by Curtis' comment too. What these figures say
is that MOST node failures can be repaired using primary tunnels only, and
that the remaining few percent can be repaired using a secondary tunnel.
i.e. repair to one neighbor's neighbor and then let that node repair again.
(note that this is not nested tunnel encapsulation, since the packet is
decapsulated before being re-encapsulated. Indeed, it is often the case
that one (or even both) of the repairs would not need tunnels at all. i.e.
both the primary and secondary repair could be LFAs. But note that to avoid
the problem with looping secondaries we would encap the first repair,
although this isn't strictly necessary in all topologies; it could be
avoided in some topologies at the expense of extra computation (to
determine if it were necessary).

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%


I.e., it covers the node disjoint case pretty well.


At 03:09 PM 11/22/2004, Curtis Villamizar wrote:

In message <[email protected]>
mike shand writes:
> At 12:39 22/11/2004 -0500, Alia Atlas wrote:
> >What can you get with a single primary repair?
> Some examples of the percentage of node repairs which require secondaries
> below. This is calculated by taking the number of repairs for node repair
> which require a secondary repair divided by the total number of repairs.
> Where a repair is a repair to a single neighbor's neighbor.
> e.g.
>            V
>            |
> S---------E----U
>            |
>            T
> The repairs for node E failing would be
> etc.
> 0.79%
> 13.77%
> 3.98%
> 1.47%
> 0.50%
> 4.64%
> 0.00%
> (Note that the 13% one is a hub and spoke like network which gives only
> about 70% coverage for U-turns (link repair; I haven't simulated U-turns
> for node repair).  It is quite a nasty topology for any IPFRR mechanism)
>          Mike

So what you are saying seems to be that covering the node disjoint
problem is mostly not needed.  I think some providers would dispute
that (if providers ever did speak up in IETF and if one does please
disregard my speculation on what providers might say).

Also this does not address SRLG at all which was another part of this
thread.  Thats why I changed the subject line.  You could further
split that into node disjoint and SRLG since they are different
problems (though the node disjoint problem can be considered a proper
subset of SRLG).


Rtgwg mailing list
[email protected]

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