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

Geoff Huston <gih@apnic.net> Fri, 04 November 2016 09:04 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 AAF9C12951F for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 02:04:54 -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=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 KS8YRhwUkeCH for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 02:04:53 -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 A2523129417 for <idr@ietf.org>; Fri, 4 Nov 2016 02:04:52 -0700 (PDT)
Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id bbdf8939-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 19:04:47 +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; Fri, 4 Nov 2016 19:04:48 +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: <288c77155de540adbdb60d8587b9f39b@XCH-ALN-014.cisco.com>
Date: Fri, 4 Nov 2016 20:04:47 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <E3FB42F7-507F-4F8D-9F52-70D39CDCDAC9@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>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wCzLx_HHbhlRbVCZch-3HOnudsc>
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 09:04:55 -0000

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