Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 01 Apr 2008 18:43:04 -0700

I agree with you Radia on both points,

Dinesh
Radia Perlman wrote:
> My only 2 comments on your comments:
> a) I don't see how there can be a default of square root of number of 
> RBridges, since RBridges wouldn't know the number
> of bridges. I'd say we should pick a number like "10".
> b) Sorry -- need to "think aloud" here for a bit.
> A few questions about "order": "ports" is known in advance and doesn't 
> change. "adjacencies" is not known in advance .
> But then you really want "RBridge adjacencies" and not just ports to 
> endnodes...so I'm not sure. Maybe
> it has to be "RBridge adjacencies". But does having a fluctuating 
> "order" cause problems? In theory we might want a pseudonode
> to be a tree root, but pseudonodes don't get nicknames, and therefore 
> can't be specified as a tree root in the TRILL header.
>
> And then using numerically largest works for "order" but not for 
> "distance to me", so that has to be adjusted (shouldn't be hard, perhaps
> making "order" be 1000 minus the number of RBridge adjacencies, going no 
> lower than "0"). And "order" can be calculated from
> the LSP -- it doesn't have to be separately announced. Though if you are 
> connected to a pseudonode do you have to remember
> to count all the RBridges connected to that pseudonode?
>
> It might be simpler to just have "order" feed into priority, as in, if 
> your priority is not configured in advance, then if you have more
> than some number (say 2) RBridge adjacencies, you decrement your 
> priority by 1 for every extra RBridge adjacency. If your
> priority is configured, you'd leave it at whatever it is configured to be.
>
> Radia
>
>
>
>
> Eastlake III Donald-LDE008 wrote:
>   
>> Hi,
>>
>> I agree that the present requirement that all Rbridges default to having
>> the RequestTree be TRUE probably results in Rbridges being required to
>> calculate too many trees in a large campus. See comments below at @@@
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Radia Perlman
>> Sent: Friday, March 28, 2008 10:55 PM
>> To: Developing a hybrid router/bridge.
>> Subject: [rbridge] (slight) modification of how to choose mulitcast
>> trees
>>
>> Dinesh suggested the following, as a way of making configuration easier 
>> for how to choose multicast trees.
>>
>> 1) Each RBridge is configured with a priority for being selected a 
>> multicast tree root (with of course a default being a medium priority)
>>
>> 2) Each RBridge R1 is also configured with a parameter indicating "total
>>
>> number of trees in the campus", which R1 announces in its LSP.
>>
>> @@@ So what's the recommended default here? It might sound a bit odd but
>> I would suggest that the default be something like the square root of
>> the number of Rbridges in the campus. (See comment below on volatility.)
>>
>> 3) RBridges are ranked by (priority, ID). The RBridge with the 
>> numerically lowest priority, and then numerically lowest ID being the
>> tie breaker, dictates the total number of trees all the other RBridges 
>> must calculate (the number that R1 announces in its LSP according
>> to rule 2 above.
>>
>> @@@ As long as you are generating a concatenated global priority number
>> like (priority, ID), why not make it a little more clever by having it
>> be (priority, order, ID) or something like that? (Where "order" is the
>> number of adjacencies the Rbridge has, so you'd have to change the
>> ranking to be highest priority is numerically largest...).
>>
>> 4) An RBridge calculates n distribution trees, where n is the number 
>> announced by the lowest (priority, ID) RBridge R1, in R1's LSP,
>> as the "total number of trees". The n trees computed are the ones using 
>> the n numerically lowest (priority, ID) RBridges as roots
>>
>> 5) if RB1 is ingress RBridge on port p, and (*note another parameter 
>> "k"*) is configured to do k-way path splitting on that port for
>> multidestination frames, the k tree roots that RB1 chooses consist of 
>> the three for which the triple "(cost of root to me, priority, ID)" are
>> the k smallest.
>>
>> @@@ Of course the ranking has to be the same so if "order" were added as
>> above, it would have to be added here also.
>>
>> Intuition: suppose there is a topology with a lot of "leaf" RBridges., 
>> and "next level" RBridges that the leaf RBridges connect to.
>> If there are m leaf RBridges connected to next level RBridge RBx, then 
>> there is no reason to compute trees with any of the leaf
>> RBridges as root -- the tree rooted at RBx will be the same tree, and 
>> will indeed be a shortest path tree for each of the attached
>> leaf RBridges. If a leaf RBridge is attached to several next-level 
>> RBridges, the most significant number in the triple -- "cost
>> of root to me" will cause the leaf RBridge to multipath the multicast 
>> among multiple shortest-path trees.
>>
>> @@@ That's all true but the special case of an Rbridge of order 1
>> connected to an Rbridge of order >1 seems so simple to check for that
>> you could just rule them out. Or, if "order" were added to the
>> comparison tuple as above, in the default case where all Rbridges have
>> the default priority, order 1 Rbridges would automatically have lowest
>> priority. (See also slides 8 and 9 of my presentation at 
>> http://www.ietf.org/proceedings/07jul/slides/trill-3/sld1.htm.)
>>
>> This seems completely safe, and easier than configuring, for each 
>> RBridge, the set of root RBridges to choose for multicast tree roots.
>> It also means that you can configure in one place a total number of 
>> roots, rather than possibly having too many RBridges volunteer for
>> being tree roots, and winding up with too much overhead on RBridges 
>> because they'll have to compute a tree for every RBridge that
>> says it will want to be a tree root.
>>
>> There might be a concern about volatility -- when an RBridge with 
>> numerically low priority goes down, it might cause:
>> a) a change to the total number of trees to be computed by everyone 
>> (since the next best might be configured with a different number)
>> b) a change to the list of "tree roots I will choose" announced by RB2 
>> when one of the roots for the k best (cost to me, priority, ID) goes
>> down.
>>
>> @@@ There are plenty of other possible causes for volatility. Like a
>> high priority-to-be-tree-root Rbridge coming up or an Rbridge's
>> priority-to-be-tree-root being reconfigured. But the solution to them
>> all is the same. An Rbridge has to keep calculating (or at least keep
>> around) trees for old roots as long as their reasonably might be frames
>> in transit specifying those roots. It has to calculate trees for any new
>> roots right away and, if appropriate, start advertising that it might
>> use them. What root (or from what set of roots) to choose for new native
>> multi-destination frames an Rbridge is encapsulating is a bit messier.
>> Seems to me that until it is reasonably sure that information has
>> propagated concerning new roots, it should only use those in the
>> intersection of the sets of old and new roots. If that intersection is
>> null, something only likely to occur when there are a very small number
>> of tree roots, you have a bit of a problem and might as well use the new
>> root(s). But this is no worse than under the previous scheme if
>> RequestTree was FALSE for all Rbridges and the Rbridge with the lowest
>> system ID, which had defaulted to being the only tree root, goes down.
>>
>> Other than that, I can't think of any possible problems.
>>
>> @@@ Overall, I like the proposal.
>>
>> Radia
>>
>> @@@ Thanks,
>> @@@ Donald
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>   
>>     
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 01 Apr 2008 18:48:20 -0700

