Subject: [rbridge] Comments on draft-ietf-trill-prob-00.txt

From: riw at cisco.com (Russ White)
Date: Thu, 22 Jun 2006 11:52:32 -0400

Just some comments below that might help...

:-)

Russ

==

   The spanning tree is dependent on the way a set of bridges are
   interconnected, i.e., the link layer topology. Small changes in this
   topology can cause large changes in the spanning tree. Changes in the
   spanning tree can take time to propagate and converge.

   [QUESTION: is there a good visual example of this, one that we can
   walk through in the description?]

I think the absolute worst case is when one of the branches connected
to the root bridge fails, causing a large number of ports to
block and unblock before the network would reconverge. Perhaps a ring
would show enough to explain, however (?):

A----B----C----D----E
|                                        |
+-----F-----G-------+

If A is the root bridge, then we can assume the paths A->B->C->D and
A->F->G->E are the two open paths, while the D->E link is blocked in
both directions (just using hop count). If the A->B link fails, then E
must unblock its port to D for traffic to flow again, but it may
require recomputation of the entire tree through BPDUs, I think (?).

==

   [QUESTION: is port autolearning in this category too? i.e., are TRILL
   solutions trying to hide bridge reattachment from other nodes (or is
   that even necessary?)]

I don't think we are trying to address this in TRILL (?).

==

   The spanning tree protocol is inherently global to an entire layer 2
   subnet; there is no current way to contain, partition, or otherwise
   factor the protocol into a number of smaller, more stable subsets
   that interact as groups. Contrast this with Internet routing, which
   includes both intradomain and interdomain variants, split to provide
   exactly that containment and scalability within a domain while
   allowing domains to interact freely independent of what happens
   within a domain.

   [QUESTION: anybody have a convenient reference for a proof? Are new
   spanning tree protocols not considering AS-like boundaries? (just
   checking)]

I'm not certain you need any reference on this, I would guess it's
pretty self evident (?).

==

3.5. Multiple Attachments

   [QUESTION: I'm not sure what this refers to; is it the same NIC
   attached at different points to a TRIL solution? If so, why should
   this be possible where it seems ignored in bridges?]

I'm not certain what this section would cover, as well. It might
mention that while, in STP, a single NIC with multiple attachments to
a single spanning tree will always only get traffic over one of the
two attachment points (I don't see how it would work otherwise??),
with TRILL, it's actually possibly to load share between the
attachment points. I don't know if this is worth calling out, or
worrying about, though, in this specific document, since this is a
problem statement, and this has never been noted as a problem in STP.

==

---

From: dahmna at gmail.com (Masanori Takashima)
Date: Wed, 28 Jun 2006 15:44:31 -0400

Hi,

I think, in addition, that those two papers are helpful to understand
RSTP causing large changes. Especially, the latter one shows us how
bad it is when root bridge in outside ring disappers. Russ expains
that root bridge is inside ring, but the paper explains root bridge in
outside ring.

- A. Myers, T. E. Ng, and H. Zhang. Rethinking the Service Model:
Scaling Ethernet to a Million Nodes. In Third Workshop on Hot Topics
in networks (HotNets-III), Mar. 2004.
- K. Elmeleegy, A.L. Cox and T. E. Ng, On Count-to-Infinity Induced
Forwarding Loops in Ethernet Networks. In Infocom '06, April. 2006.

Masanori
-------------------------------------------

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 28 Jun 2006 22:19:44 +0200

I do agree. It seems that, as shown in the second paper, (I cite 
aproximately "...when the network gets partitioned and the part that 
does not
contain the previous root bridge has a cycle, a count to infinity may 
occur"). 
Regards
Guillermo

Masanori Takashima wrote:

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