From d3e3e3 at gmail.com  Tue Jul  1 20:06:46 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 1 Jul 2008 23:06:46 -0400
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
Message-ID: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>

Hi,
This message initiates a two week TRILL Working Group Last Call on the draft
below.

Thanks,
Donald and Erik

2008/6/27 <Internet-Drafts at ietf.org>:

> 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
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080701/94089f0e/attachment.html

From ftallet at cisco.com  Wed Jul  2 16:00:25 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Wed, 2 Jul 2008 16:00:25 -0700
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <mailman.5.1215025203.13569.rbridge@postel.org>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E01136397@xmb-sjc-229.amer.cisco.com>

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: rbridge-bounces at postel.org 
| [mailto:rbridge-bounces at postel.org] On Behalf Of 
| rbridge-request at postel.org
| Sent: Wednesday, July 02, 2008 12:00 PM
| To: rbridge at postel.org
| Subject: rbridge Digest, Vol 50, Issue 1
| 
| Send rbridge mailing list submissions to
| 	rbridge at postel.org
| 
| 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
| 	rbridge-request at postel.org
| 
| You can reach the person managing the list at
| 	rbridge-owner at postel.org
| 
| 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" <d3e3e3 at gmail.com>
| Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
| To: rbridge at postel.org
| Message-ID:
| 	<1028365c0807012006j4c6e130el38ba48b6713bd48b at mail.gmail.com>
| 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 <Internet-Drafts at ietf.org>:
| 
| > 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
| d3e3e3 at gmail.com
| -------------- next part --------------
| An HTML attachment was scrubbed...
| URL: 
| http://mailman.postel.org/pipermail/rbridge/attachments/200807
| 01/94089f0e/attachment-0001.html
| 
| ------------------------------
| 
| _______________________________________________
| rbridge mailing list
| rbridge at postel.org
| http://mailman.postel.org/mailman/listinfo/rbridge
| 
| 
| End of rbridge Digest, Vol 50, Issue 1
| **************************************
| 


From sdalberg at marchex.com  Wed Jul  2 17:35:34 2008
From: sdalberg at marchex.com (Steve Dalberg)
Date: Wed, 2 Jul 2008 17:35:34 -0700
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <9D2A87BDA62A8041AFE4E3D20FC1786E01136397@xmb-sjc-229.amer.cisco.com>
References: <mailman.5.1215025203.13569.rbridge@postel.org>
	<9D2A87BDA62A8041AFE4E3D20FC1786E01136397@xmb-sjc-229.amer.cisco.com>
Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50DAA7681@exchbe1sea.windows.marchex.com>

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 ftallet at cisco.com  Thu Jul  3 15:06:24 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Thu, 3 Jul 2008 15:06:24 -0700
Subject: [rbridge] rbridge Digest, Vol 50, Issue 2
In-Reply-To: <mailman.3.1215111601.11453.rbridge@postel.org>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E01136701@xmb-sjc-229.amer.cisco.com>

Hi Steve,

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

There are 4K vlans and each of them must be mapped to a unique instance
among 65, so of course, more than one vlan can be mapped to a particular
instance. But a given vlan cannot be mapped to two different instances,
that's why the "one instance per group of vlans" did not seem very clear
to me. That's not arbitrary groups 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 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?
| 

Well, that might just be my ignorance of the detail of TRILL;-) 802.1Q
acknowledges that some applications are sensitive to duplication and out
of order frames and might require STP in the network. If TRILL provides
equivalent capability in this regard, is there a way that we can ensure
that we won't get out of order and duplicate frames, even during
reconvergence?

Regards,
	Francois

| Steve
| 
| 
| 
| 
| ------------------------------
| 
| _______________________________________________
| rbridge mailing list
| rbridge at postel.org
| http://mailman.postel.org/mailman/listinfo/rbridge
| 
| 
| End of rbridge Digest, Vol 50, Issue 2
| **************************************
| 


From d3e3e3 at gmail.com  Sun Jul  6 12:14:14 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 6 Jul 2008 15:14:14 -0400
Subject: [rbridge] Dublin TRILL meeting cancelled
Message-ID: <1028365c0807061214rb2e5563r990da7acfb738020@mail.gmail.com>

Hi,

