[Idr] Review of draft-ietf-large-community-06

Mach Chen <mach.chen@huawei.com> Tue, 08 November 2016 06:23 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511C1129A59 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 22:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Level:
X-Spam-Status: No, score=-5.718 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=-1.497, 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 NDjetJgkekJN for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 22:23:08 -0800 (PST)
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 EDC001294A6 for <idr@ietf.org>; Mon, 7 Nov 2016 22:23:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZX29055; Tue, 08 Nov 2016 06:23:04 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Nov 2016 06:23:02 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 8 Nov 2016 14:22:54 +0800
From: Mach Chen <mach.chen@huawei.com>
To: IETF IDR WG <idr@ietf.org>
Thread-Topic: Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7w==
Date: Tue, 08 Nov 2016 06:22:54 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
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.0A090202.58216F49.0021, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1174214b812387ac53bd14a5b3e5450b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/il174ETuCEEqk3fU2-6XntA9xIg>
Subject: [Idr] Review of draft-ietf-large-community-06
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 06:23:10 -0000

Hi, 

I have review the latest version(06) of this document. The draft is well written and is basically ready for publication. I have some minor comments as bellows:

1. 

Section 2, the first sentence:
"This document creates the Large BGP Communities attribute as an..."

Although RFC1997 also uses "creates", I'd suggest to use "defines" here, it also aligns with the convention of most of the RFCs.


2.
Section 2, the last sentence:
"A receiving speaker SHOULD silently remove duplicate Large BGP
   Communities from a BGP UPDATE message."

IMHO, whether remove the duplicate communities from a BGP UPDATE message is not significant, since the life of the message is over once the message processed. The key point is that the receiving speaker should ignore the duplicate Large BGP Communities. 

How about:

"A receiving speaker SHOULD silently ignore the duplicate Large BGP
   Communities within a Large BGP Communities attribute. "

3.

In Section 5 says:
   "Operators SHOULD NOT use these Global Administrator
   values."

Later, in Section 6:
"The Large BGP Communities Global Administrator field may contain any
   value, and a Large BGP Communities attribute MUST NOT be considered
   malformed if the Global Administrator field contains an unallocated,
   unassigned or reserved ASN or is set to one of the reserved Large BGP
   Community values defined in Section 5."

The "SHOULD NOT", "may contain any value" and "MUST NOT" seems little bit confusion and self-contradiction. Since the first sentence is not a specification to the Large BGP Communities attribute, but just a recommendation to the Operators.

How about changing it as:

"It is recommended that operators do not use these Global Administrator values." 

Or using some other similar text.

Hope this comments helps!


Best regards,
Mach