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
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:
> -----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
> | |
> | (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
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