Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 19 October 2016 19:46 UTC

Return-Path: <brian.peter.dickson@gmail.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 81F16129559 for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 12:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KMOZBNqkQIkB for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 12:46:29 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 6501F1293E3 for <idr@ietf.org>; Wed, 19 Oct 2016 12:46:29 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id f128so52898769qkb.1 for <idr@ietf.org>; Wed, 19 Oct 2016 12:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+hqPofQHGT05M7KFlEekdw2LRBvLJEoM+X5ryHQFLik=; b=WhsbW1mqHrkS0rTNA+e4qXbNEUyjzXcmMmmrVriodvEz2PibE8jSYjnHqD4bpSLlrh hPR/Dhtc00MaO6TySKzeVXKsp2ZEQjTxg12QsolSla3ym9C+bj08h4MuNDixceDxLTkX yO2cEU9eMdP5R62+G/8aL9WuldN/LKKXVTwWUmVblwdKKVLHf3GBboUZ9Oss/3cLrX2M 30Gtd4c9x8rtKqY5dMz7NuT2+TfcDrJ+hqeVve34NF8b6l+l2FLbf4FXlBsCY4PR1tBZ YUaiy2FoE/C/7sbAY4Bi2bdKxNoFl+idwKqnCdwSwwWqWwR+enELwUGlKb6O8P9PtuDW K+6w==
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=+hqPofQHGT05M7KFlEekdw2LRBvLJEoM+X5ryHQFLik=; b=Wt0QmbZoZNlAbnl4wFei6PjZlPbMoqMBVLTFMWJuyxbVa5EWvPVOpa8V2TNFFvQdr3 GaFYopBaIFzYrqufzwKJ8nm2O4NewWruFG8KJAvNoELxitXEIyKXkGWPWHCA3VvV5BwW XmEcwaTVVxztnCzTCPYBRWEKFvNoTVhfbugPWkfIYtLRS7vtknEcXndS1hKub23/GjgZ WMKIQftXM5d+Qwg5e6E7XzoApRnXvVGOrx3gLEWtGgOzg7gWNdOG0RsUuvsxVsRx8mtn k5GNP2dmiwwzzoYvmDyRpq882gSuXZygTK14XM6EZ92meB56FqJCFr+pW+qg54lyGK+X iixw==
X-Gm-Message-State: AA6/9RnYlGDgRMLJ9jFRrViXCn7cxglE+XTbK7gUb0SwekhV4LGXf7sWsyCzYdrV9DAwdJAI/pcr2xClFBaHhQ==
X-Received: by 10.194.74.5 with SMTP id p5mr5988290wjv.92.1476906388382; Wed, 19 Oct 2016 12:46:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.203.207 with HTTP; Wed, 19 Oct 2016 12:46:27 -0700 (PDT)
In-Reply-To: <20161019185405.GA12214@puck.nether.net>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 19 Oct 2016 12:46:27 -0700
Message-ID: <CAH1iCirF_1ODLtLzeVhKmQPDeeGcczcQCSPXDcro=OQv2ipR3A@mail.gmail.com>
To: Jared Mauch <jared@puck.nether.net>
Content-Type: multipart/alternative; boundary=047d7bd9111aa569a4053f3d1011
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uCYj-VqKxX-PYx6TQoodr1uvds0>
Cc: IETF IDR WG <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
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, 19 Oct 2016 19:46:31 -0000

On Wed, Oct 19, 2016 at 11:54 AM, Jared Mauch <jared@puck.nether.net>; wrote:

> On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote:
> > I remain unhappy with this I-D.
> >
> > I find it ironic that the messages for this Last Call should be
> > interspersed with those relating to what goes wrong when someone
> > somewhere else in the world uses a field in an unexpected way.  This
> > reinforces my belief that this I-D should be more forceful in calling
> > out the dangers (eg MUST instead of SHOULD).
> >
> > I think that this I-D is factually incorrect, or at least open to
> > misinterpretation,  when it says
> > '[RFC1997] BGP Communities attributes are four-octet values split into
> >    two two-octet words.  The most significant word is usually
> >    interpreted as an Autonomous System Number (ASN) '
>
>         rfc1998: section 4 gives you the slice + dice bits:
>
> -- snip -- rfc 1998 --
>    To make use of the BGP community attribute, several community values
>    (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
>    by customers to tag routes so that the appropriate "LOCAL_PREF"
>    values are configured. Table 2 lists the appropriate community
>    attribute values (and the mappings of community to LOCAL_PREF):
> -- snip -- rfc 1998 --
>
>         This is the segmenting, and most customers have
> "ip bgp community new-format" configured.
>
>         If your issue is about printf %ull vs %d:%d:%d we operators
> can solve this by ensuring our vendors do the right thing, which
> we have already done 20 years ago via rfc1998.
>
>         This nit is imo not worth picking.
>
>
I think Tom was concerned about the usage of "usually", not the 16:16
format. I agree, and I am also concerned.

Per Susan Hare's WGLC instructions, here are my specific concerns, and
suggested text for correcting those concerns:

Concern #1:

>From my reading of RFC1997, and from a couple of decades of operational
experience,
I believe the wording in Section 1 should be as follows:

"The most significant word is always an ASN. Private ASN values MAY be used
when agreed upon by adjacent BGP peers."
(Insert reference to IANA private 32-bit ASN table.)

Rationale:

The second sentence was not explicitly part of RFC1997, but definitely has
been operational practice, and is implied by the meaning of ASN, and tables
of 16-bit ASN values (reserved, private, and available/assigned.)

Concern #2:

And, IMNSHO, the request/demand for parity with RFC1997, calls for similar
language when describing the 32-bit first field's interpretation:

In Section 2:

"Global Administrator:  A four-octet namespace identifier.  This MUST be an
Autonomous System Number. Private ASN values MAY be used when agreed upon
by adjacent BGP peers. Private ASN values SHOULD NOT be advertised to peers
where their use has not been agreed upon."

Rationale:

Trying to separate out the "best practice" into a separate,
non-Standards-Track document, significantly weakens the practical ability
BY OPERATORS to enforce the requirement of exclusive control of the
meanings assigned by them, of the number space within communities (regular
and wide).

The draft, as currently worded, gives third parties "wiggle room" to use
non-ASN values as the first 32-bit field. Their argument will be that this
document does not say "MUST", and for whatever choice of argument they
pick, they are justified in squatting on someone's ASN as the first 32-bit
value.

Since Section 1 of this document give exclusive semantic control of that
portion of the Large Community space -- " a four-octet ASN and two
four-octet operator-defined values, each of which can be used to denote
properties or actions significant to that ASN." -- squatting needs to be
explicitly prohibited via use of "MUST" instead of "SHOULD" in specifying
Global Administrator as meaning, exclusively, ASN.

Concern #3:

In addition, to address concerns the co-authors have expressed, the
non-intent of "MUST", to implementers, should be explicitly called out. The
proposed wording would be:
"The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.
   Implementations MUST allow the operator to specify any value for the
   Global Administrator field. Implementors MUST NOT restrict permitted
values
   of ASN, including non-reserved 16-bit ASN values and non-reserved 32-bit
ASN
   values, which includes all Private Use ASN ranges. Use of third-party
ASN values
   is an explicitly permitted use of Large Communities."

Rationale: Avoid any ambiguity for implementation of Large Communities.
Interoperation demands compatible interpretation of values of ASN permitted
by implementors.

Of course, if the above changes are adopted, I approve publication,
whole-heartedly.

Brian Dickson