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

Mach Chen <mach.chen@huawei.com> Wed, 09 November 2016 02:43 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 B65A1129496 for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 18:43:03 -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 yRqkc4jeDQCH for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 18:43:02 -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 97FAA128874 for <idr@ietf.org>; Tue, 8 Nov 2016 18:43:01 -0800 (PST)
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 CZZ47626; Wed, 09 Nov 2016 02:42:58 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Nov 2016 02:42:57 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Wed, 9 Nov 2016 10:42:51 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Job Snijders <job@instituut.net>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06
Thread-Index: AdI5iIlDv+X8FqL1SIqxamyskn+T7///zqcA//59h6A=
Date: Wed, 9 Nov 2016 02:42:51 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A5780@SZXEMA510-MBX.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com> <20161108112616.GD2473@Hanna.local>
In-Reply-To: <20161108112616.GD2473@Hanna.local>
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.0A020204.58228D33.00F0, 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: 78ca36416e9be1cb184ad998701ae391
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dYIgoRKJbzBNFKt2L7qtTjNefHE>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [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: Wed, 09 Nov 2016 02:43:03 -0000

Hi Job,

Thanks for your prompt response!

Please see replies inline...

> -----Original Message-----
> From: Job Snijders [mailto:job@instituut.net]
> Sent: Tuesday, November 08, 2016 7:26 PM
> To: Mach Chen
> Cc: IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
> 
> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> > 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.
> 
> Good suggestion, accepted.
> 
> > 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. "
> 
> After the latest round of review from Geoff Huston and Jakob Heitz the
> following text was produced.
> 
> The below text is queued to be in -07 of the draft, but -07 can't be posted yet as
> we are in the 'cutoff' period before the IETF meeting in Seoul.
> 
> """
> 	Duplicate BGP Large Community values SHOULD NOT be transmitted. A
> 	receiving speaker SHOULD silently remove duplicate BGP Large
> 	Community values from a BGP Large Community attribute.
> """
> 
> I think the above text aligns with your suggestion, right?

Yes, I am fine with the text.

> 
> > 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.
> 
> I don't see the contradiction, its text that gradually narrows down into specifics
> for specific audiences. The text in section 5 is for operators, the text in section
> 6 is for implementors and bgp developers.
> I don't think that removing the 2119 language will increase the clarity.

Although I am not fully convinced, I am OK to move the document forward and let's leave this to the picky IESG review :-)

Best regards,
Mach
> 
> > Hope this comments helps!
> 
> Very much appreciated!
> 
> Kind regards,
> 
> Job