From d3e3e3 at gmail.com  Sun Aug 10 12:44:35 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 10 Aug 2008 15:44:35 -0400
Subject: [rbridge] New personal RBridge IS-IS draft
Message-ID: <1028365c0808101244p2d0140c5s300f61a0eb8e3d30@mail.gmail.com>

My draft on RBridge use of IS-IS has been updated. Almost all the changes
are to bring it into correspondence with the -08 version of the base
protocol draft (draft-ietf-trill-rbridge-protocol-08.txt) and the -03
version of the L2 IS-IS draft (draft-ward-l2isis-03.txt).
See draft-eastlake-trill-rbridge-isis-01.txt.

Thanks,
Donald
=============================
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/20080810/b0d0618a/attachment.html

From d3e3e3 at gmail.com  Thu Aug 14 07:45:56 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 14 Aug 2008 10:45:56 -0400
Subject: [rbridge] Fwd: Please ask your WG...
In-Reply-To: <20080803144322.AA9033A68BA@core3.amsl.com>
References: <20080803144322.AA9033A68BA@core3.amsl.com>
Message-ID: <1028365c0808140745w70463784lf18aaa323256de40@mail.gmail.com>

Hi,
Please consider volunteering for the IETF nominations committee as below.

Thanks,
Donald

---------- Forwarded message ----------
From: NomCom Chair <nomcom-chair at ietf.org>
Date: Sun, Aug 3, 2008 at 10:43 AM
Subject: Please ask your WG...
To: Working Group Chairs <wgchairs at ietf.org>


To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
   https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617
Whether you copy that message, or reference is probably up to you and the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
   https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618

Thank you,
Joel M. Halpern
Nomcom Chair
jmh at joelahlpern.com
nomcom-chair at ietf.org



-- 
=============================
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/20080814/3750cb87/attachment.html

From d3e3e3 at gmail.com  Wed Aug 20 20:43:21 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 20 Aug 2008 23:43:21 -0400
Subject: [rbridge] WGLC comments on problem and applicability statement
Message-ID: <1028365c0808202043ne58384dl8fddeaec230f3e27@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080820/b25d68f3/attachment.html

From ftallet at cisco.com  Thu Aug 21 11:03:21 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Thu, 21 Aug 2008 11:03:21 -0700
Subject: [rbridge] WGLC comments on problem and applicability statement
In-Reply-To: <1028365c0808202043ne58384dl8fddeaec230f3e27@mail.gmail.com>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E014C63CB@xmb-sjc-229.amer.cisco.com>

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

	
	

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

From d3e3e3 at gmail.com  Thu Aug 21 12:15:52 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 21 Aug 2008 15:15:52 -0400
Subject: [rbridge] WGLC comments on problem and applicability statement
In-Reply-To: <9D2A87BDA62A8041AFE4E3D20FC1786E014C63CB@xmb-sjc-229.amer.cisco.com>
References: <1028365c0808202043ne58384dl8fddeaec230f3e27@mail.gmail.com>
	<9D2A87BDA62A8041AFE4E3D20FC1786E014C63CB@xmb-sjc-229.amer.cisco.com>
Message-ID: <1028365c0808211215u7614ab82pdc90a1437c6b87e6@mail.gmail.com>

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/4c39e8d1/attachment.html

From ftallet at cisco.com  Thu Aug 21 13:42:30 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Thu, 21 Aug 2008 13:42:30 -0700
Subject: [rbridge] WGLC comments on problem and applicability statement
In-Reply-To: <1028365c0808211215u7614ab82pdc90a1437c6b87e6@mail.gmail.com>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E014C64E3@xmb-sjc-229.amer.cisco.com>

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

From d3e3e3 at gmail.com  Fri Aug 22 10:03:05 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 22 Aug 2008 13:03:05 -0400
Subject: [rbridge] draft-eastlake-trill-rbridge-notes-00.txt
Message-ID: <1028365c0808221003x4552490cv1c7bc93f73e2fd9e@mail.gmail.com>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Rbridge Notes
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-eastlake-trill-rbridge-notes-00.txt
	Pages		: 20
	Date		: 2008-8-20
	
This document provides additional informational material related to
   RBridges, which are devices that implement the TRILL protocol. It is
   a supplement to the RBridges base protocol specification and includes
   discussion of tradeoffs in some features and configurations of
   RBridges. In addition, it provides a sketch of a proof that, with
   reasonable assumptions, persistent loops do not occur in a TRILL
   campus.

A URL for this Internet-Draft
is:http://www.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-notes-00.txt

Internet-Drafts are also available by anonymous FTP
at:ftp://ftp.ietf.org/internet-drafts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080822/3bf52961/attachment.html