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

From: ayabaner at cisco.com (Ayan Banerjee (ayabaner))
Date: Wed, 1 Nov 2006 11:21:38 -0800

Radia,

In this case could we assume that this list of trees to be computed will
be ordered and consistent across all nodes (say on MAC address or
priority)? 

Given the above, is it possible to have another TLV that states how many
trees (or the roots of trees) a node is "willing" to compute based on
its resource constraints. This will eliminate interoperability issues
across next-generation rbridges which may be more capable and deployed
with older rbridges. 

Thanks,
Ayan 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Wednesday, November 01, 2006 10:43 AM
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