There do not seem to be any critical topics for the Dublin meeting and
several document authors can't make it so we are canceling the Dublin TRILL
meeting.

Thanks,
Donald & Erik
=============================
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/20080706/8b2a516e/attachment.html

From d3e3e3 at gmail.com  Mon Jul  7 16:05:52 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 7 Jul 2008 19:05:52 -0400
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <9D2A87BDA62A8041AFE4E3D20FC1786E01136397@xmb-sjc-229.amer.cisco.com>
References: <mailman.5.1215025203.13569.rbridge@postel.org>
	<9D2A87BDA62A8041AFE4E3D20FC1786E01136397@xmb-sjc-229.amer.cisco.com>
Message-ID: <1028365c0807071605j2156024w679a24c6f688964e@mail.gmail.com>

Hi,

See comments below:

On Wed, Jul 2, 2008 at 7:00 PM, Francois Tallet (ftallet) <ftallet at cisco.com>
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?


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


Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street +1-508-333-2270 (cell)
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080707/d456d2d9/attachment.html

From ftallet at cisco.com  Mon Jul  7 18:04:59 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Mon, 7 Jul 2008 18:04:59 -0700
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <1028365c0807071605j2156024w679a24c6f688964e@mail.gmail.com>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E0119ADEB@xmb-sjc-229.amer.cisco.com>

Hi Donald,
Please see inline.

		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.
	

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

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

		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?
	[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:
		802.1v and 802.1s (lower case) are amendments to 802.1Q (capital). Mentioning 802.1Q is probably enough;-)
		
		Thanks and regards,
		Fran?ois
		...


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

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

From Radia.Perlman at sun.com  Wed Jul  9 10:49:47 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 09 Jul 2008 10:49:47 -0700
Subject: [rbridge] Optional pseudonode
Message-ID: <4874FA3B.4050108@sun.com>

The notion of automatic pseudonode minimization was apparently discussed 
at the last IETF in either rtgwg or IS-IS. I wasn't
there, but heard there was not much interest, because there is already a 
solution to that (configuration).

The reason it was brought up outside of TRILL was because some people 
thought it was a good enough idea to
deploy in IS-IS in general, an perhaps even OSPF.

However, I think that even if IS-IS and OSPF are not interested in 
retrofiting this feature, I think it is a good idea
to do it in TRILL. It is quite simple, safe, and does not require 
retrofit, and is actually more useful of a feature in
TRILL than in layer 3 deployments of IS-IS.

In a lot of TRILL deployments all the links will be pt-to-pt (bridges 
and shared media would have gone away), so it does
seem like a good idea to have a safe zero-configuration method of 
eliminating pseudonodes in that case (if all RBridge adjacencies
resulted in pseudonodes there would be 50% more LSPs). It's slightly 
more difficult to add it into the layer 3 IS-IS at
this point because there has to be a method of signalling ability to do 
this. But if we put it into the base TRILL spec now,
then all RBridges would support this.

I'd suggest doing it like this:

In the Hello, say that having the DRB specify the pseudonode ID as 7 
bytes of 0 means "just report all your adjacencies
on this cloud as pt-to-pt links". So it's completely up to the DRB (no 
potential mismatch of configurations) as to
whether the cloud should be reported as pt-to-pt or with a pseudonode.

When the DRB decides to use a zero for pseudonode does not need to be 
standardized, though we could give hints.
It could be configured ("if you are DRB, always use a pseudonode", or 
"never use a pseudonode").
Or it could use an algorithm such as "if  you have only 1 RBridge 
adjacency, don't use a pseudonode, but otherwise
use a pseudonode". or "if you have 2 or more RBridge adjacencies, or had 
2 or more adjacencies within the last hour, use
a pseudonode, otherwise don't".

And also mention that this does not change any behavior such as how LSPs 
are flooded on the link. This only affects what
LSPs are generated. And perhaps give an example. If R1 and R2 are the 
only RBridges on the link, then with
a pseudonode there are 3 LSPs: say R1.25 (the pseudonode), R1, and R2, 
where R1.25 reports connectivity to R1 and R2,
and R1 and R2 each just say they are connected to R1.25.
Whereas if DRB R1 declares no pseudonode, then there will be 2 LSPs: R1 
and R2 each reporting connectivity to each other.

