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

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 01 Nov 2006 10:43:11 -0800

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