[email protected]
[Top] [All Lists]

Re: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]]

Subject: Re: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]]
From: mike shand
Date: Thu, 28 Jul 2005 13:51:26 +0100
At 13:29 28/07/2005, Russ White wrote:

I'm completely confused about what you are saying here. We are talking about B wanting to send traffic to C, right? In BOTH cases there is a loop. Clearly so in the first case, since there is no other path than through B. But in the second case there is also a loop because of ECMP. If ANY ECMP path may loop then you have to consider it a loop. Then you suggest changing the B-D cost to 25. Again in BOTH cases there is loop. I don't know what you are trying to show here.
So, this is part of the problem--what do you mean by "loop?" Do you mean D
has an alternate path that does not go through B, or do you mean D would
not send traffic via B to get to C given the current metrics? Those are
two different definitions, and I've not figured out which one the draft is
using. I _think_ the draft "wants to mean" that the first is a loop free
path, and the second is a "downstream neighbor," but the formula's don't
seem to work this way.
If we are considering whether or not B's neighbor D is an LFA (for
destination C), then what we mean is that if B were to send a packet
addressed to C to D, then if we can guarantee that the packet will not come
back to B we can say that D is an LFA. If the packet MAY come back to B,
the D is not an LFA.
The conditions for this to be true are described by the relationship
D_opt(D, C) < D_opt(D, B) + D_opt(B, C)
{aside...
Now I confess that I personally don't find the mathematical expression of these things particularly easy to manipulate in my mind. I much prefer a pictorial way of thinking about it. But nevertheless, the mathematical version is I think correct.
}

A downstream route is a much stronger requirement than an LFA. i.e. a downstream route is always an LFA, but the converse is not true.
In the draft we are considering, the safety condition is that we have an
LFA in the old topology and a downstream route in the new topology.
As explained we cannot just choose LFA in both old and new topologies,
since that could result in a loop. Using the stronger downstream
requirement prevents this.
It would also be guaranteed loop free if we used downstream in both old and
new (the so called assymetric cost condition), but this would dramatically
reduce the number of type A pairs found.
One source of confusion here may be that we are talking about two sorts of
"loops". There are the loops we are considering when we decide whether a
neighbor is an LFA or not, and there are the loops which may form during a
topology change. The two are related, but not the same thing.
        Mike



However if you changed the cost of B-D to 51 THEN it becomes interesting. Case 1 is clearly a loop, but case 2 is not.
>> A-(25)-B-(25)-C
>> |      |
>> |     (50)
>> |      |
>> +-(25)-D
>>
>> A-(25)-B-(25)-C
>>         |      |
>>        (50)    |
>>         |      |
>>         D-(75)-+

In neither case is D a downstream neighbor (since the cost from D to C is > cost from B to C).
But consider LFAs
we have an LFA if D_opt(N, D) < D_opt(N, S) + D_opt(S, D)
or in this case if  D_opt(D, C) < D_opt(D, B) + D_opt(B, C)
But in case 1 D is NOT an LFA
D_opt(D, C) = 75 (DABC)
D_opt(D, B) = 50 (DAB)
D_opt(B, C) = 25 (BC)
hence 75 !< 50 + 25
whereas in case 2 D IS an LFA
D_opt(D, C) = 75 (DC)
D_opt(D, B) = 51 (DB)
D_opt(B, C) = 25 (BC)
hence 75 < 51 + 25
I see, you're counting on the looped path showing up as an alternate lower
cost path to the neighbor itself. In other words, this could be simlified
to if there is a path with lower cost to the neighbor through some other
path, then the path through the neighbor must be a loop.
Then why not just say so? :-)

The draft is very confusing, and doesn't really explain the principle being used here very well at all....
:-)

Russ
_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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