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

Geoff Huston <gih@apnic.net> Fri, 04 November 2016 18:23 UTC

Return-Path: <gih@apnic.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 BE774129608 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 11:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.398
X-Spam-Level:
X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable 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 2tMC2B-JOO-A for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 11:23:04 -0700 (PDT)
Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6481295ED for <idr@ietf.org>; Fri, 4 Nov 2016 11:23:03 -0700 (PDT)
Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id b655b986-a2bb-11e6-b23e-005056b685e3; Sat, 05 Nov 2016 04:22:58 +1000 (AEST)
Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:23:00 +1000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <20161104171834.GE961@Vurt.local>
Date: Sat, 5 Nov 2016 05:22:59 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <4EAB2E28-E839-4007-9155-EE4B5AAD0997@apnic.net>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <C2DABF02-D3CB-4646-B869-FBCE5F05FDA1@apnic.net> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <CED07D95-A426-469C-85B4-DB2FBE52D14A@apnic.net> <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com> <E3FB42F7-507F-4F8D-9F52-70D39CDCDAC9@apnic.net> <20161104171834.GE961@Vurt.local>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6YkxyBkAqa9ayTNI1hNkpSO_XIY>
Cc: IETF IDR WG <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
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: Fri, 04 Nov 2016 18:23:07 -0000

> On 5 Nov. 2016, at 4:18 am, Job Snijders <job@ntt.net> wrote:
> 
> On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote:
>>>> 4.  Canonical Representation
>>>> 
>>>> I am confused here - this section used an example with TWO
>>>> canonical representations:
>>>> 
>>>>  "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)."
>>>> Conventionally, it's better to use a single canonical
>>>> representation, so the authors should pick either a colon-delimited
>>>> list, or a bracketed comma+space separated object.
>> 
>>> On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
>>> 
>>> To explain this one, it was originally "Textual Representation" and
>>> it was with colons only. Then we discovered that Bird uses commas as
>>> a separator. Since that does not degrade the utility, we allowed it.
>>> The real point is that it has to be exactly 3 positive decimal
>>> integers. If some implementations only offered hexadecimal or used 6
>>> int16's then it would become very difficult for ISPs to communicate
>>> community settings to customers.  I can change it to a single
>>> representation and detail the allowed deviations from it.
>> 
>> if you make a canonical a SHOULD not a MUST then you can permit
>> variation without breaking the standard.
>> 
>> So what you are saying is that the canonical representation of a
>> single Large Community value is three unsigned decimal integer values,
>> separated by a ‘:’ (colon) character, representing the value as a
>> triplet of unsigned 32-bit integer values. Implementations SHOULD
>> accept this representation as a valid form of representation of the
>> value of a Large Community.
> 
> It appears the word "canonical" is maybe triggering something. The key
> element is that its three separate values. Nobody cares whether it is a
> colon, comma or a hypen.
> 
> Does removing the word "canonical" address the raised remark?
> 
> """
> 4.  Representation
> 
>   Large BGP Communities MUST be represented as three separate unsigned
>   integers in decimal notation in the following order: Global
>   Administrator, Local Data 1, Local Data 2.  Numbers MUST NOT contain
>   leading zeros; a zero value MUST be represented with a single zero.
>   For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).
> “”
> 


change the MUST to a SHOULD and drop the example that contains two different delimiters (as the text is fully functional and the example provides no further information, but adds confusion).

I suspect that the second sentence is overly normative (!!)

If you simply said that: “The decimal notation does not use leading zeros, and a zero value is represented as a single ‘0’.” then I suspect that you are consistent with a SHOULD, and adequately convey the minimal intent you are aiming at here

 

regards,

  Geoff