Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)

Mingui Zhang <zhangmingui@huawei.com> Fri, 21 August 2015 01:32 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 19A601A0162; Thu, 20 Aug 2015 18:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 is5QiybGUsyK; Thu, 20 Aug 2015 18:32:48 -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 AA4671A014C; Thu, 20 Aug 2015 18:32:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWN93625; Fri, 21 Aug 2015 01:32:45 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 21 Aug 2015 02:32:44 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.33]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Fri, 21 Aug 2015 09:32:37 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)
Thread-Index: AQHQ2n297KACDXoA4Ui65GT9PKA+k54UH08A///2SQCAAYwDoA==
Date: Fri, 21 Aug 2015 01:32:36 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7871A0084@nkgeml512-mbx.china.huawei.com>
References: <20150819120129.21242.5533.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78719FB6F@nkgeml512-mbx.china.huawei.com> <55D59A00.8000601@cs.tcd.ie>
In-Reply-To: <55D59A00.8000601@cs.tcd.ie>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.146.93]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/94q7mpk9LDcHfDVninkxiw9F8yk>
Cc: "draft-ietf-trill-aa-multi-attach.shepherd@ietf.org" <draft-ietf-trill-aa-multi-attach.shepherd@ietf.org>, "draft-ietf-trill-aa-multi-attach.ad@ietf.org" <draft-ietf-trill-aa-multi-attach.ad@ietf.org>, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, "trill@ietf.org" <trill@ietf.org>, "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "draft-ietf-trill-aa-multi-attach@ietf.org" <draft-ietf-trill-aa-multi-attach@ietf.org>
Subject: Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 21 Aug 2015 01:32:49 -0000

Hi Stephen,

Thanks for the suggestions!

> Good improvements. For this (fairly ignorant) reader though, saying "keep all
> the attachments" is still a bit puzzling. If that's normal trill phraseology then
> it's probably best as-is, but if not, maybe it'd be better something like:
> 
> NEWNEW
>     Thus, remote edge RBridges (who are not in the group) will see
>     one host MAC address being associated with the multiple RBridges
>     in the group. Such remote edge RBridges are required to
>     maintain all those associations and to not flip-flop among them
>     which would be the behaviour prior to this specification.
> NEWNEW

[MZ] I agree the word "association" is more easily to be understood. Let's incorporate the text. And, since the word "attach" is used everywhere, it'd be helpful to relate them as below.

...maintain all those associations (i.e., MAC attachments) and ...

> Heh:-) I'm not so sure I agree that faking an ESADI message from the right
> place within the campus would be that hard.

[MZ] Yes, I agree. Faking an ESADI message is possible and it has been captured in [RFC7357].

> But I also note that you've
> answered that my example doesn't work which is fine, but you didn't explicitly
> say that the general analysis had been done. I'll assume that you did mean that
> though:-)

[MZ] Yes, we did:-)

Thanks,
Mingui