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

Wed Nov 1 12:19:11 PST 2006

1) Yeah, options are better avoided if possible. But they're not too bad as long as there
are reasonable defaults, and no way to screw up by setting things differently at different RBridges.

2) Traffic should not traverse any link more than once no matter which tree is being used. Or am I confused?

3) Right. Choosing which n RBridges get to be roots based on MAC addresses is arbitrary. I just wanted
a simple tie breaker so all the RBridges compute the same trees. For DR election there's a priority
field that is used as the most significant byte of the address. We could do the same thing here. Rather than
a flag saying "I want to be a root", there can be, say, a 1 byte TLV in the link state packet saying "my priority
for being a tree root is x". If the TLV is not there at all then it means "I don't want to be a root at all, unless
there are no other volunteers and I happen to be the lowest MAC address". Otherwise, the n RBridges
with the highest ( root priority | MAC ) get chosen.

Radia

----- Original Message -----
From: "Gray, Eric" <Eric.Gray at marconi.com>
Date: Wednesday, November 1, 2006 11:51 am
Subject: Re: [rbridge] Compromise proposal---allowing tradeoff between	com putation and optimality of delivery

> Radia,
> 
> 	There are three problems with this proposal: 1) the general
> problem associated with having options, 2) the fact that it is not 
> consistent with the idea of trying to utilize links more fully if 
> the approach may require traffic to traverse the same links more
> than one time, and 3) there is nothing about a low MAC address that
> has anything to do with the suitability of a particular RBridge to
> act as the root for a shared tree. 
> 
> 	I think there are other ways to allow for an optional server
> for broadcast/multicast/flooding distribution than to complicate
> the TRILL protocol with optional implementation alternatives like
> this proposal seems to suggest.  Part of the complication - at a
> minimum - is the need to provide for a neogitation mechanism with
> one or more tunable parameters for determing a primary, and one or 
> more secondary, roots for the shared tree.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org 
> --> [rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> --> Sent: Wednesday, November 01, 2006 1:43 PM
> --> 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
> 