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

David Farmer <farmer@umn.edu> Fri, 04 November 2016 20:39 UTC

Return-Path: <farmer@umn.edu>
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 C05C81295D6 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 13:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level:
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 WEmD8WbDcewH for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 13:39:53 -0700 (PDT)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 8453F12958D for <idr@ietf.org>; Fri, 4 Nov 2016 13:39:53 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 0353B602 for <idr@ietf.org>; Fri, 4 Nov 2016 20:39:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inuxZ62EVzac for <idr@ietf.org>; Fri, 4 Nov 2016 15:39:52 -0500 (CDT)
Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id B7BF69E0 for <idr@ietf.org>; Fri, 4 Nov 2016 15:39:52 -0500 (CDT)
Received: by mail-qt0-f197.google.com with SMTP id n6so43442073qtd.4 for <idr@ietf.org>; Fri, 04 Nov 2016 13:39:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=Ksue/p9kEs0xA+kCR3E88hNpBIIdUgkSDQ0Mxi6ANJOhCJSpAHv75byPooc3dOpW1O wx+ZxUrDOh0edt0vvK8pgIFFflKKWSx0L1gxouQ64SdbJ+HQ9j3Vh1anrfAWr+3AMSOI XoLcC+5XHydmOpfqBTws5h0hbuG1XGuqHmOhLJ1y3wdWcN9Wb849MxaDAK36WVsKWs6t r70uHU5YOidusSOvXFkfj17/gNA72NAV4vm9SFRVsT12f+8Zv63Dc2cFTcMmhZ44y01H 783efYyphwUxZcEgqosvh03oxNb0TL9At13nJEmGZXqMkLJH3+VYs7PG8P5kAa85eJyz 7FoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g1BJG/G7Ur4Wvcce2dzsDypyupQiwihgl93eow69aaA=; b=PlZF8iFqAacCuZyhSNnSlmbMmizCgKuyG5UnP+9tn1nGKI1uBNR0HyJIYgGWSI9Xkr VAmg+v94MFcD5mMbbMZlwF5845zg7ZqYNxvTZnPvQ8dqnoESSPocZdbhaD5pOLnZdW+Q uTp5cz2w1s7u//Og0A/llY6bkIUQZbViJv6+uFVLqdHBuEjlkX9rnNjTy9GHBlCb4ScJ 0Q0MfWPqt4XUgCdsktLAohtE0snD0yo/eUjnD637Yhhs2wjUgszBzeJg6CHg/Wqr0KOH ZWUe4PL59LJsj0jzpPSOBW5ofUYl0GALsFi249Hncn5xU8rd0YyW+jGJ/vtEGT2HCaLy m5PQ==
X-Gm-Message-State: ABUngvfzW2w4b4aDwNGCAJv2Z3kCs9DRYbCQKgE7UMSdM778CFBB/8DcEsQELJ0EYmWFHzTTNAPAgtVvVVN1za3FcD1qjG/NwqzHFTwr3bAHKQ3uzREGduL1EYEZBGJKF9eXgKwGUBZcWJJgjQ==
X-Received: by 10.55.91.193 with SMTP id p184mr6655975qkb.301.1478291992179; Fri, 04 Nov 2016 13:39:52 -0700 (PDT)
X-Received: by 10.55.91.193 with SMTP id p184mr6655961qkb.301.1478291991988; Fri, 04 Nov 2016 13:39:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.253 with HTTP; Fri, 4 Nov 2016 13:39:51 -0700 (PDT)
In-Reply-To: <20161104171834.GE961@Vurt.local>
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>
From: David Farmer <farmer@umn.edu>
Date: Fri, 04 Nov 2016 15:39:51 -0500
Message-ID: <CAN-Dau0=RyuhWk7HdCgUgqCy2O8OccjC1VSHh2WcdVD1t5RstA@mail.gmail.com>
To: Job Snijders <job@ntt.net>
Content-Type: multipart/alternative; boundary="001a114e2cf60ea45b05407fadfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yYTN07NzuwiJSXJCin0o4U0LJqE>
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 20:39:56 -0000

On Fri, Nov 4, 2016 at 12:18 PM, 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).
> """
>

I won't try to speak for Geoff, but it doesn't do it for me.

I think we should just say what you've said previously as a summary of the
intent, but use normative language.

I'd propose something like the following.

4.  Canonical Representation

   The canonical representation for Large BGP Communities is three separate
unsigned
   integers in decimal notation separated by colons in the following order:
Global
   Administrator, Local Data 1, Local Data 2.  For example:
64496:4294967295:2,
   64496:0:0,  or 64496:111:222

   Implementations SHOULD use the above canonical representation,
especially when
   representing a Large BGP Community for output.   Implementations MAY use
other
   delimiters than colons, especially for compatibility with a
configuration syntax.  However,
   Large BGP Communities MUST be represented as three separate unsigned
integers
   in decimal notation, regardless of the delimiters used. Further, the
numbers MUST NOT contain
   leading zeros, and a zero value MUST be represented with a single zero.







-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================