On 7/27/05, Russ White <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > a) shortest paths
> > b) downstream paths: the next-hop's distance to D is less than S's
> > distance to D. Shortest paths are a subset of these.
> > c) loop-free paths: the next-hop's shortest path(s) to D do not go
> > through S. Downstream paths are a subset of these.
> > d) looping paths: the set of next-hops with at least one shortest
> > path that does go through S.
> Agreed. All of C and all of D fall into Dopt(S,D) > Dopt(N,D), based on
> your definition of B. You can't tell which is which by relying on the
> metrics. See my example in my other email....
> > Perhaps I should have said that the right side is the cost of the
> > shortest possible "looping" path that would go via S.
> Hmmm.... I think what you're saying here is that as long as a neighbor's
> cost is less than my cost, it must be loop free, since any additional
> cost, even 1 more, could be a loop. In fact, if a neighbor has an equal
> cost, it could be a loop, in theory, in the case of equal cost multipaths.
> > The question is whether the shortest path from N to D goes via S.
> > The shortest distance that such a path can be is D_opt(N,S) + D_opt(S,
> > D). If D_opt(N, D) is less than this, then the path from N to D
> > cannot go through S.
> Okay, so what you're trying to actually figure out is whether the path
> from N goes through me, S. So, what you're actually trying to split is
> the second case, not the third, from what it looks like. Going back to
> my three cases:
No, I'm trying to split the third case.
The case of downstream neighbors where D_opt(N,D) < D_opt(S,D) isn't
the issue here. Those are loop-free by virtue of a each hop along a
shortest path being monotonically decreasing.
> 1. This is the lowest cost path. This is loop free.
> 2. My neighbor's cost is less than my cost. This is loop free.
> 3. My neighbor's cost is more than my cost. This may, or may not, be
> loop free, but I can't tell from the metrics.
> What you're actually trying to determine seems to be whether or not N
> will, or is, using you as its next hop, in case 2. To do this, you have
> to add your cost to N, and see if that's lower or higher than your cost
> to D. If it is, then N must be using the alternate path to D. If it's
> not, then N must be using you as it's alternate path.
I'm trying to determine this for case 3. The question is how will N
decide to forward a packet to D. Is it via S or not? N will use the
shortest path - so if N->S + S->D is shorter than any other known path
from N->D, N will use that.
> Is that right? If so, you're not messing with the third case, you're
> breaking the second case down into it's two options.
> >>Huh? Again, there are three options for a path, based on the metric:
> >>- -- The path is your best path. This is known to be loop free.
> >>- -- Your neighbor's cost is less than your total cost. This is known to
> >>be loop free, but not the "best."
> >>- -- Your neighbor's cost is more than your total cost. You don't know if
> >>this path is loop free or not, and there's no way to tell from the metrics.
> > And, again, the third one case CAN and IS broken into 2 groups:
> > loop-free & looping. Why do you believe that this can't be told from
> > the metrics???
> See my other example. You can't know the difference between the two.
> > Why do you think a router S can't tell if a neighbor N's path is
> > loop-free to a particular destination?
> > Are you making an assumption that S has only run a single SPF from its
> > own perspective? Why do you think this is unknowable?!?!
> Because of my other example, and my long experience with EIGRP, a
> protocol that uses this specific property of paths to determine a loop
> free feasible successor. :-) I could probably draw you a large number of
> easy to complicated networks where a specific router, under the
> conditions where Dopt(S,D) > Dopt(N,D), may or may not be a loop, and
> the metrics look the same in all cases. Now, breaking the second case
> down into it's two possibilities is useful in the link state case (it's
> not in EIGRP's case, by the way, for various reasons), because you can't
> tell the difference between the two without the second step of
> determining if N must be using S as it's next hop or not.
I have not thought about this in the context of EIGRP (for obvious
reasons :-) but I am confused by why you are unwilling to consider the
knowable information for N->S.
Again, I am not concerned with the downstream neighbors case, which
is, as I understand it, what EIGRP uses.
Also, the question is not whether N is using S as its next-hop, but
whether S is in the path from N to D.
> I do think the draft's wording is a little confusing--I've read it three
> or four times, and couldn't make out what it was trying to say in this area.
Did you have a chance to loop at the framework & LFA drafts? Clearly,
from this conversation, the PLSN draft needs some clarifications &
Rtgwg mailing list