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

Wed Jul 2 16:00:25 PDT 2008

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