<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN
class=543583419-28072008>Hi Donald,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN
class=543583419-28072008>More inline too... (highlighted in
red)</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><SPAN
class=543583419-28072008></SPAN></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV dir=ltr>
<DIV>
<DIV class=gmail_quote>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=gmail_quote>
<DIV>
<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>
<DIV>
<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></DIV><FONT
color=#0000ff><BR><SPAN><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></FONT></DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>
<DIV>Yes, that was what I wanted, for you to, as I said, "explain what is
wrong with the description of the problem in that paper?" I have no interest
in searching through 802.1 mail archives. I'm guessing that the problem with
the paper is that the stale information can't cycle for as long as the paper
implies because the distance hits a maximum...<BR><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000
size=2>[FT>] The paper is simply wrong in the way it describes the
operation during RSTP reconvergence. The paper show that RSTP opens a loop
during the simple scenario described, which is an implementation bug. I've
found back the reaction of Mick Seaman to the paper, as it seems this is a
reference you appreciate:</FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000 size=2><A
href="http://www.ieee802.org/1/private/email2/msg03582.html">http://www.ieee802.org/1/private/email2/msg03582.html</A></FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008></SPAN><FONT color=#ff0000><SPAN
class=543583419-28072008><FONT face=Arial size=2>[FT>] The
mere fact that the authors, just like you, assumed that it's normal that
STP open a temporary loop during reconvergence shows that they have little
bridging experience (and it's ok, I'm not trying to insult anyone, don't
get me wrong). This common knowledge is just derived from the way routing
protocols operate and the assumption that
STP=RIP. </FONT></SPAN></FONT></DIV>
<DIV><FONT color=#ff0000><SPAN class=543583419-28072008><FONT face=Arial
size=2>I'm not trying to say either that there can never be a bridging loop in
any case when STP is running in a network (more on this below), but it is
shocking to see this paper as a reference for anyone who is quickly searching
how STP works, and this leads to the (imo wrong) assertions you make in the
document.</FONT></SPAN><BR><BR></FONT>I understand that spanning tree
protocols try hard to minimize loops and that modern equipment and links are
quite reliable so even transient loops are rare. But, as far as I can tell,
the claim you repeat above, that there is "never a forwarding loop" with STP,
just isn't true. I really hate arguing based on "authority" rather than the
real technical facts, but I have spoken with Mick Seaman and Norm Finn and
they agree that transient loops are possible with loss of a sufficient number
of BPDUs or temporarily undetected changes in topology although, as I say,
this is obviously a rare occurrance in the real world.</DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=gmail_quote>
<DIV>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.</DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV class=gmail_quote>
<DIV>
<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></DIV><FONT
color=#0000ff><SPAN><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></FONT><BR></DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>Could you provide citations to these multiple explicit mentions in
"802.1" and exactly where which 802.1 standard forbids having more than one
hub in a bridged LAN? A quick search shows no occurrences of hub in 802.1Q and
exactly one occurrence in 802.1D. That occurrence in informational Annex K.1
when it mentions that the undetected appearance of connectivity as a way you
could get frame duplication or re-ordering, and it gives the appearance of a
link between two hubs as one example. That annex is not normative text
anyway. </DIV>
<DIV><BR></DIV>
<DIV>I do not agree that there is any equivalence between (1) dropping or
garbling BPDUs due to noise or other line glitches and a link coming up due,
for example, to a hub or repeater intermittently failing and transitioning
from the failed to the non-failed state and (2) and inserting a deliberate
BPDU filter. The first is normal, albeit unlikely, random occurrence due to
the imperfections of the real world. The second is a deliberate attempt to
cause failure. In any case, I don't think anyone said that "STP does not
converge". I merely made the true statement that transient loops are possible
with STP.<BR><SPAN class=543583419-28072008><FONT face=Arial size=2><FONT
color=#ff0000>[FT>] Exactly!</FONT> <FONT color=#ff0000>I
perfectly agree with that and let me elaborate my answer based on
this.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>The
example I gave about a device filtering BPDUs is not absurd. For instance,
Cisco is using some proprietary form of STP using a proprietary destination
mac address for its BPDUs. Some third party devices had the really weird idea
of selectively discarding those BPDUs. As soon as you inserted such a device
in a Cisco network running PVST, you could get a permanent loop. In that case,
you can say that STP does not converge. But this is something that can
hopefully be avoided, by design. </FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008></SPAN><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>STP is indeed
making some assumptions on the network. You won't be guaranteed that there is
no temporary bridging loops if there are hubs in your topology (that's just
what I meant when I said it was "forbidden", sorry about that, I'm not a
native English speaker) or more generally if STP does not see the link state
changes. This property of the network can be enforced with great accuracy by
design just like you can avoid devices filtering BPDUs. All the complex
mechanisms built in STP only make sense if you are running in such a network,
and our customers (who again, might be sensitive to 10ms forwarding loop) are
definitely using STP in an appropriate network. BTW, they are also using point
to point links between switches so that they can benefit from fast convergence
(generally sub-second with decent hw), even if it is always mentioned that STP
can only converge in 30 seconds.</FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>Now,
once you have properly designed your network, you can still get some loops. As
you mentioned earlier, dropping BPDUs could open a loop. But it's not as
likely as you might think. STP makes the relatively reasonable assumption that
if no BPDU can go through a link, then no data traffic is forwarded either. In
order to open a loop, you would need to loose all consecutive BPDUs that
STP sends on a link (every 2 seconds) for 30 seconds while still
forwarding data traffic! A single BPDU going through would reset the
timer for 30 seconds. Honestly, if it's not impossible, getting even a
transient loop in those conditions is pretty unlikely. In fact, you are much
more likely to get a loop as a result of an implementation bug (as the
one in the simulator of professor Eugene;-). </FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=543583419-28072008></SPAN><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>There
should never be a temporary loop during the normal operation of STP
in the network, just like a plane should never crash. It does not mean that
planes never crash, just that a lot of effort has been put so that getting a
crash is not trivial.</FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008></SPAN><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>Unless I'm
simplifying TRILL the same way you are simplifying STP, I don't think there is
any effort to prevent temporary loops with TRILL. You just have the
typical loop mitigation mechanism that is a TTL in the frames. That's why
I don't think it is appropriate at all to justify the lack of loop prevention
in TRILL by comparing its behavior to STP. It's just like comparing flying
with playing Russian roulette! Sure, you can potentially die in both cases,
but they're *very* different.</FONT></SPAN></DIV>
<DIV><BR></DIV>
<DIV>While the wording the draft may be overly critical of STP and should
probably be adjusted, I really get tired of these sloppy claims of magical
perfection for STP.<BR><FONT face=Arial><FONT size=2><SPAN
class=543583419-28072008><FONT color=#ff0000>[FT>] I'm likewise
tired of constantly hearing the sloppy claim that introducing IS-IS
will magically fix all the "STP flaws" from people who just ignore
the constraints imposed by bridging. I challenge you to replace STP with IS-IS
and get a safer way of doing bridging. </FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><SPAN
class=543583419-28072008></SPAN></FONT></FONT><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000 size=2>With TRILL, you
have not just replaced STP, you have changed the way bridging frames is
achieved (which most likely implies new hardware for most switch vendors, not
just a software upgrade). It's not IS-IS that decrements a TTL, it's not IS-IS
that cause a frame that is not in a routing table to be dropped instead of
being flooded. Even if I perfectly agree with the choice of IS-IS, TRILL or
its equivalent could have been implemented using OSPF, EIGRP, RIP or... STP as
a control protocol!! That's why I think claiming that TRILL is fixing "STP
flaws" is just not correct.</FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008></SPAN><SPAN
class=543583419-28072008><FONT face=Arial color=#ff0000
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=543583419-28072008><FONT face=Arial color=#ff0000
size=2>Francois</FONT></SPAN></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV
class=gmail_quote> </DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>