Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)

"Zhangmingui (Martin)" <zhangmingui@huawei.com> Sat, 08 July 2017 05:56 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 E515A12896F; Fri, 7 Jul 2017 22:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level:
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[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] 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 0mZkavtUN5Nq; Fri, 7 Jul 2017 22:56:58 -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 5B01612783A; Fri, 7 Jul 2017 22:56:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQQ27984; Sat, 08 Jul 2017 05:56:54 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Jul 2017 06:56:53 +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; Sat, 8 Jul 2017 13:56:48 +0800
From: "Zhangmingui (Martin)" <zhangmingui@huawei.com>
To: Alvaro Retana <aretana@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-trill-mtu-negotiation@ietf.org" <draft-ietf-trill-mtu-negotiation@ietf.org>, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)
Thread-Index: AQHS9WDydUM3ICjtaESynIclWhvByqJJH94E
Date: Sat, 08 Jul 2017 05:56:48 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7A6546EE6@NKGEML515-MBX.china.huawei.com>
References: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com>
In-Reply-To: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.108.158]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59607427.004D, 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: 9ad46b9b84e80f9f42f3a363bd1428ad
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/B4DTYU06sg-gp2sud6ip2y81FBA>
Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)
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: Sat, 08 Jul 2017 05:57:00 -0000

Hi Alvaro,

Thanks for your comments. Please see inline below.

________________________________________
From: Alvaro Retana [aretana@cisco.com]
Sent: Wednesday, July 05, 2017 15:33
To: The IESG
Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; shares@ndzh.com; trill@ietf.org
Subject: Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-mtu-negotiation-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Are there implementations of this optimization?  Have they shown the expected
improvements?  The mechanism seems ok, but the introductory text made we
wonder, specially the part about "*potentially* improving the efficiency of
link utilization and speeding link state convergence."  IOW, if the advantages
are not really know, then maybe a Standards Track document is premature.  I
really don't have a strong opinion, so I'm just wondering at this point.

[Mingui] Only if Lz is larger than Sz, link-scoped PDUs can be formatted greater than Sz. Otherwise, efficiency remains the same. That is why the document indicate "potentially". 


Some nits:

1. There are some places where rfc2119 language is used that I think is out of
place because it is really just stating a fact or quoting what different
documents say (without actually using quotations); IOW, these are really not
normative statements defined in this document:

- "[RFC6325] describes the way RBridges agree on the campus-wide minimum
acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..."

- "As specified in [RFC8139], RBridges MUST support..."

- "as required by [RFC7780], all RBridges MUST..."

[Mingui] Got it. The RFC2119 language has been removed for those occurrences.

2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize
APPsub-TLV occurring in any other fragment MUST be ignored. An
originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored.
"

[Mingui] One of them has been dropped.


Thanks,
Mingui