Subject: [rbridge] Comments on: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-01.txt

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 31 Oct 2006 22:05:57 -0800

IRTs have two problems.

1) They limit the number of Rbridges in a CRED, since each switch needs
to run a copy of Djikstra for each IRT.

2) they don't support load balancing of traffic across multiple links.
The charter says: "Load-splitting among multiple paths", it does not say
"only for unicast". TRILL needs to provide a set of trees in the CRED
(what I call shared trees) and let each ingress RBridge balance the
traffic on a subset of them.

In a network with 1000 RBridges, 1000 IRTs are computationally difficult
and don't provide load-splitting among multiple paths, 8 shared trees
are easy to compute and provide load-splitting among multiple paths.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Tuesday, October 31, 2006 9:19 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Comments on: http://www.ietf.org/internet-
> drafts/draft-ietf-trill-rbridge-arch-01.txt
> 
> Silvano,
> 
> 	 See comments below...
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> --> Sent: Monday, October 30, 2006 12:13 PM
> --> To: rbridge at postel.org
> --> Subject: [rbridge] Comments on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
> --> -arch-01.txt
> -->
> -->
> --> Comments inline marked "sgai n>"
> -->
> --> Sgai 1> This documents assumes that all multicast traffic must be
> --> propagated through the IRT (Ingress Rbridge Tree) and therefore
> --> denies any possibility for shared trees.
> 
> 
> I don't follow this comment.  Or perhaps I simply don't understand
> why this is our problem.
> 
> By creating ingress RBridge trees (as the concatenation of shortest
> path routes from an ingress to all egresses), we establish a "tree"
> which will deliver to all destinations in the broadcast domain.  If
> we then "prune" the tree for specific VLANs and multicast interest
> groups, we create "virtual trees" per-VLAN and for multicast groups.
> 
> In doing this, we are perhaps doing better than 802.1<whatever>, but
> we are still only trying to deliver broadcast, flooded and multicast
> frames to the destinations that 1) would receive them in an Ethernet
> network and 2) should receive them if optimizing an Ethernet network
> for IP multicast.
> 
> Frankly the intent to support optimization of IP multicast is a bit
> of a fragile compromise within the working group, but it is AFAIK
> what we are trying to do.
> 
> So, what I am trying to figure out is how what we're doing with the
> IRT differs from "shared tree" support with existing 802.1<whatever>
> bridges.
> 
> Are you saying that you would like RBridges to support the "shared
> tree" concept even though 802.1<whatever> bridges may or may not
> support it?
> 
> Or are you saying that there is something about the design of the
> ingress rbridge trees that get in the way of support for "shared
> trees" that might be provided in today's Ethernet bridges?
> 
> 
> -->
> --> -- Silvano
> -->
> --> --------------------------------------------------------
> -->
> --> ... snip ...