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

From: "Francois Tallet (ftallet)" <[email-masked]>
Date: Wed, 2 Jul 2008 16:00:25 -0700

Hi all,

I'm new to the alias and I'm very excited to follow the progress of TRILL: it's been a while we've been waiting for a breakthrough at L2 and I'm just sorry there is not more cooperation between the IEEE and the IETF on that.

I have an 802.1 background and I found the document a little bit confusing in the way it associates the spanning tree required in the data plane to forward traffic in bridged networks nowadays (with all the limitations you rightfully mention) , and the spanning tree protocol, running at the control level. The fact that we can learn mac addresses is derived from the assumption that there is a single path between any two devices in the network. The fact that we don't have a TTL, that we don't have any indication about the location of a device based on its address and that we flood unknown traffic are data plane choices that have shaped the control plane, not the other way around. I just mean that I think TRILL is as much if not more a data plane enhancement than a control plane enhancement. I don't think that replacing STP by ISIS while keeping those data plane constraints would provide any significant advantage... I know it's not a proof whatsoever, but the IEEE would have already done it if it was;-) Actually, we tried with 802.1aq, that was initially supposed to work with existing bridges. However, while slowly progressing, Shortest Path Bridging is accumulating new hardware requirements (i.e. data plane changes) that were not desired initially. It's because TRILL did not care about preserving the existing hardware that it is now much ahead of 802.1aq.
Anyway, all this to say that I think the document is focusing too much on the spanning tree control protocols while they're not the real justification for TRILL imo.

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.

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

The fact that you cannot segment an L2 network is again based on the way frames are forwarded... You cannot tell from the L2 address whether a station belong to a particular region, as a result, the L2 control protocol has to span the whole network and take care of loops itself. Introducing ISIS would not help if we kept the same way of handling the data frames (flooding unknown unicast etc...)

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.

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.

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.

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 

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of 
| [email-masked]
| Sent: Wednesday, July 02, 2008 12:00 PM
| To: [email-masked]
| Subject: rbridge Digest, Vol 50, Issue 1
| 
| Send rbridge mailing list submissions to
| 	[email-masked]
| 
| To subscribe or unsubscribe via the World Wide Web, visit
| 	http://mailman.postel.org/mailman/listinfo/rbridge
| or, via email, send a message with subject or body 'help' to
| 	[email-masked]
| 
| You can reach the person managing the list at
| 	[email-masked]
| 
| When replying, please edit your Subject line so it is more 
| specific than "Re: Contents of rbridge digest..."
| 
| 
| Today's Topics:
| 
|    1. WG LC draft-ietf-trill-prob-04.txt (Donald Eastlake)
| 
| 
| ----------------------------------------------------------------------
| 
| Message: 1
| Date: Tue, 1 Jul 2008 23:06:46 -0400
| From: "Donald Eastlake" <[email-masked]>
| Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
| To: [email-masked]
| Message-ID:
| 	<[email-masked]>
| Content-Type: text/plain; charset="iso-8859-1"
| 
| Hi,
| This message initiates a two week TRILL Working Group Last 
| Call on the draft below.
| 
| Thanks,
| Donald and Erik
| 
| 2008/6/27 <[email-masked]>:
| 
| > A New Internet-Draft is available from the on-line Internet-Drafts 
| > directories.
| > This draft is a work item of the Transparent 
| Interconnection of Lots 
| > of Links Working Group of the IETF.
| >
| >
| >        Title           : Transparent Interconnection of 
| Lots of Links
| > (TRILL): Problem and Applicability Statement
| >        Author(s)       : J. Touch, R. Perlman
| >        Filename        : draft-ietf-trill-prob-04.txt
| >        Pages           : 18
| >        Date            : 2008-06-27
| >
| > Current Ethernet (802.1) link layers use custom routing 
| protocols that 
| > have a number of challenges. These routing protocols need 
| to strictly 
| > avoid loops, even temporary loops during route propagation,
| >
| >
| >  because of the lack of header loop detection support. 
| Routing tends 
| > not to take full advantage of alternate paths, or even non- 
| > overlapping pairwise paths (in the case of spanning trees). The 
| > convergence of these routing protocols and stability under link 
| > changes and failures is also of concern. This document 
| addresses these 
| > concerns and suggests that they are related to the need to 
| be able to 
| > apply modern network layer routing protocols at the link 
| layer. This 
| > document assumes that solutions would not address issues of 
| > scalability beyond that of existing bridged (802.1) links, 
| but that a 
| > solution would be backward compatible with 802.1, including hubs, 
| > bridges, and their existing plug-and-play capabilities.
| >
| > This document is a work in progress; we invite you to 
| participate on 
| > the mailing list at http://www.postel.org/rbridge
| >
| > A URL for this Internet-Draft is:
| > http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-04.txt
| >
| > Internet-Drafts are also available by anonymous FTP at:
| > ftp://ftp.ietf.org/internet-drafts/
| >
| > Below is the data which will enable a MIME compliant mail reader 
| > implementation to automatically retrieve the ASCII version of the 
| > Internet-Draft.
| >
| >
| =============================
| Donald E. Eastlake 3rd
| 155 Beaver Street
| Milford, MA 01757 USA
| [email-masked]
| -------------- next part --------------
| An HTML attachment was scrubbed...
| URL: 
| http://mailman.postel.org/pipermail/rbridge/attachments/200807
| 01/94089f0e/attachment-0001.html
| 
| ------------------------------
| 
| _______________________________________________
| rbridge mailing list
| [email-masked]
| http://mailman.postel.org/mailman/listinfo/rbridge
| 
| 
| End of rbridge Digest, Vol 50, Issue 1
| **************************************
| 

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Steve Dalberg" <[email-masked]>
Date: Wed, 2 Jul 2008 17:35:34 -0700

