Hi,<br><br>See comments below:<br><br><div class="gmail_quote">On Wed, Jul 2, 2008 at 7:00 PM, Francois Tallet (ftallet) <<a href="mailto:ftallet@cisco.com" target="_blank">ftallet@cisco.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>...<br>
<br>
<br>
2.3 page 7:<br>
<br>
There is no forwarding loop in the case described in figure 4. I met with some of the authors of [5] and I'm relatively sad that this paper was published when the conclusion is based on a bug present in their simulator. However, RSTP can indeed suffer from the usual count to infinity issue specific to distance vector protocols that can delay the convergence by few seconds.<br>
</blockquote><div><br>Can you provide some pointer to a discussion of this issue or explain what is wrong with the description of the problem in that paper? Has a retraction or counter paper been published? Just saying there was a bug in their simulator does not explain to me why the problem they describe in text does not occur.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't exactly know where the 45 seconds mentioned here come from. With default timers, a failure is detected in max 20 seconds by STP and convergence is a matter of 30 seconds. With RSTP/MST, it's 6 second to detect a failure (when the protocol does not see a link going down) and the convergence is virtually immediate (does not depend on any timer).</blockquote>
<div><br>I believe that the earliest version of the spanning tree protocol waited 45 seconds before going into the forwarding state. If your figure of 30 seconds is correct for 802.1 STP, then I would think the figure should be adjusted.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
<br>
2.5 page 8<br>
MST arguably provide a max of 65 instances: one CIST and up to 64 MSTIs. I don't understand "one per group of vlans" -> a given vlan is mapped to a unique instance.</blockquote><div><br>Now that there have been a few comments on this, can you suggested better wording?<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.1 page 9-10:<br>
I think that using STP, you are guaranteed that there is no duplication and out of order frames. Frames in transit could be duplicated or re-ordered while RSTP/MST converges. I think that if TRILL relies on TTL to mitigate loops, we'll certainly get more duplication of frames, and more often.</blockquote>
<div><br>What are your assumptions? A topology change like a link to a hub coming up could result in frame duplication until detected.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.3 page 10:<br>
A new link coming up should not be introducing any temporary loop. It's true that you can achieve that by bringing up a link between devices (like hubs) that are not running STP.</blockquote><div><br>Again, what are your assumptions? If you have three bridges A-B-C and a source of broadcast or multicast frames is sending them into A and a link appears between A and C, why don't you have a loop until the link is noticed?<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.4 page 10:<br>
"reference not found"<br>
<br>
3.6 page 11:<br>
802.1v and 802.1s (lower case) are amendments to 802.1Q (capital). Mentioning 802.1Q is probably enough;-)<br>
<br>
Thanks and regards,<br>
François<br>
...</blockquote><div><br>Thanks,<br>Donald </div></div>=============================<br> Donald E. Eastlake 3rd +1-508-634-2066 (home)<br> 155 Beaver Street +1-508-333-2270 (cell)<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a>