[email protected]
[Top] [All Lists]

[Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]]

Subject: [Fwd: [Fwd: I-D ACTION:draft-ietf-rtgwg-microloop-analysis-00.txt]]
From: Russ White
Date: Fri, 22 Jul 2005 16:44:11 -0400
Comments on draft-ietf-rtgwg-microloop-analysis-00....

    This document provides an analysis of microloop formation.
    Specifically, we categorize different types of reconvergence
    scenarios, and explore their properties. We then show that in certain
    scenaiors microloops do not form, in others they can be eliminated
    using simple techniques described in this document, and define
    scenarios where more sophisticated loop avoidance mechanisms may be
    necessary.

Replace with:

This document provides an analysis of microloop formation. Specifically,
we categorize different types of convergence scenerios, and explore
their properties, to determine:

  o Which scenerios will not result in a microloop.
  o Which scenerios will result in a microloop, but the microloop can be
eliminated using simple techniques described in this document.
  o Which scenerios will result in a microloop requiring more
sophisticated loop avoidance mechanisms.

The parallelism wasn't right in there someplace. :-)

-

      Downstream neighbor
           Neighbor N of router S is considered S's downstream neighbor
           for destination D, if Dopt(N, D) < Dopt(S, D)

It might be worthwhile to state that you are considering "downstream" to
be "closer to the destination." There's often a lot of confusion in the
concept of downstream and upstream.

-

      Primary neighbor
           Neighbor N of router S is considered S's primary neighbor for
           destination D, if N provides the shortest path to D according
           to the SPF calculation.

There could be more than one of these. Don't know if it's worth
mentioning or not. (After reading a bit further, I see you mention this
in section 3.2, but only after the change. It's worth mentioning here
that there are cases where this is true before the change, and it's
always safe to simply drop the failing path, and rely on the remaining
path, in these cases).

-

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

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.

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
L1/L2/ABRs).

-

           For networks with symmetric link costs, after a topology
           change, it is safe for router X to switch to neigbor Y as its
           next-hop for a specific destination if the path through Y sat-
           isfies both of the following criteria:

           1.   X considered Y as its loop-free neighbor based on the
                topology before change AND

           2:   X considers Y as its downstream neighbor based on the
                topology after change.

I would reverse the second requirement--it doesn't matter what X thinks
about where Y should be forwarding traffic, it matters what Y thinks
about where Y should be forwarding traffic. So, perhaps:

Y does not consider X as its downstream neighbor based on the topology
after change. X can infer this as long as it still considers Y a
downstream neighbor after the topology change.

Or something like that (?).

-

           Routers whose new primary next-hops after the topology change
           are safe and transition to them will not create a microloop.
           Two subtypes are recognized:

transition should be transitioning

-

    The following section formally defines the mechanism.

The following section formally defines a mechanism that can be used to
gaurentee this condition.

-

Section 3.2 is a bit confusing. If I have multiple paths of the same
cost after the topology change, they cannot be a mix of types, simply
because they are all equal cost (?). If I have one path that's type A,
and another path of the same cost, how can that second cost be of type
B, since the types are defined based on the costs of the paths?

-

    While this mechanism does not remove all possible micro-loops, it
    addresses the majority of them in topologies with a reasonable level
    of physical redundancy.  Topologically, micro-loop coverage provided
    by this algorithm is

Is?? Is???? I'm dying to know what the rest of this sentence says!!!! :-)

-

And there's one more, I sent Alex previously:

What are "incornsistencies"?? Corn that's sometimes white and sometimes yellow? Sorry, just couldn't resist!!! <hehe>
:-)

Russ


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

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


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
<Prev in Thread] Current Thread [Next in Thread>