[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 09:11:31 +0100
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.
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.
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


At 01:30 28/07/2005, Russ White wrote:
Hash: SHA1

>>You could divide the last one into two groups, if you can find a way to
>>tell between loop free and looped paths in this class--but you can't
>>tell the difference based on your cost and your neighbor's cost alone.

BTW, I'll make the challenge more specific. Suppose you have these two

|      |
|     (50)
|      |

        |      |
       (50)    |
        |      |

How can B tell which is which, based only on metrics (no SPF or split
horizon tricks allowed, just metrics!). The metrics are identical in
both cases:

- -- B->C (best) == 25
- -- B->D == 50
- -- D->C (via C) == 75
- -- D->C (via B) == 75

Yet one is a loop, and the other is not. Further, D->C !< B->C, so B
thinks this is a loop, in both cases--they both fall into the same
category of the neighbor's cost being more than the local cost, which is
the category you're saying you can split by looking at the metrics. To
make matters worse, D is actually ECMP load sharing to C in both cases
(!), without realizing the traffic is actually passing through the B->C
link in the first case across both available paths.

Even if you make the B->D link 25 in both cases, B cannot tell the
difference between these two cases, and making it ECMP just tears the
entire concept of "downstream neighbor" and "loop free neighbor"
completely asunder.... :-)

>>In "standard" IS-IS, this isn't a problem, since you never take routes
>>from L2 into L1, and therefore you can't have loops. I don't tend to
>>think of these problems in terms of a specific implementation,
>>though--if you're addressing the theoretical mechanisms of finding
>>alternate loop free paths, then the problem is the same, in theory, in
>>all possible link state protocols that divide the flooding domain by
>>removing topology information at set boundaries within the network. AIMV
>>(actual implementations may vary, a corollary of the underlying theory
>>that YMMV, or perhaps RLMV).

> K.  We did a bit of considering the problem  & decided to put an SEP
> field around it by specifying applicability restrictions for OSPF,
> which is the actual implementation that exhibited the problem.  My
> concern was whether the actual implementation for IS-IS might have any
> unobvious issues as well.

In theory, you'd never send traffic through an L1 domain to get between
two sections of the L2 domain, nor would you ever go through L2 to reach
some other destination in the same L1 domain, so the problem can't
exist, really. Now, if you get into a situation where the link failure
that specifically causes you to fall back to your backup path also
happens to split the domain, I don't know what the result would be. I
don't think you'd run into a problem there, either, but it's an
interesting case to consider, perhaps (?).



- --
[email protected] CCIE <>< Grace Alone

Version: PGP Desktop 9.0.1 (Build 2185)


Rtgwg mailing list
[email protected]
Rtgwg mailing list
[email protected]

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