Radia



From Radia.Perlman at sun.com  Wed Jul  9 10:56:45 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 09 Jul 2008 10:56:45 -0700
Subject: [rbridge] Access-only link
Message-ID: <4874FBDD.3090806@sun.com>

I forget who mentioned to me at the last IETF the desire to have an 
"access only" port. At the time I found it
scary.

However, after thinking about it, I've convinced myself it's not scary, 
and relatively simple to provide.

We've already added in "trunk only" links, on which data is not 
encapsulated/decapsulated if there happened to
be endnodes present despite configuration to specify the link as "trunk 
only". That feature seemed simple to
provide and useful to me.

I'm a little less clear on why access-only links are as important, since 
it doesn't seem as though the traffic of
LSP propagation would be that much. But again, I think it's simple and 
safe, so if people think it's useful, I wouldn't
oppose it.

The idea is for the DRB to signal in its Hello "this is access-only". 
And in the LSP for the pseudonode, the DRB
can set the "database overflow" flag, which is a flag already in IS-IS 
for the purpose of dealing with a router that
can't hold the LSP database. That flag means "don't go through this node 
unless absolutely no other path exists".
If the "overflow" flag is set in the pseudonode's LSP, that would mean 
that that pseudonode would not be computed
in a path as a transit link.

Radia

From james.d.carlson at Sun.COM  Wed Jul  9 11:29:35 2008
From: james.d.carlson at Sun.COM (James Carlson)
Date: Wed, 9 Jul 2008 14:29:35 -0400
Subject: [rbridge] Optional pseudonode
In-Reply-To: <4874FA3B.4050108@sun.com>
References: <4874FA3B.4050108@sun.com>
Message-ID: <18549.911.507870.181742@gargle.gargle.HOWL>

Radia Perlman writes:
> The notion of automatic pseudonode minimization was apparently discussed 
> at the last IETF in either rtgwg or IS-IS. I wasn't
> there, but heard there was not much interest, because there is already a 
> solution to that (configuration).

Not just that there was a solution, but what I heard was that it
"didn't matter."  In other words, if you configure everything as
multiple-access and needing a pseudo-node, who cares?  You get a small
increase in the number of LSPs, modern CPUs are fast, added complexity
(of any kind) is a bad thing, and so on.

> The reason it was brought up outside of TRILL was because some people 
> thought it was a good enough idea to
> deploy in IS-IS in general, an perhaps even OSPF.
> 
> In a lot of TRILL deployments all the links will be pt-to-pt (bridges 
> and shared media would have gone away), so it does

Exactly; that's why it's so much more interesting for us than for the
general case, and probably why it won't necessarily get traction
elsewhere.

> When the DRB decides to use a zero for pseudonode does not need to be 
> standardized, though we could give hints.
> It could be configured ("if you are DRB, always use a pseudonode", or 
> "never use a pseudonode").
> Or it could use an algorithm such as "if  you have only 1 RBridge 
> adjacency, don't use a pseudonode, but otherwise
> use a pseudonode". or "if you have 2 or more RBridge adjacencies, or had 
> 2 or more adjacencies within the last hour, use
> a pseudonode, otherwise don't".

I'd be in favor of the second suggested implementation -- it's simple
enough -- but obviously if one node makes the decision, it's no longer
a compatibility issue.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From james.d.carlson at Sun.COM  Wed Jul  9 12:08:05 2008
From: james.d.carlson at Sun.COM (James Carlson)
Date: Wed, 9 Jul 2008 15:08:05 -0400
Subject: [rbridge] Access-only link
In-Reply-To: <4874FBDD.3090806@sun.com>
References: <4874FBDD.3090806@sun.com>
Message-ID: <18549.3221.399586.28461@gargle.gargle.HOWL>

Radia Perlman writes:
> I'm a little less clear on why access-only links are as important, since 
> it doesn't seem as though the traffic of
> LSP propagation would be that much. But again, I think it's simple and 
> safe, so if people think it's useful, I wouldn't
> oppose it.

