Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Mingui Zhang <zhangmingui@huawei.com> Mon, 31 August 2015 03:55 UTC
Return-Path: <zhangmingui@huawei.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC41ACE40; Sun, 30 Aug 2015 20:55:38 -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 Fv6DhRIFc7-4; Sun, 30 Aug 2015 20:55:36 -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 D3ADF1ACE3D; Sun, 30 Aug 2015 20:55:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWY08556; Mon, 31 Aug 2015 03:55:04 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Aug 2015 04:55:03 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.33]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Mon, 31 Aug 2015 11:54:56 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: Russ Housley <housley@vigilsec.com>, "draft-ietf-trill-pseudonode-nickname.all@ietf.org" <draft-ietf-trill-pseudonode-nickname.all@ietf.org>
Thread-Topic: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
Thread-Index: AQHQ4RO7GL3QfcPgCUuUTfg8C/4Zkp4lTBGw
Date: Mon, 31 Aug 2015 03:54:55 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7871A2CFE@nkgeml512-mbx.china.huawei.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
In-Reply-To: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.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/gen-art/EHgkVy0G1R_wLX3LRtJOHeT-XpE>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 03:55:39 -0000
Hi Russ, Thanks for the comments. Please see the in-lines below. > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, August 28, 2015 5:59 AM > To: draft-ietf-trill-pseudonode-nickname.all@ietf.org > Cc: IETF; IETF Gen-ART > Subject: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05 > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-trill-pseudonode-nickname-05 > Reviewer: Russ Housley > Review Date: 2015-08-24 > IETF LC End Date: 2015-09-01 > IESG Telechat date: unknown > > Summary: Almost Ready > > Major Concerns: > > (1) In section 5.2, the document provides this formula: > "(System IDj | LAALPi) mod k". In my first reading, I missed the overloading of > "LAALPi", and I think it would be more clear to say "(System IDj | LAALP IDi) > mod k". > If this is accepted, the description becomes simple: > "... and the LAALP IDi is the LAALP ID for LAALPi". [MZ] This will be incorporated for easy reading. > > (2) Also, in Section 5.2, Step 1, I think the intended sort order depends on all > of the LAALP IDi values being represented with the same number of bits. > Since Section 9.1 provides a variable length field to carry a LAALP ID value, I > assume that they are not always the same length. Is a step needed to > encode the LAALP ID to a consistent length? [MZ] The sort is done in the per-LAALP base. It's not necessary to make the LAALP ID to a constant length. Besides, the 'mod' function always returns a value in [0, k-1] whatever the length of LAALP ID is. > > (3) In Section 11, we learn 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. > Is there anything that can be added to the Security Considerations that can > help avoid these inconsistencies? > [MZ] The LAALP is REQUIED to keep the consistence. That is to say, if the consistence cannot be maintained, it is not qualified as a LAALP. What TRILL switches can do is that ports connected to inconsistent LAALPs MUST be disabled. This requirement can be added. > > Minor Concerns: > > (1) In section 1, we learn that there is more than one way to handle > nicknames: > > ... A member RBridge of > such a group uses a pseudo-nickname, instead of its own nickname, as > the ingress RBridge nickname when ingressing frames received on > attached LAALP links. Other methods are possible; for example the > specification in this document and the specification in [MultiAttach] > could be simultaneously deployed for different AAE groups in the same > campus. > > Both of these specifications are Internet-Drafts in the TRILL WG. > Given this situation, I was expecting some discussion about how an > implementer was expected to choose and any consequences on interoperability > that result from that choice. [MZ] Yes, there was a Capability TLV in [MultiAttach] to handle the interoperability. Explicit consequences can be explained here. > > (2) I found the last sentence of Section 2 confusing. I am suggesting a > rewording to see if I figured it out. If I did not figure it out properly, then the > sentence really does need to be reworked. > > Under the assumption that the default learning is enabled at > edge RBridges, MAC flip-flopping can be solved by using a > Virtual RBridge together with its pseudo-nickname. This > document specifies a way to do so. [MZ] Yes, this is clear. Will be incorporated. > > (3) In Section 5.1, it says: > > This document uses the approach proposed in [CMT] to fix the RPF > check violation issue. Please refer to [CMT] for more details of the > approach. An alternative solution is proposed in [CentralReplicate]. > > Is the alternate solution compatible or incompatible with this document? > I am not sure from this paragraph; please add a few words to be clear. > [MZ] Currently, it is not compatible. In the text, the [CentralReplicate] mentions because it is an alternative of RPF rather than the whole Active-Active mechanism. You know, RPF issue is a sub-issue of Active-Active. I think the last sentence should be removed to avoid confusion. > > Other Comments: > > The document uses "RPF Check" and "RPF check". Please pick one. > > In Section 4.1: s/RB3 announces {LAALP1, LAALP2, LAALP3, LAALP}/ > /RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}/ > > In Section 16.1: s/trill-frc7180bis/trill-rfc7180bis/ > > In Section 5.1: s/a distribution tree Tx/a distribution tree/ > -- The Tx is not referenced later, so it is not needed here > > In Section 5.1: s/Coordinated Multicast Trees (CMT)/ > /Coordinated Multicast Trees (CMT) [CMT]/ > > In Section 5.3: s/The idea of this check is to check the/ > /The idea of this check is to determine the/ > > In section 11: s/It is important that the VLAN membership of all/ > /The VLAN membership of all/ [MZ] Above replacement will be executed. Thanks. > > > Process Observation: > > This document contains a normative references to draft-ietf-trill-cmt and > draft-ietf-trill-rfc7180bis, both of which have been submitted to the IESG for > publication. An updated I-D is needed for draft-ietf-trill-cmt to progress. If > this document is approved now, it was wait in the RFC Editor queue for missing > references. Thanks, Mingui
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Sandra Murphy
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Russ Housley
- [Gen-art] Gen-ART Review of draft-ietf-trill-pseu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Steve Crocker
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Donald Eastlake
- Re: [Gen-art] Gen-ART Review of draft-ietf-trill-… Mingui Zhang
- [Gen-art] Gen-ART Review of draft-ietf-mpls-self-… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Ronald Bonica
- [Gen-art] Gen-ART Review of draft-ietf-lisp-impac… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-s… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Luigi Iannone
- Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-i… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… BRUNGARD, DEBORAH A
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-… Jari Arkko
- [Gen-art] Resolution on comments of draft-ietf-l2… Jiangyuanlong
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- Re: [Gen-art] Resolution on comments of draft-iet… Ben Campbell
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Resolution on comments of draft-iet… Sheng Jiang
- Re: [Gen-art] Resolution on comments of draft-iet… Jiangyuanlong
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… David C Lawrence
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Warren Kumari
- [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-eppext-tmc… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- Re: [Gen-art] Gen-ART Review of draft-ietf-eppext… Gustavo Lozano
- [Gen-art] Gen-ART Review of draft-ietf-rtcweb-aud… Russ Housley