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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 1 Nov 2006 14:16:32 -0800

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

---

From: riw at cisco.com (Russ White)
Date: Thu, 02 Nov 2006 08:17:24 -0500

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

:-)

Russ

>> can be introduced by having RBridges compute more trees.

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