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

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> Wed, 28 November 2012 03:45 UTC

Return-Path: <tsenevir@cisco.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348A21E8030; Tue, 27 Nov 2012 19:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDBRW8y9Cld4; Tue, 27 Nov 2012 19:45:44 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 95BFB21F8449; Tue, 27 Nov 2012 19:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56680; q=dns/txt; s=iport; t=1354074343; x=1355283943; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CqLd8cukwlH1FucxoqIm8rwBKmVke5IYof6aVj+xkXc=; b=fYpLi+a3xflx6E58aWHLv+6Zox4/pT3dabJ2K1OCdtrRsmxH/ZHM3EGS ViSXmtoidDKyBJ0Ti1bADb541VNZGrXoawfIZDcCf4aX8kUMHq1TBmfvP lAHisN5BoYPMvX/XkHYqTNe67yvMdud+Ezp+vJqQAWOCRC2oilHe2639y I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmsMALOHtVCtJV2Z/2dsb2JhbABFgkmDYLh/exZsB4IeAQEBBAEBASpBCxACAQYCEQQBAQsLCwEGBQICJQsUCQgCBA4FCBOHcgysRgiETo4PBIw6gQ6CHDZhA6ZFgmMNgiA
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146913206"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 28 Nov 2012 03:45:42 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAS3jgrO000758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 03:45:42 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.130]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 21:45:42 -0600
From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: "liao.ting@zte.com.cn" <liao.ting@zte.com.cn>
Thread-Topic: Re: [trill] draft-ietf-trill-cmt
Thread-Index: Ac2+FF0H+VMAhVydQOe90fdycFINlgLXltQAAG52p5AAHnL5AAARf38AADGjD4AAACHO8AAlYbKAAAvGWQA=
Date: Wed, 28 Nov 2012 03:45:41 +0000
Message-ID: <FBEA3E19AA24F847BA3AE74E2FE19356288761ED@xmb-rcd-x08.cisco.com>
References: <FBEA3E19AA24F847BA3AE74E2FE1935628875C0F@xmb-rcd-x08.cisco.com> <OFB6D0E97A.AA5BE496-ON48257AC4.00056B68-48257AC4.0011F174@zte.com.cn>
In-Reply-To: <OFB6D0E97A.AA5BE496-ON48257AC4.00056B68-48257AC4.0011F174@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.126.101]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE19356288761EDxmbrcdx08ciscoc_"
MIME-Version: 1.0
Cc: "trill-bounces@ietf.org" <trill-bounces@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] draft-ietf-trill-cmt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 03:45:45 -0000

Hi Tina

I must admit, I did not fully understand what you mean by some of the items below

1)how to choose the member RB
Current proposal is to consider all RBridges announcing nickname RBv to be members.
2)how the chosen member RB  to collect the tree configured information
[not clear with what you meant]
3)how to announce the tree allocation information
[currently, each RBridge use a standard algorithm and all RBridges can deduce the trees used by member RBridges RBv]

If you want more complex and extensible solution, I think it is best to write a separate draft.

Thanks
Tissa
From: liao.ting@zte.com.cn [mailto:liao.ting@zte.com.cn]
Sent: Tuesday, November 27, 2012 7:16 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: 答复: Re: [trill] draft-ietf-trill-cmt


Hi,Tissa

IMO, maybe the following informations should be standarded:
1)how to choose the member RB
2)how the chosen member RB  to collect the tree configured information
3)how to announce the tree allocation information

And with regard to failover protection, when any other member RB fails,
the failure information should be transmitted to the chosen member RB,
and the chosen member RB will reallocate trees among member RBs except the failed one.
If the chosen member RB had failure, there should be a slave chosen member RB elected to be the master.

OK, maybe that will be too complex, and more likely to be a local administrative policy, but if the CMT mention about that, it will be more impeccable. :)

Thanks,
Tina


"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com<mailto:tsenevir@cisco.com>>
发件人:  trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>

2012-11-27 23:34

收件人

"liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>" <liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>>

抄送

"trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>" <trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>>, "trill@ietf.org<mailto:trill@ietf.org>" <trill@ietf.org<mailto:trill@ietf.org>>

主题

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







Hi Tina

What you are looking at is a local administrative policy, I am not clear what to be specified in a standard. Additionally manual configurations does not provide failover protection. I think it is best to leave the administrative policies to platforms.

Additionally, when multiple tree allocation algorithms are present, we need to ensure that all of the RBv are using the exact same algorithm, which will make matters complicated. So in short, if one would like to use a different algorithm than what is specified in the standard, it is up to them to do so and ensure that they meet

1.       Failover requirements
2.       Algorithm consistency between members

Thanks
Tissa


From: liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn> [mailto:liao.ting@zte.com.cn]
Sent: Tuesday, November 27, 2012 1:22 AM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org<mailto:trill@ietf.org>; trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>
Subject: 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<mailto:tsenevir@cisco.com>>
发件人:  trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>

2012-11-26 23:44


收件人

"liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>" <liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>>

抄送

"trill@ietf.org<mailto:trill@ietf.org>" <trill@ietf.org<mailto: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> [mailto:liao.ting@zte.com.cn]
Sent: Sunday, November 25, 2012 5:19 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org<mailto:trill@ietf.org>; trill-bounces@ietf.org<mailto: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<mailto:tsenevir@cisco.com>>
发件人:  trill-bounces@ietf.org<mailto:trill-bounces@ietf.org>

2012-11-26 00:50




收件人

"liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>" <liao.ting@zte.com.cn<mailto:liao.ting@zte.com.cn>>

抄送

"trill@ietf.org<mailto:trill@ietf.org>" <trill@ietf.org<mailto: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> [mailto:liao.ting@zte.com.cn]
Sent: Thursday, November 22, 2012 10:05 PM
To: Tissa Senevirathne (tsenevir)
Cc: trill@ietf.org<mailto:trill@ietf.org>; trill-bounces@ietf.org<mailto: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<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill_______________________________________________
trill mailing list
trill@ietf.org<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill_______________________________________________
trill mailing list
trill@ietf.org<mailto:trill@ietf.org>
https://www.ietf.org/mailman/listinfo/trill