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

[Russ White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I support this as well.... We need to sort the signaling out, somehow.

:-)

Russ

Silvano Gai wrote:
> Radia,
> 
> This is a great proposal,
> I fully support it
> 
> -- Silvano
> 
>> -----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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

- --
riw at cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSe/jER27sUhU9OQRAijWAJ4x7YMh30geODak9oMu9hFCwUR0mQCgl9O3
ah/WKrnrVzEoShD2xihrUtE=
=vBsK
-----END PGP SIGNATURE-----