[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: Russ White
Date: Wed, 27 Jul 2005 20:30:19 -0400
-----BEGIN PGP SIGNED MESSAGE-----
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 
networks:

A-(25)-B-(25)-C
|      |
|     (50)
|      |
+-(25)-D

A-(25)-B-(25)-C
        |      |
       (50)    |
        |      |
        D-(75)-+

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 (?).

:-)

Russ

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


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2185)

iQA/AwUBQugnJREdu7FIVPTkEQLp1ACg1AeIaNMVkjA9oKNpmIPWzlw4nScAmgJP
MQ+fkvO2i3jfdiJJXYSCXxth
=pLCY
-----END PGP SIGNATURE-----

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

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