The case I remember discussing (Silvano, maybe?) was with a wiring
closet.  There's a set of "backbone" links interconnecting the
RBridges, but there are a pair of RBridges that are incidentally
connected through a local access-side wiring closet.  The owner of the
wiring closet doesn't want any backbone traffic traversing it, no
matter how attractive it might look as a path.

> The idea is for the DRB to signal in its Hello "this is access-only". 
> And in the LSP for the pseudonode, the DRB
> can set the "database overflow" flag, which is a flag already in IS-IS 
> for the purpose of dealing with a router that
> can't hold the LSP database. That flag means "don't go through this node 
> unless absolutely no other path exists".
> If the "overflow" flag is set in the pseudonode's LSP, that would mean 
> that that pseudonode would not be computed
> in a path as a transit link.

I think the desire was for "no way, no how."  Not "go ahead and use
this to patch together the rest of the network if necessary."

Perhaps that's too strict a requirement, but that's what I *thought* I
understood from the lunch table discussion.  Perhaps the others
involved could pipe up and clarify whether overflow would be
sufficient.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From mrthom at essex.ac.uk  Wed Jul  9 12:54:05 2008
From: mrthom at essex.ac.uk (Thomas, Matthew R)
Date: Wed, 9 Jul 2008 20:54:05 +0100
Subject: [rbridge] Optional pseudonode
References: <4874FA3B.4050108@sun.com>
Message-ID: <7AC902A40BEDD411A3A800D0B7847B661D3B3BF6@sernt14.essex.ac.uk>

Hi Radia,
 
I have kept quiet on this one lately, however during the ISIS meeting I did reference my maths that was submitted for publication. Academia takes an age to publish. This was accepted for publication and for completeness can be found here :o)
 
http://dces.essex.ac.uk/staff/hunter/Thomas%20CommsLett%202008.pdf
 
Regards,
 
MT

________________________________

From: rbridge-bounces at postel.org on behalf of Radia Perlman
Sent: Wed 09/07/2008 18:49
To: rbridge at postel.org >> "Developing a hybrid router/bridge."
Subject: [rbridge] Optional pseudonode



The notion of automatic pseudonode minimization was apparently discussed
at the last IETF in either rtgwg or IS-IS. I wasn't
there, but heard there was not much interest, because there is already a
solution to that (configuration).

The reason it was brought up outside of TRILL was because some people
thought it was a good enough idea to
deploy in IS-IS in general, an perhaps even OSPF.

However, I think that even if IS-IS and OSPF are not interested in
retrofiting this feature, I think it is a good idea
to do it in TRILL. It is quite simple, safe, and does not require
retrofit, and is actually more useful of a feature in
TRILL than in layer 3 deployments of IS-IS.

In a lot of TRILL deployments all the links will be pt-to-pt (bridges
and shared media would have gone away), so it does
seem like a good idea to have a safe zero-configuration method of
eliminating pseudonodes in that case (if all RBridge adjacencies
resulted in pseudonodes there would be 50% more LSPs). It's slightly
more difficult to add it into the layer 3 IS-IS at
this point because there has to be a method of signalling ability to do
this. But if we put it into the base TRILL spec now,
then all RBridges would support this.

I'd suggest doing it like this:

In the Hello, say that having the DRB specify the pseudonode ID as 7
bytes of 0 means "just report all your adjacencies
on this cloud as pt-to-pt links". So it's completely up to the DRB (no
potential mismatch of configurations) as to
whether the cloud should be reported as pt-to-pt or with a pseudonode.

When the DRB decides to use a zero for pseudonode does not need to be
standardized, though we could give hints.
It could be configured ("if you are DRB, always use a pseudonode", or
"never use a pseudonode").
Or it could use an algorithm such as "if  you have only 1 RBridge
adjacency, don't use a pseudonode, but otherwise
use a pseudonode". or "if you have 2 or more RBridge adjacencies, or had
2 or more adjacencies within the last hour, use
a pseudonode, otherwise don't".

And also mention that this does not change any behavior such as how LSPs
are flooded on the link. This only affects what
LSPs are generated. And perhaps give an example. If R1 and R2 are the
only RBridges on the link, then with
a pseudonode there are 3 LSPs: say R1.25 (the pseudonode), R1, and R2,
where R1.25 reports connectivity to R1 and R2,
and R1 and R2 each just say they are connected to R1.25.
Whereas if DRB R1 declares no pseudonode, then there will be 2 LSPs: R1
and R2 each reporting connectivity to each other.

Radia


_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge




From Caitlin.Bestler at neterion.com  Wed Jul  9 13:10:05 2008
From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Wed, 9 Jul 2008 16:10:05 -0400
Subject: [rbridge] Access-only link
In-Reply-To: <4874FBDD.3090806@sun.com>
References: <4874FBDD.3090806@sun.com>
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC33B5@nekter>

I'm not sure if this is the case you are recalling, but Bridges that
are part of a blade chassis, a multi-function NIC, or a hypervisor
soft-bridge all have links (actual or virtual) that are inherently
internal and lead only to known end stations. Doing "discovery" on
those links is overkill.

It is already common to optimize spanning tree based on this knowledge.
Similar optimizations would certainly be done should any of those
bridges take on RBridge functionality. Whether this needs to be
in the standard or not is a separate question. It could easily
fall under the rule that an implementation can do whatever it
wants if it doesn't impact anybody else.


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Wednesday, July 09, 2008 10:57 AM
> To: rbridge at postel.org >> "Developing a hybrid router/bridge."
> Subject: [rbridge] Access-only link
> 
> I forget who mentioned to me at the last IETF the desire to have an
> "access only" port. At the time I found it
> scary.
> 
> However, after thinking about it, I've convinced myself it's not
scary,
> and relatively simple to provide.
> 
> We've already added in "trunk only" links, on which data is not
> encapsulated/decapsulated if there happened to
> be endnodes present despite configuration to specify the link as
"trunk
> only". That feature seemed simple to
> provide and useful to me.
> 
> I'm a little less clear on why access-only links are as important,
> since
> it doesn't seem as though the traffic of
> LSP propagation would be that much. But again, I think it's simple and
> safe, so if people think it's useful, I wouldn't
> oppose it.
> 
> The idea is for the DRB to signal in its Hello "this is access-only".
> And in the LSP for the pseudonode, the DRB
> can set the "database overflow" flag, which is a flag already in IS-IS
> for the purpose of dealing with a router that
> can't hold the LSP database. That flag means "don't go through this
> node
> unless absolutely no other path exists".
> If the "overflow" flag is set in the pseudonode's LSP, that would mean
> that that pseudonode would not be computed
> in a path as a transit link.
> 
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From ddutt at cisco.com  Sun Jul 13 21:59:12 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Sun, 13 Jul 2008 21:59:12 -0700
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
References: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
Message-ID: <487ADD20.4090604@cisco.com>

Here are my initial set of comments, some editorial and some not. I'll 
try and send more tomorrow.

    * Abstract: I disagree with the choice of the word "custom routing
      protocols". Spanning tree is as much a custom protocol as IS-IS or
      OSPF or BGP. I'd be OK with something along the lines of "Current
      Ethernet link layers use variants of the spanning tree protocol
      that have ...."
    * Abstract: I also don't think people use the word "routing
      protocols" when referring to Ethernet control protocols. "Bridging
      protocols" maybe appropriate.
    * Section 2: It was not 802.1Q that originally allowed multiple
      spanning tree protocol (MSTP), but 802.1s, and was merged into
      802.1Q only in 2003.
    * Section 2: What does it mean to say "STP is affected even by small
      changes". So does any routing protocol. The fact that it is a tree
      makes for some interesting failure scenarios. But the statement as
      it is worded is vague and potentially inaccurate.
    * Section 2.2: I disagree with the statement "Multipathing would
      typically result in only a small improvement in capacity for a
      network with roughly equal traffic between all pairs of nodes."
      Compared to STP, the effect is dramatic. This is THE main
      motivator for TRILL in the industry. Please reword the paragraph.
    * Section 2.3, last paragraph: I don't believe it is STP that
      specifies that the bridge ports are forwarding by default. It is a
      property of the p-n-p nature of the bridge. We've shipped products
      that have the ports blocked by default.
    * Section 3.1, first para: I'd make it a mandatory requirement to
      retain the native properties of Ethernet, unicast, multicast and
      broadcast, not merely a "useful to have".
    * Section 3.4, first para: There is an erroneous text "Error !
      Reference not found"

