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