Two comments:

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

A group of Vlans can be mapped to an IST.  It isn't necessarily a 1:1
mapping of vlans to instances, in fact, it usually isn't...  It reads
clearly to me, can you describe how you are reading it, or what the
problem is?

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

Can you describe the reasoning here?  Do you mean during non-convergence
times?

Steve

---

From: "Donald Eastlake" <[email-masked]>
Date: Mon, 7 Jul 2008 19:05:52 -0400

Hi,

See comments below:

On Wed, Jul 2, 2008 at 7:00 PM, Francois Tallet (ftallet) <[email-masked]>
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?

> ...

Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street +1-508-333-2270 (cell)
Milford, MA 01757 USA
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Francois Tallet (ftallet)" <[email-masked]>
Date: Mon, 7 Jul 2008 18:04:59 -0700

Hi Donald,
Please see inline.

		2.3 page 7:

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

	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.
	[FT>] Currently, a port goes to forwarding in 2xforward_delay, and forward_delay is 15 seconds by default. 

		...
		
		2.5 page 8

	Now that there have been a few comments on this, can you suggested better wording?
	[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. 

		3.1 page 9-10:

	What are your assumptions? A topology change like a link to a hub coming up could result in frame duplication until detected.
	[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;-)

		3.3 page 10:

	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?
	[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. 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.
	 
	Regards,
	Francois

		3.4 page 10:
		"reference not found"
		
		3.6 page 11:
		
		Thanks and regards,
		François
		...

	Thanks,
	Donald

---

From: "Donald Eastlake" <[email-masked]>
Date: Sat, 26 Jul 2008 23:28:26 -0400

Hi Francois,
See inline

On Mon, Jul 7, 2008 at 9:04 PM, Francois Tallet (ftallet) <[email-masked]>
wrote:

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

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.

> Then the number in the draft should probably be changed to 30 seconds.

> [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.
>
> OK. Or I suppose it could say something like "one per non-overlapping group
of VLANs".

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

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.

> [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.
>
> Why do you believe this is true in all cases? Once again, I must ask what
your assumptions are. Are you assuming some particular technology for the
link which was down and comes up and that this signals the ports so at A and
C so that if they were in forwarding state that transition out of that
state? If you are assuming that, how can you know it to be true for all link
technologies?

> 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. 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.
>
> I don't know what you mean exactly by "expected". And I certainly don't
claim loops are common. Pretty much all routing and forwarding protocols
have as a goal to minimize the probability and duration of temporary loops
but, while they should have as an absolute goal the elimination of
persistent loops under reasonable assumptions, I have seen no evidence that
it is practical to completely eliminate the possibility of transient loops.

The impression I have is that the problem presented in the paper to which
you object can occur but cannot persist for tens of seconds as their flawed
simulation showed; that it involves a count-to--infinity but infinity is
only ~8 in this case; as a result, if RSTP BPDU transmission rate limiting
was in effect when this occurred, a transient loop could exist for a lot
longer than the 10ms you cite as causing a problem (in fact, earlier in your
message you say "few seconds" which can clearly be fatal for some networks).

As far as I can tell, the very common statement that "there is never a
forwarding loop with spanning tree" is, in its unqualified form, not true.
On closer examination, I have always found that the speaker was speaking
informally and what they really meant was one of the following two true
statement (1) "given reasonable assumptions, there is never a persistent
loop with spanning tree" or (2) "there is never a transient loop with
spanning tree unless one of the unlikely conditions that would cause such a
transient loop occurs".

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.

> 155 Beaver Street
155 Beaver Street

---

From: "Francois Tallet (ftallet)" <[email-masked]>
Date: Mon, 28 Jul 2008 14:27:17 -0700

Hi Donald,
More inline too... (highlighted in red)

				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.

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

	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...
	[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:
	http://www.ieee802.org/1/private/email2/msg03582.html
	[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. 
	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.
	
	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.

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

	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. 

	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.
	[FT>] Exactly! I perfectly agree with that and let me elaborate
my answer based on this.
	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. 
	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.
	 
	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;-).  
	 
	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.
	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.

	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.
	[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. 
	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.
	Regards,
	Francois