Re: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

Mingui Zhang <zhangmingui@huawei.com> Fri, 07 August 2015 06:48 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 2B6DF1B3753 for <trill@ietfa.amsl.com>; Thu, 6 Aug 2015 23:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 R-ZyGCORHS8A for <trill@ietfa.amsl.com>; Thu, 6 Aug 2015 23:48:42 -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 6DCD91B374F for <trill@ietf.org>; Thu, 6 Aug 2015 23:48:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVZ23640; Fri, 07 Aug 2015 06:48:40 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 7 Aug 2015 07:48:39 +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; Fri, 7 Aug 2015 14:48:35 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: gayle noble <windy_1@skyhighway.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)
Thread-Index: AdDOu0A8fk+YtNsfRi+PLCIgVt1xcQBkezEAACPnQ2A=
Date: Fri, 07 Aug 2015 06:48:34 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E787174852@nkgeml512-mbx.china.huawei.com>
References: <023401d0cebb$533d8010$f9b88030$@ndzh.com> <201508062138.t76LcXW6096520@skyhighway.com>
In-Reply-To: <201508062138.t76LcXW6096520@skyhighway.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: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E787174852nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/T-aCa-tQVQIQWGhaT1mm1CvI0Tc>
Subject: Re: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)
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, 07 Aug 2015 06:48:44 -0000

Hi Gayle,

Appreciate the review! These comments will surely be incorporated when the draft is updated.

Thanks,
Mingui

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of gayle noble
Sent: Friday, August 07, 2015 5:38 AM
To: trill@ietf.org
Subject: Re: [trill] draft-zhang-trill-multi-level-single-nickname - WG Adoption Call extension (7/16 to 8/16/2015)

I support this draft for adoption.
I do have the following suggestions and corrections

These are the acronyms used but not defined
APPsub-TLV  Application sub-TLV
E-L1FS         Extended Level 1 Flooding Scope [RFC7356]
E-L2FS  Extended Level 2 Flooding Scope [RFC7356]
FGL            Fine Grained Label [RFC7172]
FS-LSP         Flooding Scoped Link State PDU [RFC7356]
PDU             Protocol Data Unit
TLV             Type Length Value

corrections

1.   page 5 section 3.2 - first paragraph - first sentence
[Both L1 and L2 are areas so "each L1 area and L2" reads a bit weird.]
(as written)
Distribution trees for flooding of multi-destination packets are calculated separately within each L1 area and L2.
(I'd write)
Distribution trees for flooding of multi-destination packets are calculated separately within each L1 and L2 area.

2.   page 9 second paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if this packet is originated from an area out of the connected areas, RB1 should replicate this packet and flood it on the proper Level 1 trees of all the areas in which it acts as the DBRB.
(I'd write)
if this packet originated from an area out of the connected areas, RB1 should replicate this packet and flood it on the proper Level 1 trees of all the areas in which it acts as the DBRB.

3.   page nine third paragraph - first sentence
["packet is originated" is weird wording. I don't think "is" is needed.]
(as written)
if the packet is originated from one of the connected areas, RB1 should replicate the packet it receives from the Level 1 tree and flood it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface).
(I'd write)
if the packet originated from one of the connected areas, RB1 should replicate the packet it receives from the Level 1 tree and flood it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface).


4.   page 9 fourth paragraph - third sentence
["can well appear" would read smoother as "can appear"]
(as written)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as area border RBridges but they can well appear in an L1 area acting as non-area-border RBridges.
(I'd write)
RBridges that do not support either E-L1FS or E-L2FS cannot serve as area border RBridges but they can appear in an L1 area acting as non-area-border RBridges.

5.   page 11 second paragraph - third sentence
["will finally flooded" should be "will finally be flooded"]
(as written)
This packet will finally flooded to RB77 via RB30.
(should be)
This packet will finally be flooded to RB77 via RB30.