[email protected]
[Top] [All Lists]

Re: Comparison of symmetric and asymmetric PLSN algorithms

Subject: Re: Comparison of symmetric and asymmetric PLSN algorithms
From: Alia Atlas
Date: Tue, 14 Jun 2005 11:10:10 -0400
At 11:36 AM 6/13/2005, mike shand wrote:
At 16:01 13/06/2005, Alia Atlas wrote:
At 08:24 AM 6/8/2005, mike shand wrote:
At 22:29 07/06/2005, mike shand wrote:
At 21:56 07/06/2005, Alia Atlas wrote:
So this is more of a swings and roundabouts case.

I'm beginning to think that we can ignore the asymmetric cost case unless we have evidence that doing so would make things dramatically worse.
You aren't catching real multi-hop loops in the topologies that you have?
Not sure what you mean. There can't be any loops in the converged topologies.
What I was asking was whether you are seeing multi-hop micro-forwarding
loops using the symmetric condition & PLSN during the transition on the
real network topologies that you have.
  What about cases where one direction of the link changes to be max-cost?
Interesting. Of course if the connectivity fails in just one direction the
reverse connectivity check (does OSPF have that to?) would cause BOTH
directions to be treated as failed simultaneously. Going to max-cost is a
different matter since I don't think implementations count that as failing
the RCC.
My first take on this is that it shouldn't make any difference since in
the SPT a link can only ever exist in one direction (or none) at once.
Do you think such a topology transformation is likely to cause the multi-hop loops.
On the above quick analysis, no, but I reserve the right to be wrong:-)
I was asking about the max-costing because that is something that does
occur in networks to cause asymmetric link costs.
If the networks with asymmetric link costs that you have seem to have fewer
unresolved micro-loops across fewer links using the symmetric condition,
then that's a good start to think that the symmetric condition is the way
to go. To be even more comfortable with that, it'd be very good to see if
similar behavior holds with links costed out causing asymmetric costs. I
imagine that the primary case to consider might be when an entire router's
links are all costed-out, as in RFC3137. An operator taking a link out via
costing would probably do it in both directions; similarly, the costing out
of a link due to lack of an LDP session should occur in both directions -
though it needn't.

I just tried a randomly generated topology with all (very) asymmetric links and managed to produce a 9 hop loop, which traversed 6 type C nodes, 2 type As and a type B!!!
Excellent! I assume this was using the symmetric condition- because there
are type As and a type B in it? What does it look like using the
asymmetric one?
Do you think we can adequately describe the topology conditions that can
lead to the multi-hop micro-loop problem with the symmetric condition?
Alia

Testing path from node 8 (8) to node 7 (7) at time 1

Node 8 (8): Packet discarded because looped
Node 19 (19) New: Forwarded via adj 1 over link 42 to node 8
Node 3 (3) New: Forwarded via adj 1 over link 13 to node 19
Node 28 (28) New: Forwarded via adj 1 over link 37 to node 3
Node 18 (18) New: Forwarded via adj 1 over link 18 to node 28
Node 29 (29) New: Forwarded via adj 1 over link 47 to node 18
Node 22 (22) New: Forwarded via adj 1 over link 23 to node 29
Node 11 (11) Temp: Forwarded via adj 1 over link 44 to node 22
Node 26 (26) Old: Forwarded via adj 1 over link 8 to node 11
Node 8 (8) Old: Forwarded via adj 1 over link 15 to node 26

(read the trace going up)

Node 11 is type B and nodes 3 and 11 are type A for the destination node 7

So at time 1 (when the type C's change), type A MUST forward according to new topology, type B according to the temporary type B next hop, and the type C either according to old or new topology (since they are in the process of changing)
So, yes, we can get multi-hop loops with the asymmetric algorithm!

        Mike


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

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