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

[Gray, Eric]

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