[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: Alia Atlas
Date: Thu, 28 Jul 2005 10:57:56 -0700

I think, from this email & the next one, I've got a slightly better
idea of what you're saying.  I was misinterpreting the "unknowable
from metrics".

The context for LFAs and PLSN, I think, has been link-state protocols
and not distance vector.  Because it is a link-state protocol, all the
topology is known at S and S can run multiple different SPFs to find
out the necessary information.  Certainly for a distance-vector
protocol, the SPF computation is what is distributed; I'm not sure
whether one could take the partial information & use that.  I've not
read that paper yet, so it feels like it could be possible :-) but I
haven't thought about it.

Want to? ;-)

On 7/27/05, Russ White <[email protected]> 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
> 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

Ah, in both cases:
   D->C == D->B + B->C

thus, it fails the loop-free test.  Both are loops, if one assumes
that D is doing ECMP & B has no information to assume otherwise.

> 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.... :-)

ECMP is considered in these cases.  That's why both are considered loops!

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

Yes, probably.  Maybe Mike's thought about that one?


Rtgwg mailing list
[email protected]

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