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

Job Snijders <job@instituut.net> Tue, 08 November 2016 11:26 UTC

Return-Path: <job@instituut.net>
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 2E1401295D4 for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 03:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 1jlEr9EMac8k for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 03:26:20 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325BE1295A4 for <idr@ietf.org>; Tue, 8 Nov 2016 03:26:20 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id t79so232748576wmt.0 for <idr@ietf.org>; Tue, 08 Nov 2016 03:26:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ILFFQOT/zbyqQmj0lj9ehNvFQFg/KMWNe8n8NAaW1xE=; b=jzzCRcq+KkVPBhtAhBLUi6CUbAsjmk9mZgdIQADoXEFo4FoQ9xj30Un8Y8BFUUtb3T 7str0DvS/Z/KF4uhRjvIqR8CTmiTHkt/Bg6HkgvpGprICstJfaiUC4sO/HKABU5056Ot 3jfVjDFpXjyep+EfCCQYlNle+V14iVSq1fHBShQ1ywC0SOJmK22Mg52exVzdTDH63awU zBBsnc0k4H6HXVdr5FpUuDL7F/w1Z2Cys2s149kh44TteEHjzd5h1z4bCYji2e3HTvJG b7+PVmdU/DtiYMQOZb2mN1apqSJ6i1GlI2SZ0+/5Ui5X1tBOOkMLc+SffxF3XXGpGJ90 fYGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ILFFQOT/zbyqQmj0lj9ehNvFQFg/KMWNe8n8NAaW1xE=; b=iubWaxt3/UXFIhcghOVyQ9egkHSpzgO5MOLux/bidWiAln6dU90VKZjSw58TWIV+GB ATwdPYOk++f+7IpowJijJ3ETa2+O3CfqPPK65aeR1R+hfMNdkaFd4y65QTXvMJcET/XY ULbJH9AUNTFK3yBGtbYvpcbyWPYEObq7tx09j3hAMyfujBvxYpHUngYg81OtKG6svcQw U3cK6N47xDkddOJYNfHDVyvU8FsajdfokrDgroW9RCqe6BBzEnkHS3+LNrGGVWh3N2XZ arWqXHH81dRlxCT9rbO5Hbk0FNr6pX1oYTB68ylsV8AEihB3rTEJReSkMAhnsFj3TbDF 6HYg==
X-Gm-Message-State: ABUngvdQgUT2Tz2NfADHRvPsdtv2j96CrVUYEaOCxCemif49re7KDJF6EfzFh36uDx5WeA==
X-Received: by 10.28.97.139 with SMTP id v133mr15964609wmb.117.1478604378529; Tue, 08 Nov 2016 03:26:18 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:319f:c386:86c3:ad6a]) by smtp.gmail.com with ESMTPSA id o62sm469213wmg.12.2016.11.08.03.26.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 03:26:17 -0800 (PST)
Date: Tue, 08 Nov 2016 12:26:16 +0100
From: Job Snijders <job@instituut.net>
To: Mach Chen <mach.chen@huawei.com>
Message-ID: <20161108112616.GD2473@Hanna.local>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F2A4BDA@SZXEMA510-MBX.china.huawei.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ELIxs7qRSFCcnZltvvG7dJB4NAA>
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: Tue, 08 Nov 2016 11:26:22 -0000

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?

> 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.

> Hope this comments helps!

Very much appreciated!

Kind regards,

Job