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

From: "Donald Eastlake" <[email-masked]>
Date: Tue, 1 Jul 2008 23:06:46 -0400

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

Thanks,
Donald and Erik

2008/6/27 <[email-masked]>:

> 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
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 13 Jul 2008 21:59:12 -0700

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 <[email-masked] <mailto:[email-masked]>>:
>
>     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
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

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

---

From: "Silvano Gai" <[email-masked]>
Date: Mon, 14 Jul 2008 15:24:34 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Donald Eastlake
Sent: Tuesday, July 01, 2008 8:07 PM
To: [email-masked]
Subject: [rbridge] WG LC draft-ietf-trill-prob-04.txt

Hi,

Thanks,

Donald and Erik

---

From: "Steve Dalberg" <[email-masked]>
Date: Tue, 15 Jul 2008 10:58:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On Behalf Of Silvano
> Gai
> Sent: Monday, July 14, 2008 3:25 PM
> To: Donald Eastlake; [email-masked]
> Subject: Re: [rbridge] WG LC draft-ietf-trill-prob-04.txt
> 
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: "Francois Tallet (ftallet)" <[email-masked]>
Date: Fri, 18 Jul 2008 17:38:18 -0700

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
| [email-masked]
| http://mailman.postel.org/mailman/listinfo/rbridge
|

---

From: "Donald Eastlake" <[email-masked]>
Date: Sun, 27 Jul 2008 13:28:27 -0400

A comment on one of your points:

On Mon, Jul 14, 2008 at 12:59 AM, Dinesh G Dutt <[email-masked]> wrote:

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

>     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
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Donald Eastlake" <[email-masked]>
Date: Mon, 28 Jul 2008 17:46:42 -0400

A response to a couple of your comments

On Mon, Jul 14, 2008 at 6:24 PM, Silvano Gai <[email-masked]> 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.

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

Donald