[rbridge] WG LC draft-ietf-trill-prob-04.txt

[Silvano Gai]

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