Dinesh
Donald Eastlake wrote:
> Hi,
>
> This message initiates a two week TRILL Working Group Last Call on the 
> draft below.
>
> Thanks,
> Donald and Erik
>
> 2008/6/27 <Internet-Drafts at ietf.org <mailto:Internet-Drafts at ietf.org>>:
>
>     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
> d3e3e3 at gmail.com <mailto:d3e3e3 at gmail.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From sgai at nuovasystems.com  Mon Jul 14 15:24:34 2008
From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 14 Jul 2008 15:24:34 -0700
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
References: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2051339C8@nuova-ex1.hq.nuovaimpresa.com>

My general comment is that this draft does a lot of unneeded
bad-mouthing of Spanning tree and indirectly of IEEE. There are a lot of
brilliant folks at IEEE that have devoted many years of their life to
improve spanning tree and to make it the only current deployed protocol
at layer 2. If spanning tree was as bad as described in this draft it
will not be currently deployed.

 

Let's make the point for TRILL, but be fair: to prove that TRILL is a
good idea it is enough to mention that TRILL is capable of using all the
links In a network while spanning tree is not.

 

I ask the authors to remove all the statement detrimental to Spanning
Tree and limit the discussion to the advantages of the TRILL approach.

 

Since we are in 2008, I suggest the authors to remove all the mentions
of Thickcable, Thincable and hubs: these things no longer exist.

 

My detailed comments:

 

ABSTRACT

Please rewrite from scratch.

Please remove reference to "custom routing protocols". Not clear what
they are.

There is no route propagation at layer 2.

Routing is a layer 3 term, IEEE 802.1 never speaks about routing.

Not clear what "convergence of these routing protocols and stability
under link 
   changes and failures is also of concern" means
 
INTRODUCTION
"convergence of the spanning tree protocol can be slow." This has been
addressed by RSTP.
 
2.0 THE TRILL PROBLEM
Remove citation to Thicknet and Thinet: no longer relevant.
Not clear what it means: "The spanning tree configuration is 
   affected by even small topology changes, and small changes can have 
   large effects. Each of these inefficiencies can cause problems for 
   current link layer deployments. "
 
2.1. Inefficient Paths
 
Remove reference to "hub": no longer relevants and not relevants for
this discussion.
 
2.3 Convergence and safety
This is absolutely not correct: "if RSTP is in use, 
   produce persistent loops lasting for tens of seconds due to BPDU 
   traffic throttling [5]."
 
Spanning tree is not unsafe: "All variants of spanning tree are
inherently unsafe"
 
2.5. Other Ethernet Extensions 
802.1 is not an "Ethernet Extension"
802.1w, 802.1s, 802.1v no longer exist: they have been incorporated in
802.1Q.
 
3.3. Forwarding Loop Mitigation 
There are no transient loops in Spanning Tree
 
3.4. Spanning Tree Management 
Sections 2.2 and Error! Reference source not 
   found.)
 
4 Applicability
It seems original that being almost done with TRILL, we still have a
sentence that says: "A currently open question is ..."
 
-- Silvano
 
 
 
 
 
 
 

 

 

 

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Donald Eastlake
Sent: Tuesday, July 01, 2008 8:07 PM
To: rbridge at postel.org
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt

 

Hi,

 

This message initiates a two week TRILL Working Group Last Call on the
draft below.

 

Thanks,

Donald and Erik

2008/6/27 <Internet-Drafts at ietf.org>:

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
d3e3e3 at gmail.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080714/497ac5c6/attachment.html

From Internet-Drafts at ietf.org  Tue Jul 15 09:30:01 2008
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Tue, 15 Jul 2008 09:30:01 -0700 (PDT)
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-08.txt
Message-ID: <20080715163001.EABF13A6AFD@core3.amsl.com>



From sdalberg at marchex.com  Tue Jul 15 10:58:45 2008
From: sdalberg at marchex.com (Steve Dalberg)
Date: Tue, 15 Jul 2008 10:58:45 -0700
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2051339C8@nuova-ex1.hq.nuovaimpresa.com>
References: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
	<34BDD2A93E5FD84594BB230DD6C18EA2051339C8@nuova-ex1.hq.nuovaimpresa.com>
Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50DE79DA7@exchbe1sea.windows.marchex.com>



> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On Behalf Of Silvano
> Gai
> Sent: Monday, July 14, 2008 3:25 PM
> To: Donald Eastlake; rbridge at postel.org
> Subject: Re: [rbridge] WG LC draft-ietf-trill-prob-04.txt
> 
> My general comment is that this draft does a lot of unneeded
bad-mouthing of Spanning tree
> and indirectly of IEEE. There are a lot of brilliant folks at IEEE
that have devoted many
> years of their life to improve spanning tree and to make it the only
current deployed protocol
> at layer 2. If spanning tree was as bad as described in this draft it
will not be currently
> deployed.
> 

Concerning "the only current deployed protocol at Layer 2"

This is untrue, as many vendors have proprietary solutions that don't
involve spanning tree.  HP ProCurve has Meshing, and I believe Extreme
also uses some propriety stuff as well.  Cisco has Their some variances
of Spanning tree, and some true alternatives with some of their stacking
features (I'll admit this is very limited, but it isn't spanning tree
either).  Trill is trying to address a problem vendors have been working
on proprietary solutions on for a while.  While I agree that disparaging
IEEE isn't productive, there is merit in pointing out that Spanning Tree
is deficient in many ways and forces people down paths that can be
costly since a tree topology causes lots of aggregation.  Many people
could forestall an upgrade to 10Gig with a Trill solution in a mesh
topology.

Steve


From ftallet at cisco.com  Fri Jul 18 17:38:18 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Fri, 18 Jul 2008 17:38:18 -0700
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <9B4191CF8F73B04BB4F437E1F7F86ED50DE79DA7@exchbe1sea.windows.marchex.com>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E0125BFE5@xmb-sjc-229.amer.cisco.com>

Steve,
Actually, your email is exactly in the lines of what I think should be
corrected in the document.

| Concerning "the only current deployed protocol at Layer 2"
| 
| This is untrue, as many vendors have proprietary solutions 
| that don't involve spanning tree.  HP ProCurve has Meshing, 
| and I believe Extreme also uses some propriety stuff as well. 
|  Cisco has Their some variances of Spanning tree, and some 
| true alternatives with some of their stacking features (I'll 
| admit this is very limited, but it isn't spanning tree 
| either).  

I don't know exactly what alternate protocols you are referring to, but
I would not be surprised if they computed a spanning tree for the data
plane, unless they changed the way frames are bridged (which is not
simply a control plane change then). Even if the control protocol is not
the Spanning Tree Protocol, your data plane requires a spanning tree
because of the way frames are switched. That's what is preventing
multipathing.
That's this confusion that makes the following incorrect if you are
talking of the Spanning Tree Protocol:

|Spanning Tree is deficient in many 
| ways and forces people down paths that can be costly since a 
| tree topology causes lots of aggregation.  Many people could 
| forestall an upgrade to 10Gig with a Trill solution in a mesh 
| topology.

TRILL does much more than replacing the control protocol of current
bridges. And STP is not the reason why we don't have multipathing now in
802.1Q (actually, the first draft of 802.1aq, the 802.1 TRILL
equivalent, is based on MST).

Exaggerating the "deficiencies" of STP will just turn the bridging
community against the project. After seeing the document for the first I
read: "It's time we bring modern age routing technology to this bridging
world, that is still relying on deficient custom routing protocol". Then
insisting on the long convergence time of STP (btw, RSTP is out for
almost a decade and today 802.1D *is* RSTP) and mentioning that
transient loops are part of the normal protocol operation does not add
much credibility to the argument;-)

But most of all, I don't think it is necessary to bash STP to make the
move to TRILL or 802.1aq worthwhile for most users. There is a real
expectation for something new in the area. 

Regards,
Francois

| 
| Steve
| 
| _______________________________________________
| rbridge mailing list
| rbridge at postel.org
| http://mailman.postel.org/mailman/listinfo/rbridge
| 


