Subject: [rbridge] Compromise proposal---allowing tradeoff between com putation and optimality of delivery

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 1 Nov 2006 14:51:34 -0500

Radia,

	There are three problems with this proposal: 1) the general
problem associated with having options, 2) the fact that it is not 
consistent with the idea of trying to utilize links more fully if 
the approach may require traffic to traverse the same links more
than one time, and 3) there is nothing about a low MAC address that
has anything to do with the suitability of a particular RBridge to
act as the root for a shared tree. 

	I think there are other ways to allow for an optional server
for broadcast/multicast/flooding distribution than to complicate
the TRILL protocol with optional implementation alternatives like
this proposal seems to suggest.  Part of the complication - at a
minimum - is the need to provide for a neogitation mechanism with
one or more tunable parameters for determing a primary, and one or 
more secondary, roots for the shared tree.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Wednesday, November 01, 2006 1:43 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] Compromise proposal---allowing tradeoff 
--> between computation and optimality of delivery
--> 
--> There is understandable nervousness about the need to compute
--> per-ingress trees for every RBridge, and optimality of delivery.
--> I actually was dubious about whether people *really* wanted
--> to have to compute per-ingress trees.
--> 
--> Here's a proposal that will allow tradeoff between overhead of
--> computation and optimality of delivery. If people really want
--> they can have RBridges compute trees rooted at every 
--> RBridge. Or they
--> can have all multicast delivered on a single shared tree. 
--> Or anything in 
--> between.
--> I'm arbitrarily picking the zero configuration option being 
--> a single tree.
--> 
--> The new shim format allows the ingress RBridge to specify the
--> distribution tree for multicast, by putting into the 
--> "egress RBridge"
--> field a tree rooted at at the specified RBridge.
--> 
--> In this proposal, by default, the only tree that will be 
--> computed is a 
--> single shared
--> tree rooted at the RBridge with smallest MAC address. Let's say that
--> RBridge has nickname "71". By specifying 71 as egress RBridge in
--> a multicast packet, the delivery path will be via the bidirectional
--> tree rooted at 71.
--> 
--> An RBridge can be configured to demand that it, too, be the root of
--> a tree, and it informs the other RBridges with a flag in 
--> its link state
--> packet.
--> 
--> So now we have a subset of RBridges that can be used as 
--> roots of trees, 
--> because
--> they have specified that in their link state packet.
--> Let's say that RBridges with nicknames 11, 15, 71, 222, and 259 all
--> have announced that they want to be roots of trees.
--> 
--> Then an ingress RBridge, say R2, with nickname 11, can send a
--> multicast/unknown destination packet with "ingress"=11 (its own)
--> and "egress"=11 (because it said it wanted to be a root). 
--> Or it could
--> choose any of the other potential ones (15, 71, 222, 259).
--> 
--> Likewise, an ingress RBridge, say R3, with nickname 13, who has
--> not requested to be the root of a tree, can specify only
--> the trees 11, 15, 71, 222, 259. Note it cannot specify 
--> "13", since we
--> are assuming it has not requested that all RBridges 
--> calculate a tree 
--> rooted at itself.
--> 
--> If no RBridges are configured to say they want to be the root,
--> then only a single tree will get computed---the one rooted
--> at 71.
--> 
--> So the zero configuration option is a single shared tree 
--> (still filtered
--> based on IP multicast announcements and VLANs) rooted at 
--> the RBridge with
--> smallest MAC address. But by configuration, more and more optimality
--> can be introduced by having RBridges compute more trees.
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->