At 22:29 07/06/2005, mike shand wrote:
At 21:56 07/06/2005, Alia Atlas wrote:
Do you have any info on the length of the multi-hop loops? I.e., one
loop that is 5 links long might want to count more...
The numbers are very interesting.
No. At the moment I don't even know how many multihop loops there
are (if any). Of course I could record both of those statistics... I'll
see what I can do tomorrow.
Well, it turns out that it is rather more difficult than I thought to get
this information owing to the recursive way I explore for loops. However,
it seems this was a bad choice of network, since despite the presence of
asymmetric costs there are no multi-hop loops caused by them. So it is not
surprising that we get the result we did!
Going back to the original asymmetric cost diagram that Pierre used, we get
the following results
4 5 3 of which are 3 hop loops
8 6 all 6 of which are 3 hop loops
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.
My only caveat would be that if we want to combine PLSN with some other
loop prevention technique to get 100% coverage (e.g. using tunnels only for
the cases not dealt with by PLSN), then we should probably use the
asymmetric cost algorithm even though it might result in using more tunnels
than necessary. The reason is that the multi-hop loops which occur while
using the symmetric cost algorithm are (currently) unpredictable, and hence
it is difficult to know when to use a tunnel to avoid them. Whereas the
extra single link loops which occur by using the asymmetric algorithm are
at least predictable (they can only occur over type C pairs). Of course if
we could figure out how to predict the multi-hop loops, then this wouldn't
Hmmm. Is it true that using the asymmetric algorithm prevents ALL multi-hop
links, or can we still get multi-hop loops around cycles which are all type C.
The more I think about this the more my brain hurts.
Rtgwg mailing list
Rtgwg mailing list