[rbridge] last call comment

[Jeff Pickering]

Radia,

Please understand that I am coming from the perspective of data center applications
where the heavily predominant architecture is one of a 3 tier fat tree with a radix
of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2
for approximately 60% of the RBs (assuming top tier root placement which is what
customers appear to want). I worry about the j mod p algorithm's impact on convergence 
times in this scenario. 

The algorithm provides no improvement in load sharing in this scenario either. And while
I understand that writing a spec for a particular architecture is inappropriate (just look to
What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p
is really only ensured to help load sharing in the specific case of co-located roots or 
at least located very close together. In other cases, it may actually decrease load sharing.

I understand your point that b) is no change and that it decreases at least some aspects
of the increased storage/sorting that needs to be done. However, I would still prefer c)
(5 seems realistic) because it limits the impact of optimizing for co/near located root case
while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b).

I someone wants to load share more than a new architectural constant, they can always do this
using root placement. Or if there is a real problem with the constant, we can always make it
configurable and place each RBs value in an LSP (we already have similar mechanisms).


Jeff



-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Wednesday, July 01, 2009 6:02 PM
To: Jeff Pickering
Cc: rbridge at postel.org
Subject: Re: [rbridge] last call comment

Well, if we want to allow load splitting with at least p trees, then we 
have to keep p parents.

Alternatives to what is written, I think, are:

a) keep as is: while computing the tree, keep all p parents.

b) say that if p > j, then you only need to keep the top j choices of 
parent. (this
is true, and might be a good clarification to put in)

c) say that load splitting choices will never be more than, say, 5 (an 
architectural
constant we will choose now and be stuck with forever), and then say 
that the top
"5" choices of parents must be kept (so that the actual choice, for tree 
j, will
be j mod 5).

Choice b) does not affect the output-- it's just somewhat of an 
optimization for how
to compute the trees.

Would saying that be sufficient, or would you prefer that we actually 
limit the number of
potential load splitting choices?

Radia



Jeff Pickering wrote:
>    
>      Section 4.5.1
>  
>
>    "When building the tree number j, remember all possible equal cost
>
>    parents for node N. After calculating the entire "tree" (actually,
>
>    directed graph), for each node N, if N has "p" parents, then order
>
>    the parents according to 7-byte ID. For tree j, choose N's parent as
>
>    choice j mod p."
>
>  
>
>    I really dont like the idea of keeping all P parents, esp in an 
> environment
>
>    like fat tree where there may be dozens of upstream equal cost 
> parents (times thousands of nodes).
>
>       That said, we should at least say whether "order the parents" 
> means starting with lowest or highest.
>
>  
>
>  
>
>      Section 4.5.2
>
>  
>
>     
>
>       "In this case, R1-R2 adjacencies are ordered as follows, with
>
>       the one "most preferred" adjacency being the one that R1 transmits
>
>       to R2 on, and the one that R2 accepts traffic from R1 on:"
>
>  
>
>    
>
>       The way I read this, the statement is meaningless, R1 and R2 
> both transmit to each other. So
>
>       either the intent is to say R1 (or R2) is the RB closer to the 
> root. Or the intent is to say that depending
>
>       on whether traffic is flowing towards or away for the root, you 
> may choose a different adjacency. Whichever
>
>       interpretation is intended should be clarified.
>
>  
>
>     Section 4.5.2
>
>  
>
>  
>
>  
>
>  
>
>  
>
>       Jeff
>
>  
>
>  
>
>    
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>