On 7/22/05, Russ White <[email protected]> wrote:
> Loop-free neighbor
> Neighbor N of router S is considered S's loop-free neighbor
> for destination D, if Dopt(N, D) < Dopt(N, S) + Dopt(S, D).
> Note that a loop-free neighbor may be, for example, router's
> primary before or after failure.
> I don't know if I agree with this.... You're saying a neighbor is only
> loop free if the cost from the neighbor to the destination is less than
> the cost from the local router to the destination plus the cost from the
> neighbor to the local router? That's not true, since their cost could be
> much less than yours, but your cost to them is greater than the
> differential, which, according to this definition, marks the route as a
> loop (actually, I think this formula is worse than that, and marks all
> possible alternate routes as loops).
If N's shortest path to D goes via S, then Dopt(N,D) == Dopt(N,S) +
Dopt(S,D) because a shortest path is comprised of shortest paths.
This is considering the shortest path from N's view.
If N is a loop-free neighbor for a particular destination, then S can
send that traffic to N & know that it won't come back. S may choose
to do so for this purpose even if the cost from S to N is high.
> A neighbor always has a loop free route if their cost is less than your
> cost--it's geometrically impossible to be otherwise (see Garcia's
> original DUAL paper). Your cost to the neighbor in question has no part
> to play in determining if they have a loop free alternate path to the
> one you have. If Dopt(N,D) < Dopt(S,D), the path is loop free in all cases.
This is the tighter condition of a downstream neighbor, which is a
subset of the loop-free neighbors. It is more restrictive & provides
> A neighbor MAY have a loop free path, even if their cost is greater than
> or equal to yours, but there's no way for you to know that without
> taking yourself out of the tree and calculating an SPF from their point
> of view (and it's impossible to verify is the destination is only
> reachable through an aggregate of information formed along a flooding
> domain boundary, which is where I think you've run into problems with
S needs to know what its neighbor will do without knowledge of the
topology change. It isn't necessary for S to remove itself from the
topology before computing the SPF from the neighbor's point of view.
This mechanism is assuming (much like the loop-free alternates) that S
can obtain the necessary information, which can be done by doing an
SPF from each neighbor's viewpoint on the same tree.
Could you expand more on the concerns you have about L1/L2/ABRs? I
know that we ran into some issues with OSPF where traffic could leave
an area & then possibly re-enter that area, causing unknown loops.
The LFA draft addresses this for OSPF. I didn't think that there are
similar issues for IS-IS. What are you picturing?
Rtgwg mailing list