From d3e3e3 at gmail.com  Sat Jul 26 20:28:26 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sat, 26 Jul 2008 23:28:26 -0400
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <9D2A87BDA62A8041AFE4E3D20FC1786E0119ADEB@xmb-sjc-229.amer.cisco.com>
References: <1028365c0807071605j2156024w679a24c6f688964e@mail.gmail.com>
	<9D2A87BDA62A8041AFE4E3D20FC1786E0119ADEB@xmb-sjc-229.amer.cisco.com>
Message-ID: <1028365c0807262028r7e6b221fm4b5fb4a2590f7f4a@mail.gmail.com>

Hi Francois,
See inline

On Mon, Jul 7, 2008 at 9:04 PM, Francois Tallet (ftallet) <ftallet at cisco.com>
wrote:

>  Hi Donald,
> Please see inline.
>
>  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...

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.

>  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.
> [FT>] Currently, a port goes to forwarding in 2xforward_delay, and
> forward_delay is 15 seconds by default.
>
> Then the number in the draft should probably be changed to 30 seconds.

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

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

>  Regards,
> Francois
>
>
>> 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
>> ...
>
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd +1-508-634-2066 (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
>
> 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/20080726/92932832/attachment.html

From d3e3e3 at gmail.com  Sun Jul 27 10:28:27 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 27 Jul 2008 13:28:27 -0400
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <487ADD20.4090604@cisco.com>
References: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
	<487ADD20.4090604@cisco.com>
Message-ID: <1028365c0807271028p44110c0ft47e6f92a132be2f4@mail.gmail.com>

A comment on one of your points:

On Mon, Jul 14, 2008 at 12:59 AM, Dinesh G Dutt <ddutt at cisco.com> wrote:

> Here are my initial set of comments, some editorial and some not. I'll try
> and send more tomorrow.
>
> ...


>   * Section 2.2: I disagree with the statement "Multipathing would
>     typically result in only a small improvement in capacity for a
>     network with roughly equal traffic between all pairs of nodes."
>     Compared to STP, the effect is dramatic. This is THE main
>     motivator for TRILL in the industry. Please reword the paragraph.


I would agree. The text was intended to be about the improvement
multi-pathing makes when your are already using least cost paths. Basically,
multi-pathing spreads traffic over more physical links. If most of your
traffic was on one least cost path because it was between two points in a
mesh, multi-pathing would make a lot of difference. On the other hand, if
you traffic is already very diverse, using least cost paths between many
points, it seems reasonable that multi-pathing causes less improvement.

...
>
> Dinesh


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/20080727/9c876d06/attachment-0001.html

From ftallet at cisco.com  Mon Jul 28 14:27:17 2008
From: ftallet at cisco.com (Francois Tallet (ftallet))
Date: Mon, 28 Jul 2008 14:27:17 -0700
Subject: [rbridge] Few comments on the latest daft (RE: rbridge Digest,
	Vol 50, Issue 1)
In-Reply-To: <1028365c0807262028r7e6b221fm4b5fb4a2590f7f4a@mail.gmail.com>
Message-ID: <9D2A87BDA62A8041AFE4E3D20FC1786E0130A245@xmb-sjc-229.amer.cisco.com>

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

			 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080728/0945566a/attachment.html

From d3e3e3 at gmail.com  Mon Jul 28 14:46:42 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 28 Jul 2008 17:46:42 -0400
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt
In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2051339C8@nuova-ex1.hq.nuovaimpresa.com>
References: <1028365c0807012006j4c6e130el38ba48b6713bd48b@mail.gmail.com>
	<34BDD2A93E5FD84594BB230DD6C18EA2051339C8@nuova-ex1.hq.nuovaimpresa.com>
Message-ID: <1028365c0807281446y3581fae8w1c66ce528aed8704@mail.gmail.com>

A response to a couple of your comments

On Mon, Jul 14, 2008 at 6:24 PM, Silvano Gai <sgai at nuovasystems.com> wrote:

>  ...
>
> Since we are in 2008, I suggest the authors to remove all the mentions of
> Thickcable, Thincable and hubs: these things no longer exist.
>
I own hubs and occasionally use them.

>  ABSTRACT
>
> Please rewrite from scratch.
>
The abstract should correspond with the body. After such changes as are
warrented are made in the body of the draft, the Abstract should be adjusted
to correspond.

> ...
>
> -- Silvano
>
> 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/20080728/5705f0dd/attachment-0001.html