[rbridge] Compromise proposal---allowing tradeoff between computation and optimality of delivery
riw at cisco.com
Thu Nov 2 05:17:24 PST 2006
-----BEGIN PGP SIGNED MESSAGE-----
I support this as well.... We need to sort the signaling out, somehow.
Silvano Gai wrote:
> This is a great proposal,
> I fully support it
> -- Silvano
>> -----Original Message-----
>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>> 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
>> I'm arbitrarily picking the zero configuration option being a single
>> 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
>> So now we have a subset of RBridges that can be used as roots of
>> 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
>> based on IP multicast announcements and VLANs) rooted at the RBridge
>> smallest MAC address. But by configuration, more and more optimality
>> can be introduced by having RBridges compute more trees.
>> rbridge mailing list
>> rbridge at postel.org
> rbridge mailing list
> rbridge at postel.org
riw at cisco.com CCIE <>< Grace Alone
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge