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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 1 Nov 2006 11:19:20 -0500

Silvano,

	The first problem you're identifying is unavoidable if we intend to 
use an SPF routing protocol and we need to support multicast, broadcast 
and flooding.

	In your second problem, I believe you're reading something into the 
expression "load-splitting across multiple paths" that is not intended to 
be there.

	The intention is that we will use multiple paths because we are not
disabling links via STP.  If we use an SPF routing algorithm, instead of
STP, we will be splitting the traffic load over multiple paths.  Any more
complex form of load splitting implies sharing a lot of information about
- for example - link utilization, traffic patterns and trends, shortest 
path constraints, etc.

	The notion of using a L2 version of ECMP is - IMO - in no way
implied
by the text in the charter.  Nor is there any explicit intention to preclude
this type of activity - with the caveat that anyone doing so has to assume
responsibility for not "breaking" the interoperability model.

	Radia's discussion of how FTAG-like functionality might be done
using
the egress RBridge identifier is an example of one approach that might be
used by an ingress RBridge to split the load across multiple paths.  It is
also a good example of why this is very complicated - precisely because it
requires extending the process of setting up IRTs to include some form of
"token" used to distinguish intended paths.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Wednesday, November 01, 2006 1:06 AM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Comments on: 
--> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge
--> -arch-01.txt
--> 
--> 
--> 
--> 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 ...
-->

---

From: riw at cisco.com (Russ White)
Date: Wed, 01 Nov 2006 11:26:30 -0500

> responsibility for not "breaking" the interoperability model.

And this is as it should be, IMHO. If you know, for certain, that your
entire network is made up of rbridges, rather than a mixture of various
types of bridging devices, then you could use L2 ECMP. If you don't,
then you (probably) can't.

I think this decision is in the hands of network operators and
implementors, though, not in the hands of the spec writers. If we say:
"X is dangerous in specific situation Y, therefore we will never allow
X," then we are shutting down possible avenues for growth--such as the
stuff we're talking about with F-Tags.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone