Re: [trill] draft-ietf-trill-cmt

Hi,Tissa

Maybe the CMT is just to announce the Affinity Capability, IMO, the CMT is 
used to solve the tree allocation problem in RBv.
Such as the figure described in RFC6325 P93 for example: the network 
manager may be want to do some manual configuration in the situation.
                              +---+
                              |RBy|---------------+
                              +---+               |
                             /  |  \              |
                           /    |    \            |
                         /      |      \          |
                      +---+   +---+   +---+       |
                      |RB1|---|RB2|---|RB3|       |
                      +---+   +---+   +---+\      |
                        |       |       |    \    |
                      +---+   +---+   +---+    \+---+
                      |RB4|---|RB5|---|RB6|-----|RBz|
                      +---+   +---+   +---+    /+---+
                        |       |       |    /
                      +---+   +---+   +---+/
                      |RB7|---|RB8|---|RB9|
                      +---+   +---+   +---+
There are two distribution trees in the network, one rooted at RBy will 
predominantly use the vertical links among RB1 through RB9 
while another rooted at RBz will predominantly use the horizontal.
RB1\RB4\RB7\RB8\RB9 are all edge RBs, by default, each will choose the 
shortest path’s tree root to use,
and each may use the two trees to multipathing multi-destination traffic 
at the same time. 
But if we have RB1 and RB7 in a RBv, then we have to allocate different 
trees between RB1 and RB7.
With the current CMT manner, maybe RBz is allocated to RB1, RBy is 
allocated to RB7.
Obviously,RB1 is closer to RBy, so the network manager may want to 
manually configure RBy to RB1 as an algorithm intervention.

As the local policy/administrative matter, how to compatible with manual 
configuration, maybe it is a question within the RBv's tree allocation?

I think this may be solved by choosing a member RB, which is used to 
collect configuration information of RBv,
and execute an unified algorithm to allocate trees for all members within 
the same RBv. 
There are two benefits by doing so: first, it is compatible, second there 
is no need for all other member RBs to execute the algorithm.

Thanks,
Tina

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> 
发件人:  trill-bounces@ietf.org
2012-11-26 23:44

收件人
"liao.ting@zte.com.cn" <liao.ting@zte.com.cn>
抄送
"trill@ietf.org" <trill@ietf.org>
主题
Re: [trill] draft-ietf-trill-cmt

Hi Tina

Answer is no need and it is already built in. Here is why. We propose to 
announce the Affinity Capability.  CMT specification is that RBridge 
announcing that capability must follow the specified tree allocation. If 
some RBridge is announcing the affinity capability and yet doing manual 
allocation then it is an implementation error or local 
policy/administrative matter.

Thanks
Tissa

From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn] 
Sent: Sunday, November 25, 2012 5:19 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt

Hi,Tissa 

Yes，that's exactly what I mean. :) 
Should the CMT take this scenario into account？ 

Thanks,
Tina 

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> 
发件人:  trill-bounces@ietf.org 
2012-11-26 00:50 

收件人
"liao.ting@zte.com.cn" <liao.ting@zte.com.cn> 
抄送
"trill@ietf.org" <trill@ietf.org> 
主题
Re: [trill] draft-ietf-trill-cmt

Hi Tina 

I am not sure I completely understand your question. Are you referring to 
a scenario where some of the members (e.g. RB1 ) are using some manual 
configuration and other is using the proposed method (e.g. RB2) in the CMT 
draft ? 

PS: Both RB1 and RB2 are members of the virtual RBridge RBv 

From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn] 
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] draft-ietf-trill-cmt 

Hi,Tissa 

Section 5.1 provides a simple general method to assign different trees to 
different members and it is easy to employ. 
But in my opinion, it could be better to allow co-existence of default 
manner（cmt） and manual configuration 
for distribution tree choosing，otherwise if some member RBs are manually 
configured and others are not configured at all, 
compatibility problem with the current algorithm could occur. 
So, maybe we should provide a unified tree distribution method which is 
compatible 
with manual configuration and can ensure different member RBs obtain 
different  distribution tree? 

Thanks,
Tina _______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill