[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: Russ White
Date: Wed, 27 Jul 2005 21:03:00 -0400
-----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:

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.

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

:-)

Russ

- -- 
[email protected] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2185)

iQA/AwUBQuguzhEdu7FIVPTkEQIAnwCfXgYp/dUKNM0wgVODNYa+BPcfL1IAoJgf
Ivf/wRseRWCqwWOPB5iQizEp
=FXL9
-----END PGP SIGNATURE-----

_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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