[rbridge] Few comments on the latest daft (RE: rbridge Digest, Vol 50, Issue 1)

[Donald Eastlake]

Hi,

See comments below:

On Wed, Jul 2, 2008 at 7:00 PM, Francois Tallet (ftallet) <ftallet at cisco.com>
wrote:

> Hi all,
>
> ...
>
>
> 2.3 page 7:
>
> 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.
>

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.


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


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.


> ...
>
> 2.5 page 8
> 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.


Now that there have been a few comments on this, can you suggested better
wording?


> 3.1 page 9-10:
> 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.


What are your assumptions? A topology change like a link to a hub coming up
could result in frame duplication until detected.


> 3.3 page 10:
> 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.


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?


> 3.4 page 10:
> "reference not found"
>
> 3.6 page 11:
> 802.1v and 802.1s (lower case) are amendments to 802.1Q (capital).
> Mentioning 802.1Q is probably enough;-)
>
> Thanks and regards,
> François
> ...


Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street +1-508-333-2270 (cell)
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080707/d456d2d9/attachment.html