Subject: [rbridge] WGLC comments on problem and applicability statement

From: "Donald Eastlake" <[email-masked]>
Date: Wed, 20 Aug 2008 23:43:21 -0400

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

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

---

From: "Francois Tallet (ftallet)" <[email-masked]>
Date: Thu, 21 Aug 2008 11:03:21 -0700

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

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. I'll be happy if your next draft simply acknowledges that
TRILL does not attempt to prevent temporary loops the way STP does.

Regards,

Francois

________________________________

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

	Hi,

	

	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)

	155 Beaver Street

	Milford, MA 01757 USA

	[email-masked]

---

From: "Donald Eastlake" <[email-masked]>
Date: Thu, 21 Aug 2008 15:15:52 -0400

See below:

On Thu, Aug 21, 2008 at 2:03 PM, Francois Tallet (ftallet) <
[email-masked]> wrote:

> *Section 3.3:*
> *There was one comment that there are no transient loops in Spanning Tree.
> Spanning Tree.*
> 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.

> Francois

Donald

>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Donald Eastlake
> *Sent:* Wednesday, August 20, 2008 8:43 PM
> *To:* [email-masked]
> *Subject:* [rbridge] WGLC comments on problem and applicability statement
>
>   Hi,
>
>
> 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:
>

---

From: "Francois Tallet (ftallet)" <[email-masked]>
Date: Thu, 21 Aug 2008 13:42:30 -0700

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:[email-masked]] 
	Sent: Thursday, August 21, 2008 12:16 PM
	To: Francois Tallet (ftallet)
	Cc: [email-masked]
	Subject: Re: [rbridge] WGLC comments on problem and
applicability statement

	See below:

	On Thu, Aug 21, 2008 at 2:03 PM, Francois Tallet (ftallet)
<[email-masked]> wrote:

		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: [email-masked]
[mailto:[email-masked]] On Behalf Of Donald Eastlake
			Sent: Wednesday, August 20, 2008 8:43 PM
			To: [email-masked]
			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)

			155 Beaver Street

			Milford, MA 01757 USA

			[email-masked]