RE: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

Mingui Zhang <zhangmingui@huawei.com> Tue, 01 September 2015 02:16 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CFD1B5E6C; Mon, 31 Aug 2015 19:16:09 -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 eLAS-ABAJaXE; Mon, 31 Aug 2015 19:16:08 -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 070241B738C; Mon, 31 Aug 2015 19:16:06 -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 BWZ53339; Tue, 01 Sep 2015 02:16:05 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 03:16:04 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.33]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 10:15:58 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: Sandra Murphy <sandy@tislabs.com>
Subject: RE: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Thread-Topic: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Thread-Index: AQHQ4RO7GL3QfcPgCUuUTfg8C/4Zkp4lTBGwgADvVgCAALFKMA==
Date: Tue, 01 Sep 2015 02:15:58 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7871A3178@nkgeml512-mbx.china.huawei.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com> <4552F0907735844E9204A62BBDD325E7871A2CFE@nkgeml512-mbx.china.huawei.com> <B96ADDA3-73A8-404B-A75F-9C6F9BB2E9D7@tislabs.com>
In-Reply-To: <B96ADDA3-73A8-404B-A75F-9C6F9BB2E9D7@tislabs.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/B-nEHWFP2VIGj-7s_9MDUGvs5kk>
X-Mailman-Approved-At: Tue, 01 Sep 2015 08:04:24 -0700
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>, "draft-ietf-trill-pseudonode-nickname.all@ietf.org" <draft-ietf-trill-pseudonode-nickname.all@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 02:16:10 -0000

Hi Sandy,

> I just replied to Russ's message before I read your response.
> 
> The draft language is just as Russ said.

[MZ] That's OK :)

> 
>    It is important that the VLAN membership of all the RBridge ports in
>    an LAALP MUST be the same.  Any inconsistencies in VLAN membership
>    may result in packet loss or non-shortest paths.
> 
> Following this, there is a paragraph fully describing an inconsistent
> configuration.

[MZ] Yes, that paragraph further explains the possible consequences of inconsistency. 

> 
> If it is not possible for inconsistencies to occur, then why are you mentioning
> them?  Why give an explicit example of an inconsistent VLAN configuration?

[MZ] This is to explain why consistency becomes a requirement for LAALP implementations that are connected to TRILL edge. Implementations that cannot fulfill this requirement should not be used to connect to TRILL edge. IOW, it is not qualified as an LAALP as defined in TRILL. You can also refer to the second 'c)' of Section 2.1 [RFC7379]. 

> 
> You say "if the consistence cannot be maintained, it is not qualified as a LAALP".
> But the example shows a configuration case where inconsistency happens.

[MZ] As explained above.

> Does that mean it is not an LAALP?  

[MZ] No, it's not an LAALP as TRILL defined and required. 

> Does the spec for LAALP ensure
> consistency (and if so, why mention inconsistencies and provide examples)?

[MZ] There are several proprietary link aggregation techniques in the industry. It's possible that some of them does not meet this requirement. So the requirement is a criteria for choosing LAALP implementations. I think this is easy for operators. 
It's possible that operators want to do manual configuration. In that case, the consistency requirement still holds. 

> Does anything in TRILL detect the absence of consistency?

[MZ] I think the detection of inconsistency is out the scope of TRILL. However, it's natural that an edge RBridge device implements both TRILL and LAALP. This device can detect the consistence by using LAALP.

Thanks,
Mingui

> 
> -Sandy