Re: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00

Mingui Zhang <zhangmingui@huawei.com> Tue, 05 August 2014 02:26 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCF1A8BB4 for <trill@ietfa.amsl.com>; Mon, 4 Aug 2014 19:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.752
X-Spam-Level:
X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYBFoXT19O_R for <trill@ietfa.amsl.com>; Mon, 4 Aug 2014 19:26:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE581A0BE8 for <trill@ietf.org>; Mon, 4 Aug 2014 19:26:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX35770; Tue, 05 Aug 2014 02:26:09 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 03:26:07 +0100
Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.225]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 10:25:56 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: Haoweiguo <haoweiguo@huawei.com>
Thread-Topic: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00
Thread-Index: AQHPrIwLZl7xxZ/tJk2SEirtXwgFFpu53u9QgAaR5deAAMZT8A==
Date: Tue, 05 Aug 2014 02:25:55 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E76A0ECEFA@nkgeml508-mbx.china.huawei.com>
References: <DD5FC8DE455C3348B94340C0AB5517334F7E7803@nkgeml501-mbs.china.huawei.com>, <4552F0907735844E9204A62BBDD325E76A0EC41A@nkgeml508-mbx.china.huawei.com> <DD5FC8DE455C3348B94340C0AB5517334F7EDC80@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <DD5FC8DE455C3348B94340C0AB5517334F7EDC80@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.175]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/fh2vcshUlS7sQX8hvkgt6qi08H4
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 05 Aug 2014 02:26:13 -0000

Hi Weiguo,

You mentioned the DF election algorithm. It can be classified as a hashing function as well. If it elects DF per VLAN, we can well say it's a hashing function taking VLAN as the input. So, I think this is simply a terminology dispute. The architecture of aa-multi-attach allows proprietary 'hashing' implementations. As long as such implementations meet the requirement: single exit point.

Since the Local Active-Active Link Protocol (LAALP (As agreed previously, the term MC-LAG will be replaced by LAALP in the next version)) should have designed such hashing function, we should not re-design it. Think about the inconsistence issue that may be caused by the hashing functions designed by different communities.  

By the way, it's not strange to have TRILL switches listen to the 'under' layer PDUs. Please look at RFC6325. Think about the fact that TRILL switches listen to BPDUs.

Thanks,
Mingui

>-----Original Message-----
>From: Haoweiguo
>Sent: Monday, August 04, 2014 9:09 PM
>To: Mingui Zhang
>Cc: trill@ietf.org
>Subject: 答复: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00
>
>Hi Mingui,
>Thanks for your detail explanation.
>In your draft, DRNI defined in IEEE is refered and it has not become the deployed
>standard yet. So I am not too sure how our internal implementation works for
>MC-LAG.
>Another issue is even we have MC-LAG based on hashing function to select a
>single exit point, is such information available to TRILL protocol layer? I kind of
>think such info is under the trill layer. But I am not too sure whether such
>implementation can be done.
>weiguo
>
>________________________________________
>发件人: Mingui Zhang [zhangmingui@huawei.com]
>发送时间: 2014年7月31日 17:54
>收件人: Haoweiguo
>抄送: trill@ietf.org
>主题: Re: [trill] Two comments on draft-ietf-trill-aa-multi-attach-00
>
>Hi Weiguo,
>
>Thanks for posting the comments to the list. Let me clarify them.
>
>1. It's possible to design a DF election algorithm to meet the 'single exit point'
>requirement. It did not become our design due to the complexity. The hashing
>function is a mandatory function of MC-LAG, we believe it's simpler to make use
>of it to determine the single exit point.
>
>2. I think we have covered the scenarios about "local bias forwarding
>procedures" in Appendix a, d and e. This behavior is actually not new staff.
>Please see paragraph 3 of Section 4.6.1.2 in RFC 6325. (There was ever a lot of
>discussion about this issue.)
>
>"For all multi-destination native frames, RB1 forwards the frame in
>   native form to its links..."
>
>The basic idea is that if there are end nodes that can be reached from local ports,
>packets should be bounced to these ports rather than hair-pined to these end
>nodes across the TRILL campus. Since the hair-pin has been cut off by the
>split-horizon.
>
>Thanks,
>Mingui
>
>>-----Original Message-----
>>From: Haoweiguo
>>Sent: Thursday, July 31, 2014 2:53 PM
>>To: Mingui Zhang
>>Cc: trill@ietf.org
>>Subject: Two comments on draft-ietf-trill-aa-multi-attach-00
>>
>>Hi Mingui,
>>
>>In section 5.3.1, no duplication mechanism is described. I think DF election
>>should be used instead of HASH mechanism.
>>
>>It's hard to realize consistent cross RBridge HASH algorithm, each RBridge
>>should know other RBridge's local port and port up/down state, i have not ever
>>seen similar implementation in industry.
>>
>>
>>
>>In section 5.3.2 , split-horizon mechanism is described. I think the solution had
>>better add local bias forwarding procedures.
>>
>>I think the solution should be local bias forwarding plus split-horizon based on
>>ingress nickname. What's local bias forwarding behavior? If there are multiple
>>ESs(assuming ES1 and ES2 are in same VLAN) are connected to same RBridge
>of
>>RB1,  when RB1 receives BUM traffic from ES1, it should local forwarded to
>ES2
>>no matter the DF state on the port connecting to ES2, this is called Local bias
>>forwarding behavior.
>>Then RB1 injects the BUM traffic to TRILL campus and forward to RB2, if local
>>port belongs to a MC-LAG and the MC-LAG attaches to RB1, then RB2 should
>>drop the traffic to the local port based on ingress nickname tracking and
>>filtering.
>>
>>
>>
>>Thanks
>>
>>weiguo