Slight modification. I'd want the default to be smaller, say 2 or 4. But 
I won't quibble,

Dinesh

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 2 Apr 2008 00:11:39 -0400

Hi,

See below at @@@

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008
To: Radia Perlman
Cc: Eastlake III Donald-LDE008; Developing a hybrid router/bridge.
Subject: Re: [rbridge] (slight) modification of how to choose mulitcast
trees

I won't quibble,

Dinesh

Dinesh

> of bridges. I'd say we should pick a number like "10".

@@@ OK, so let's go with a recommended default of 8.

> priority is configured, you'd leave it at whatever it is configured to
be.

@@@ I'm fine with order feeding into priority in some fashion if your
priority is not configured. People who are configuring ought to know
what they are doing and avoid ties.

@@@ Thanks,
@@@ Donald

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 01 Apr 2008 21:32:45 -0700

Why 8 ? I prefer something much less. But again, this isn't something 
I'd debate much about. Priority will be configured as users want 
predictablity and determinism.

Dinesh
Eastlake III Donald-LDE008 wrote:
>> "distance to me", so that has to be adjusted (shouldn't be hard,
>>     
> perhaps
>   
>> making "order" be 1000 minus the number of RBridge adjacencies, going
>>     
> no 
>   
>> the LSP -- it doesn't have to be separately announced. Though if you
>>     
> are 
>   
>> priority is configured, you'd leave it at whatever it is configured to
>>     
> be.
>
>>> I agree that the present requirement that all Rbridges default to
>>>       
> having
>   
>>> the RequestTree be TRUE probably results in Rbridges being required
>>>       
> to
>   
>>> From: [email-masked] [mailto:[email-masked]]
>>>       
> On
>   
>>> Behalf Of Radia Perlman
>>> Dinesh suggested the following, as a way of making configuration
>>>       
> easier 
>   
>>> multicast tree root (with of course a default being a medium
>>>       
> priority)
>   
>>> 2) Each RBridge R1 is also configured with a parameter indicating
>>>       
> "total
>   
>>> @@@ So what's the recommended default here? It might sound a bit odd
>>>       
> but
>   
>>> the number of Rbridges in the campus. (See comment below on
>>>       
> volatility.)
>   
>>> tie breaker, dictates the total number of trees all the other
>>>       
> RBridges 
>   
>>> @@@ As long as you are generating a concatenated global priority
>>>       
> number
>   
>>> like (priority, ID), why not make it a little more clever by having
>>>       
> it
>   
>>> be (priority, order, ID) or something like that? (Where "order" is
>>>       
> the
>   
>>> as the "total number of trees". The n trees computed are the ones
>>>       
> using 
>   
>>> the three for which the triple "(cost of root to me, priority, ID)"
>>>       
> are
>   
>>> the k smallest.
>>>
>>> @@@ Of course the ranking has to be the same so if "order" were added
>>>       
> as
>   
>>> Intuition: suppose there is a topology with a lot of "leaf"
>>>       
> RBridges., 
>   
>>> If there are m leaf RBridges connected to next level RBridge RBx,
>>>       
> then 
>   
>>> comparison tuple as above, in the default case where all Rbridges
>>>       
> have
>   
>>> the default priority, order 1 Rbridges would automatically have
>>>       
> lowest
>   
>>> b) a change to the list of "tree roots I will choose" announced by
>>>       
> RB2 
>   
>>> around) trees for old roots as long as their reasonably might be
>>>       
> frames
>   
>>> in transit specifying those roots. It has to calculate trees for any
>>>       
> new
>   
>>> use them. What root (or from what set of roots) to choose for new
>>>       
> native
>   
>>> multi-destination frames an Rbridge is encapsulating is a bit
>>>       
> messier.
>   
>>> intersection of the sets of old and new roots. If that intersection
>>>       
> is
>   
>>> null, something only likely to occur when there are a very small
>>>       
> number
>   
>>> of tree roots, you have a bit of a problem and might as well use the
>>>       
> new
>   
>>> RequestTree was FALSE for all Rbridges and the Rbridge with the
>>>       
> lowest
>   
>>> system ID, which had defaulted to being the only tree root, goes
>>>       
> down.
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Apr 2008 10:53:12 -0700

> when one of the roots for the k best (cost to me, priority, ID) goes down.

Has anybody looked at the volatily when the network comes up e.g., after 
a building power failure?

In that case RBridges will start sending hellos incrementally adding 
adjacencies, and receive flooded LSAs from RBridges that have just appeared.

Clearly if the network builds one RBridge at a time the regular unicast 
tree (the one rooted at the RBridge itself) would end up being 
recalculated up to N times (perhaps even more if the adjacencies between 
the N RBridges come up incrementally).

But here we are adding the fact that the *set of* multi-destination 
trees you to calculate would change as the network powers up. Do we know 
anything about the amount of churn that would cause?
It seems like receiving the first flooded LSA from an RBridge that just 
came up could cause the receiver to conclude that one (or more than 
one?) of the trees it has calculated are no longer needed, and that it 
instead needs to calculate a different set of trees.
A later LSA (from a different RBridge) could cause things to switch back 
to use the trees that were just discarded.

It sounds like this behavior can be quite dynamic.

    Erik

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 2 Apr 2008 11:08:48 -0700

I would go even further and say that 1 tree is what
should be mandated.

Anoop 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Tuesday, April 01, 2008 9:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] (slight) modification of how to choose 
> mulitcast trees
> 
> Why 8 ? I prefer something much less. But again, this isn't 
> something I'd debate much about. Priority will be configured 
> as users want predictablity and determinism.
> 
> Dinesh
> > Subject: Re: [rbridge] (slight) modification of how to choose 
> > mulitcast trees
> >
> > Slight modification. I'd want the default to be smaller, 
> say 2 or 4. 
> > But
> >
> > I won't quibble,
> >
> > Dinesh
> >
> >> RBridges, since RBridges wouldn't know the number of 
> bridges. I'd say 
> >> we should pick a number like "10".
> >>     
> >
> >> endnodes...so I'm not sure. Maybe it has to be "RBridge 
> adjacencies". 
> >> But does having a fluctuating "order" cause problems? In theory we 
> >> might want a pseudonode to be a tree root, but pseudonodes 
> don't get 
> >> nicknames, and therefore can't be specified as a tree root in the 
> >> TRILL header.
> >>
> >> lower than "0"). And "order" can be calculated from the LSP -- it 
> >> doesn't have to be separately announced. Though if you
> >>     
> > are
> >   
> >> connected to a pseudonode do you have to remember to count all the 
> >> RBridges connected to that pseudonode?
> >>
> >> It might be simpler to just have "order" feed into 
> priority, as in, 
> >> if
> >>     
> >
> >   
> priority is 
> >> configured, you'd leave it at whatever it is configured to
> >>     
> > be.
> >
> >>> I would suggest that the default be something like the 
> square root 
> >>> of the number of Rbridges in the campus. (See comment below on
> >>>       
> > volatility.)
> >   
> >>> numerically lowest priority, and then numerically lowest ID being 
> >>> the tie breaker, dictates the total number of trees all the other
> >>>       
> > RBridges
> >   
> >>> must calculate (the number that R1 announces in its LSP 
> according to 
> >>> rule 2 above.
> >>>
> >>> announced by the lowest (priority, ID) RBridge R1, in 
> R1's LSP, as 
> >>> the "total number of trees". The n trees computed are the ones
> >>>       
> > using
> >   
> >>> multidestination frames, the k tree roots that RB1 
> chooses consist 
> >>> of
> >>>       
> >
> >   
> RBridges as 
> >>> root -- the tree rooted at RBx will be the same tree, and
> >>>       
> >
> >   
> >>> will indeed be a shortest path tree for each of the attached leaf 
> >>> RBridges. If a leaf RBridge is attached to several next-level 
> >>> RBridges, the most significant number in the triple -- 
> "cost of root 
> >>> to me" will cause the leaf RBridge to multipath the multicast
> >>>       
> >
> >   
> >>> connected to an Rbridge of order >1 seems so simple to check for 
> >>> that you could just rule them out. Or, if "order" were 
> added to the 
> >>> because they'll have to compute a tree for every RBridge 
> that says 
> >>> it will want to be a tree root.
> >>>
> >>> priority-to-be-tree-root being reconfigured. But the solution to 
> >>> them all is the same. An Rbridge has to keep calculating (or at 
> >>> least keep
> >>> roots right away and, if appropriate, start advertising that it 
> >>> might use them. What root (or from what set of roots) to 
> choose for 
> >>> new
> >>>       
> > native
> >

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 02 Apr 2008 11:36:48 -0700

I'm fine with that,

Dinesh
Anoop Ghanwani wrote:
>>>> a) I don't see how there can be a default of square root 
>>>>         
>> of number of 
>>     
>>>> But then you really want "RBridge adjacencies" and not 
>>>>         
>> just ports to 
>>     
>>>> making "order" be 1000 minus the number of RBridge 
>>>>         
>> adjacencies, going
>>     
>>>>     
>>>>         
>>> no
>>>   
>>>       
>>> @@@ I'm fine with order feeding into priority in some 
>>>       
>> fashion if your 
>>     
>>> priority is not configured. People who are configuring 
>>>       
>> ought to know 
>>     
>>>>> the RequestTree be TRUE probably results in Rbridges 
>>>>>           
>> being required
>>     
>>>>>       
>>>>>           
>>> to
>>>   
>>>       
>> [mailto:[email-masked]]
>>     
>>>>>       
>>>>>           
>>> On
>>>   
>>>       
>>>>> Behalf Of Radia Perlman
>>>>> Subject: [rbridge] (slight) modification of how to choose 
>>>>>           
>> mulitcast 
>>     
>>>>> trees
>>>>>
>>>>> 1) Each RBridge is configured with a priority for being 
>>>>>           
>> selected a 
>>     
>>>>> @@@ So what's the recommended default here? It might 
>>>>>           
>> sound a bit odd
>>     
>>>>>       
>>>>>           
>>> but
>>>   
>>>       
>>>>> like (priority, ID), why not make it a little more clever 
>>>>>           
>> by having
>>     
>>>>>       
>>>>>           
>>> it
>>>   
>>>       
>>>>> number of adjacencies the Rbridge has, so you'd have to 
>>>>>           
>> change the 
>>     
>>>>> 4) An RBridge calculates n distribution trees, where n is 
>>>>>           
>> the number 
>>     
>>>>> 5) if RB1 is ingress RBridge on port p, and (*note 
>>>>>           
>> another parameter
>>     
>>>>> the three for which the triple "(cost of root to me, 
>>>>>           
>> priority, ID)"
>>     
>>>>>       
>>>>>           
>>> are
>>>   
>>>       
>>>>> the k smallest.
>>>>>
>>>>> RBridge, the set of root RBridges to choose for multicast 
>>>>>           
>> tree roots.
>>     
>>>>> It also means that you can configure in one place a total 
>>>>>           
>> number of 
>>     
>>>>> roots, rather than possibly having too many RBridges 
>>>>>           
>> volunteer for 
>>     
>>>>> being tree roots, and winding up with too much overhead 
>>>>>           
>> on RBridges 
>>     
>>>>> a) a change to the total number of trees to be computed 
>>>>>           
>> by everyone 
>>     
>>>>> when one of the roots for the k best (cost to me, 
>>>>>           
>> priority, ID) goes 
>>     
>>>>> down.
>>>>>
>>>>> @@@ There are plenty of other possible causes for 
>>>>>           
>> volatility. Like a 
>>     
>>>>> in transit specifying those roots. It has to calculate 
>>>>>           
>> trees for any
>>     
>>>>>       
>>>>>           
>>> new
>>>   
>>>       
>>>>> intersection of the sets of old and new roots. If that 
>>>>>           
>> intersection
>>     
>>>>>       
>>>>>           
>>> is
>>>   
>>>       
>>>>> of tree roots, you have a bit of a problem and might as 
>>>>>           
>> well use the
>>     
>>>>>       
>>>>>           
>>> new
>>>   
>>>

---

From: Radia Perlman <[email-masked]>
Date: Sat, 05 Apr 2008 18:05:37 -0700

I don't understand. What do you mean by "mandated"? Do you mean 
"recommended default=1"?
That probably wouldn't be controversial. But if you mean "mandated" as 
in, "only do one tree" (which was my original
assumption, by the way), I'm sure that would be controversial.

I'm almost certain you meant "recommended default=1", rather than 
"mandate one tree"
but it would be good to clarify what you meant.

Radia

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Sun, 6 Apr 2008 19:28:51 -0700

Yes, I meant recommended default=1.  To me, that
would mandate that my implementation be capable
of computing at least that many trees, hence
the choice of language.

Anoop

-----Original Message-----
From: [email-masked] on behalf of Radia Perlman
Sent: Sat 4/5/2008 6:05 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] (slight) modification of how to choose mulitcast trees

Radia

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 6 Apr 2008 23:49:16 -0400

Hi,

On "Why 8", or really why >1, as the recommended default number of
distribution trees, my answer is as follows:

Having more than one distribution tree has a bunch of benefits.
+   It probabilistically reduces the concentration of multi-destination
traffic onto particular links and increases the aggregate capacity for
them in much the same way that using IS-IS does in comparison with
spanning tree.
+   By choosing a tree rooted nearby when you are encapsulating an
unknown unicast frame, you reduce the probability of mis-ordering frames
when the address become known. (In the limit, if you root a tree for
every node, the probability of mis-ordering becomes very small.)
+   Finally, unless you do a tree for every node, there are things that
can happen which will change the set of tree calculated. This can
include nodes going down, coming up, having their priority or
RequestTree flag or whatever you are using reconfigured, etc. If you
have only one tree, you are guaranteed that when that one tree changes
all multi-destination frames in flight now refer to a tree that is no
longer supposed to be computed and all newly encapsulated frames need to
refer to a new frame which may not yet have been calculated. Most
methods of automatically choosing which nodes to use as tree roots are
designed to be reasonably stable so the probability is low that the
entire set of tree would change even if that set has only a few members.
In fact, if you are calculating k trees, most commonly only 1 would lose
its must-be-calculated status and k-1 would remain. Thus it is more
likely that, after a change in the tree set, frames in flight still
refer to trees that are being calculated. And it would be a reasonable
strategy to, for a short time, use trees in the intersection of the old
and new sets when frames are newly encapsulated so as to make it highly
probably that nodes forwarding such frames will already have computed a
tree for the root specified.

The more tree the better, according to the above factors. So what's the
disadvantage of having many distribution trees? There is no effect on
the size of the link state database or volume of routing information.
It's really just a local computational cost. Assuming building a tree
with n nodes and L pair wise links, the effort is proportional to L +
n*(log n). Thus building one for every node would be n*(L + n*(log n))
or n*L + (n**2)*(log n) effort. This is certainly a bit daunting for
large n. So we seem to be looking for some k, the recommended default
number of trees, such that k*(L + n*(log n)) is tolerable. Actually, in
order to perform unicast forwarding, each node needs to, in effect,
compute a tree rooted on itself. So it has to do n*(log n) even if there
are zero multi-destination trees. So we are looking for a recommended
default number of trees k such that (k+1)*(L + n*(log n)) is tolerable.
(These are all approximations.)

Numbers that have been suggested for k are 1, 2, 4, 8, and 10. I don't
think that we have the data or the scoring criteria to calculate an
optimal value. I think TRILL should be aiming several years out when
Moore's law will have had further effect. People in the ISIS working
group keep saying that Dijkstra calculations are cheap can be done
quickly. Even with only one distribution tree, you still have to
actually calculate two trees because you need, in effect, a self rooted
one for unicast. While I certainly don't want to make the argument that
if you can do N, you should be able to do N+1, and thus by induction
could do an unbounded number, still, it seems to me that if you have to
calculate at least 2 tree, making the recommended default 2 or 4 (i.e.,
so you end up calculating 3 or 5 distribution trees) just shouldn't be
that hard and yields considerable benefits in multi-destination traffic
capacity, reduced mis-ordering, and increased stability due to trees
that remain valid across typical changes in the set of distribution
trees to calculate. I still think 8 is reasonable and I don't see why
you would set k to 1 unless you wanted to restrict the default campus
performance for multi-destination traffic to be no better than that of
bridges with a single spanning tree.

Thanks,
Donald

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2008 12:33 AM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] (slight) modification of how to choose mulitcast
trees

Dinesh
mulitcast

perhaps
no 
are

---

From: "Silvano Gai" <[email-masked]>
Date: Mon, 7 Apr 2008 07:01:35 -0700

8 is too much,
I will prefer 1, I can accept 2.

-- Silvano

On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Sunday, April 06, 2008 8:49 PM
mulitcast
mulitcast

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 07 Apr 2008 08:04:27 -0700

Donald,

We're talking about defaults here, not what is the maximum. I hear your 
arguments but 8 is too much for smaller networks. I know of one large 
customer who's thinking of 16, but most prefer 2-4.

Dinesh
Eastlake III Donald-LDE008 wrote:
>> Slight modification. I'd want the default to be smaller, say 2 or 4.
>>     
> But
>   
>> I won't quibble,
>>
>> Dinesh
>>
>>> A few questions about "order": "ports" is known in advance and
>>>       
> doesn't
>   
>>> It might be simpler to just have "order" feed into priority, as in,
>>>       
> if
>   
>>> priority is configured, you'd leave it at whatever it is configured
>>>       
> to be.
>

---

From: "Silvano Gai" <[email-masked]>
Date: Mon, 7 Apr 2008 09:45:07 -0700

I agree with Dinesh, we are discussing the default.
One should be the default, you can config as high as you like

-- Silvano

On
> Behalf Of Dinesh G Dutt
> Sent: Monday, April 07, 2008 8:04 AM
> Cc: Developing a hybrid router/bridge.
mulitcast
mulitcast
> > Why 8 ? I prefer something much less. But again, this isn't
something