<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=042265923-07072008>Hi Donald,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=042265923-07072008>Please see inline.</SPAN></FONT></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=gmail_quote>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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><FONT color=#0000ff><BR><SPAN
class=042265923-07072008><FONT face=Arial size=2>[FT>] I got
confirmation from Prof. Eugene that there was a race
condition in a state machine of their simulator. Don't know of any public
paper. I can certainly show you what is wrong in the convergence described in
the paper if you want. I think you will find an email from Mick
Seaman regarding this in the archive of 802.1. In fact, STP/RSTP/MST make
a lot of effort to ensure there is never a forwarding loop. Again, the count
to infinity problem is real, and the solution proposed in the paper is
relevant.</FONT></SPAN><BR></FONT></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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><FONT face=Arial size=2></FONT><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><FONT color=#0000ff><SPAN
class=042265923-07072008><FONT face=Arial
size=2>[FT>] Currently, a port goes to forwarding in
2xforward_delay, and forward_delay is 15 seconds by
default. </FONT></SPAN><BR></FONT> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">...<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><FONT color=#0000ff><SPAN class=042265923-07072008><FONT
face=Arial size=2>[FT>] The comment was mainly on the 65 instead of 64
(which means that up to 65 different topologies are available). How about
something simple like: added support for multiple spanning trees, up to a
maximum of 65. Each vlan is mapped to one of
those. </FONT></SPAN><BR></FONT> <BR></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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><FONT
color=#0000ff><SPAN class=042265923-07072008><FONT face=Arial
size=2>[FT>] A single hub would not be enough to cause a
problem, but a link coming up between two hubs would definitely. That's
explicitly mentioned several times in 802.1. That's a case that can
be avoided by design. I don't think it is correct to define STP based on this
topology, that is explicitly forbidden in the spec. To push this to the
extreme, I can build on purpose a scenario where BPDUs are filtered
and STP does not converge at all. It would not be honest to say STP
does not converge based on this
example;-)</FONT></SPAN><BR></FONT> <BR></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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><FONT color=#0000ff><SPAN class=042265923-07072008><FONT
face=Arial size=2>[FT>] STP is much more than a simple distance
vector protocol. In fact, most of the complexity of STP is precisely to handle
those cases. When the link appear between A and C, at least a port stays
blocked until STP has determined it can safely go to forwarding. STP
and RSTP work differently, but the goal is definitely to avoid any
temporary loop, even the shortest. Just to give you an idea,
I once worked on a bug that introduced a bridging loop during
reconvergence in a customer network. This looped lasted less than 10ms but
created a really critical situation over there. I guess not all customers are
equally sensitive to this requirement, but some do really expect that the
network will never introduce a forwarding loop.</FONT></SPAN><SPAN
class=042265923-07072008><FONT face=Arial size=2> So I don't know if the
goal is to ease the requirements for TRILL, but again, it is not correct to
say that a temporary bridging loop is expected or even acceptable in
a bridged network handled by STP.</FONT></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=042265923-07072008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=042265923-07072008>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=042265923-07072008>Francois</SPAN></FONT></DIV>
<DIV><SPAN class=042265923-07072008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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> </BLOCKQUOTE></BODY></HTML>