Re: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05

"Zhangmingui (Martin)" <zhangmingui@huawei.com> Tue, 27 June 2017 08:07 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE1C12942F; Tue, 27 Jun 2017 01:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tykkvG6ZCu7n; Tue, 27 Jun 2017 01:07:02 -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 AC33212009C; Tue, 27 Jun 2017 01:07:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJG46933; Tue, 27 Jun 2017 08:06:59 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 09:06:58 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 27 Jun 2017 16:06:53 +0800
From: "Zhangmingui (Martin)" <zhangmingui@huawei.com>
To: Donald Eastlake <d3e3e3@gmail.com>, Brian Carpenter <brian.e.carpenter@gmail.com>
CC: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "draft-ietf-trill-mtu-negotiation.all@ietf.org" <draft-ietf-trill-mtu-negotiation.all@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-trill-mtu-negotiation-05
Thread-Index: AQHS7InVClNR32nha0euui7y5iJWUKI3hHSAgAC9CWA=
Date: Tue, 27 Jun 2017 08:06:53 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7A653E64C@NKGEML515-MBX.china.huawei.com>
References: <149826797586.7852.1637929087755767570@ietfa.amsl.com> <CAF4+nEHfdCVoLcoKO-occ++pC7QUY2AwbKM6iuLU-K1s=YCd3g@mail.gmail.com>
In-Reply-To: <CAF4+nEHfdCVoLcoKO-occ++pC7QUY2AwbKM6iuLU-K1s=YCd3g@mail.gmail.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59521223.0118, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8b6f24d469e6592969633280401ed865
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/cMAbVMcF4IDS7qa4xTtJtozvn5s>
Subject: Re: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Jun 2017 08:07:06 -0000

Hi Brian and Donald,

Thanks a lot for the comments. Please see the responses as inline below.

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: Tuesday, June 27, 2017 11:03 AM
> To: Brian Carpenter
> Cc: gen-art@ietf.org Review Team; draft-ietf-trill-mtu-negotiation.all@ietf.org;
> trill@ietf.org
> Subject: Re: Genart last call review of draft-ietf-trill-mtu-negotiation-05
> 
> Hi Brian,
> 
> Thanks for the comments. See below.
> 
> On Fri, Jun 23, 2017 at 9:32 PM, Brian Carpenter
> <brian.e.carpenter@gmail.com> wrote:
> > Reviewer: Brian Carpenter
> > Review result: Ready with Issues
> >
> > Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-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-mtu-negotiation-05.txt
> > Reviewer: Brian Carpenter
> > Review Date: 2017-06-24
> > IETF LC End Date: 2017-06-28
> > IESG Telechat date: 2017-07-06
> >
> > Summary: Ready with issues
> > --------
> >
> > Minor issues:
> > -------------
> >
> >> 2. Link-Wide TRILL MTU Size
> > ...
> >>   ...RBridges MUST support the Extended L1 Circuit-Scoped
> >>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
> >>   exchange their maximally supportable value of "Lz".
> >
> > Where does that value come from? Is it configured, derived from the
> > interface in some way, or discovered?
> 
> It's somewhat similar to the originatingL1LSPBufferSize which is talked about in
> Section 5 of RFC 7780, except that there is no reason to worry about
> coordinating across the TRILL campus. How about adding wording something
> like:
> 
>       The originatingSNPBufferSize for a port is the minimum of the following
> two quantities, but not less than 1470 bytes: (1) the maximum MTU of the port
> and (2) the maximum LSP size that the TRILL IS-IS implementation can handle,

[Mingui] OK.

> 
> >> 2.1. Operations
> >>
> >>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
> >>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
> >>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
> >>   is ignored.
> >
> > Is that really what you mean? I thought Lz was an optional extra. So I
> > think you mean:
> >
> > 2.1. Operations
> >
> >    Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
> >    in fragment zero of the RBridge's E-L1CS FS-LSP. An
> >    originatingSNPBufferSize APPsub-TLV occurring in any other fragment
> >    MUST be ignored.

[Mingui] OK.

> 
> Yes, the "MUST" was just in reference to being in fragment zero, not that it has
> to occur, so your wording seems better.
> 
> >> 3. Link MTU Size Testing
> > ...
> >>   Step 0:
> > ...
> >>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
> >>         upperBound is set to the link-wide Lz, linkMtuSize is set to
> >>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
> >>         fraction-rounded-up integer.).
> >
> > This is confusing. "linkMtuSize" was defined as a local variable.
> > But what is "Link MTU size"? Is that another local variable?
> > If so, how is it different from "linkMtuSize"?
> > It is used again in part 2) of step 2 below.
> 
> I don't want to say anything about that before checking with the primary
> author.

[Mingui] As specified in the text leading the Steps, "linkMtuSize" is a local integer variable for a specific RBridge while "link MTU size" is not a variable but a value that is agreed by two connected RBridges. To avoid the confusion, I changed "linkMtuSize" to "X" and add the text to explain that link MTU size is a value that is agreed by two connected RBridges.

> 
> > Also, I assume "Lz" is the value previously agreed among the nodes,
> > but that should be made clear to the reader.

[Mingui] Agree. Added the word "agreed" in Section 2.

> >
> > Nits:
> > -----
> >
> >> 1. Introduction
> > ...
> >>   topology. While in this document, a new RECOMMENDED link-wide
> minimum
> >>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
> >>   as specified herein, link-scoped PDUs can be formatted greater than
> >>   the campus-wide Sz up to the link-wide minimum acceptable inter-
> >>   RBridge MTU size potentially improving the efficiency of link
> >>   utilization and speeding link state convergence.
> >
> > I cannot parse those two sentences. What does the "While" refer to?
> > What does "By calculating a using Lz" mean?
> 
> I believe the sentences should be
> 
> "... In this document, a new RECOMMENDED link-wide minimum inter-RBridge
> MTU size, Lz, is specified. By calculating and using Lz as specified herein, ..."

[Mingui] OK.

> 
> >> 3. Link MTU Size Testing
> > ...
> >>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
> >>         upperBound is set to the link-wide Lz, linkMtuSize is set to
> >>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
> >>         fraction-rounded-up integer.).
> >
> > This would be easier to understand:
> >
> > 3. Link MTU Size Testing
> > ...
> >       b) Link MTU size is set to 1470, lowerBound is set to 1470,
> >          upperBound is set to the link-wide Lz, linkMtuSize is set to
> >          [(lowerBound + upperBound)/2], rounded up to the nearest
> integer.
> 
> OK.
> 
> > Repeat this in the following two cases; a normal reader will not
> > remember the rounding rule:

[Mingui] Changed three occurrences in the document.


> >
> > ...
> >    1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
> >
> >          upperBound is set to linkMtuSize and linkMtuSize is set to
> >          [(lowerBound + upperBound)/2], rounded up to the nearest
> integer.
> >
> >    2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
> >       RB2:
> >
> >          link MTU size is set to linkMtuSize, lowerBound is set to
> >          linkMtuSize and linkMtuSize is set to [(lowerBound +
> >          upperBound)/2], rounded up to the nearest integer.
> 
> That seems reasonable.
> 
> > --
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com



Thanks,
Mingui