[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]] mike shand Thu, 28 Jul 2005 09:11:31 +0100
 ```Russ, ``` 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 Mike At 01:30 28/07/2005, Russ White wrote: ``````-----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 ``````_______________________________________________ Rtgwg mailing list [email protected] https://www1.ietf.org/mailman/listinfo/rtgwg ```
 Current Thread [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]], Russ White Message not available Message not available Message not available Message not available Message not available Message not available Message not available Re: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]], Russ White Re: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]], mike shand <= Re: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]], Alia Atlas