[rbridge] WGLC comments on problem and applicability statement

Thu Aug 21 13:42:30 PDT 2008

Simple: It is a major design goal for STP to avoid temporary loops. It
not one for routing protocols and TRILL. This is partly because L3 and
TRILL have a loop mitigation mechanism in the data plane that does not
currently exist at L2 and a different forwarding scheme. I hope you can
agree on that. I'll let you word this adequately as I'm again not a
native English speaker. 

I have the same kind of emotional reaction as yours when I see some of
those routing vs. bridging presentations that emphasize how normal it is
for bridged networks running STP to experience transient loops. And for
now, your draft is explicitly written to stress that, by quoting the
bogus result from this research paper and putting side by side the fact
that transient loops are possible with STP and the expectation for TRILL
in this regard. This is wrong. 

I don't think it is diminishing the merit of L3 protocols or TRILL to
quote that they don't have the same requirement as STP. I'm including
below the link to two recent papers from Mick Seaman, who has been
attempting to put the same level of loop prevention as STP in a link
state based control protocol for L2. That will give a perspective of
what is missing in TRILL to reach the same level as STP in this regard.
Of course, if anyone has a simpler way of doing this, please let us
know. I'm not saying this ironically, it would be really great.

http://www.ieee802.org/1/files/public/docs2008/aq-seaman-link-state-brid
ging-0508.pdf
http://www.ieee802.org/1/files/public/docs2008/aq-seaman-link-state-brid
ging-part2-0708.pdf

Francois

________________________________

	From: Donald Eastlake [mailto:d3e3e3 at gmail.com] 
	Sent: Thursday, August 21, 2008 12:16 PM
	To: Francois Tallet (ftallet)
	Cc: rbridge at postel.org
	Subject: Re: [rbridge] WGLC comments on problem and
applicability statement

	See below:

	On Thu, Aug 21, 2008 at 2:03 PM, Francois Tallet (ftallet)
<ftallet at cisco.com> wrote:

		Just a comment on section 3.3's summary:

		Section 3.3:

		There was one comment that there are no transient loops
in Spanning Tree. This is incorrect. Transient loops, however unlikely,
are possible with Spanning Tree.

		You actually made the comment that some people were
claiming there could not ever be a loop with STP (I will never make that
claim as I would have a hard time justifying what I'd been working on
for 10 years;-)

	[dee3] Of course I can't actually tell what is in some else's
mind or what their motivations are but I've heard many statement that
would give many people the false impression that there can never be
temporary loops with any version of spanning tree. I've seem
presentations comparing spanning tree with "routing" that give the false
impressions that no version of spanning tree can ever have a transient
loop but that "routing protocols" routinely have persistent loops.

		The real comment is that the draft is using what can be
considered exceptional STP failure scenarios to justify TRILL's normal
way of operation.

	[dee3] This document is not the protocol specification. It is
the problem statement and applicability document. It sets only very
broad bounds on how whatever TRILL protocol is adopted would work. If
you want to claim that it would allow such a "way of operation", fine.
But I don't see it as specifying or justifying any particular "normal
way of operation".

		I'll be happy if your next draft simply acknowledges
that TRILL does not attempt to prevent temporary loops the way STP does.

	[dee3] It seems unlikely that the TRILL protocol will do much of
anything the same way STP does and I think that is pretty clear from the
document. As is always the case when you are requesting a change in a
draft, it would be good to provide a specific wording change suggestion.

		Regards,

		Francois

	Donald

________________________________

			From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake
			Sent: Wednesday, August 20, 2008 8:43 PM
			To: rbridge at postel.org
			Subject: [rbridge] WGLC comments on problem and
applicability statement

			Hi,

			Below is my summary of the Working Group Last
Call comments on draft-ietf-trill-prob-04.txt.

			General:

			There appears to be a rough consensus that the
draft is excessively critical of spanning tree and this should be
corrected in several places.

			Abstract:

			There were a number of complaints about the
abstract; however the abstract is reasonably consistent with the body.
Rather than considering such complaints twice, any problems with the
body should be fixed and then the abstract adjusted to be consistent
with the revised body.

			Introduction:

			Comments in the draft concerning spanning tree
slow convergence need, at a minimum, to be qualified to indicate they
generally do not apply to RSTP.

			Section 2:

			There were complaints when 802.1Q was
referenced, saying that previous amendment that were incorporated such
as 802.1s should be referenced instead. And there were complaints when
amendments such as 802.1s were referenced in other parts of the document
saying that they no longer exist and no amendments that have been rolled
into the 802.1Q base document should be mentioned separately.

				In the normal case, when not otherwise
qualified, "802.1Q" should refer to the current IEEE 802.1Q standard at
the time this draft is published and as specified in the References
section; however, there is no particular harm in referring to earlier
amendments that have been rolled into 802.1Q as long as their status is
mentioned.

			Section 2.1:

			There was one comment that thicknet, thinnet,
and hubs should not be mentioned because they no longer exist but the
reference to them is historical and there are still hubs, at least, in
use.

			Section 2.2:

			There is a statement in the draft intended to
compare ECMP link-state with non-ECMP link state which may appear to be
a comparison between ECMP link-state with STP. This should be clarified.

			Section 2.3:

			The referenced paper (reference [5] in the
draft) contains serious errors and should probably not be referenced.
But, as Francois Tallet said, "RSTP can indeed suffer from the usual
count to infinity issue specific to distance vector protocols that can
delay the convergence by few seconds."

			Section 2.5:

			That there are actually 65 trees available with
MSTP and that each is used for forwarding a non-overlapping set of VLANs
should be clarified.

			Section 3.3:

			There was one comment that there are no
transient loops in Spanning Tree. This is incorrect. Transient loops,
however unlikely, are possible with Spanning Tree.

			Section 3.4:

			One missing reference.

			Thanks,

			Donald (co-chair)

			=============================

			Donald E. Eastlake 3rd +1-508-634-2066 (home)

			155 Beaver Street

			Milford, MA 01757 USA

			d3e3e3 at gmail.com

	=============================
	Donald E. Eastlake 3rd +1-508-634-2066 (home)
	155 Beaver Street
	Milford, MA 01757 USA
	d3e3e3 at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080821/3d5eff67/attachment-0001.html