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

Brian Dickson <> Tue, 25 October 2016 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78D5B1299B5 for <>; Tue, 25 Oct 2016 12:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 25arlhC-FixZ for <>; Tue, 25 Oct 2016 12:41:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 507D01299AC for <>; Tue, 25 Oct 2016 12:41:53 -0700 (PDT)
Received: by with SMTP id c78so43521850wme.0 for <>; Tue, 25 Oct 2016 12:41:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PfygExtnOg1ymSVAvQnxkpPR1x2GYas0oOCAcFS4DbM=; b=gXvq7oD2C5GcK4DYpguT+YPq/dj1dmTUZJJczFz3mPXsOBnFRMi/7zjihPWLZ1r3pw /MdFPMWTy8BV7sQykKMOMW3d08V79oVtw+t4XK8gM4Jl0EW1DA9Fe7s8kUBWfnpcJRgX pKwnFW41w4QzI2gOb3PAcUeUXM3mPM9C3UzPVBZZyWo3bPIClqnvaQJeY62ahNe2G0kX VCsF2qm+45ailGZyKK773mcvzODHWrFFpjpGqQSXcFDEMqMx0nnvfBogIqjgK7RkIXaP JDR5kuikIWELeYRGZ5OZy3mMHk5KefjUNTZKISPhks6aCjDMyhZVRW5wG2/PFnoeu6ql SYFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PfygExtnOg1ymSVAvQnxkpPR1x2GYas0oOCAcFS4DbM=; b=LFpb8Y+yc01xCcXdZ0SH2yvNaQqKPvuW7JARo1hyM9mHHONbc53ZNLKGlhyxxqMkvO njPlC/HxFNgXrGrlQTSC81MLeXrxLo6wJJPCMnD8mN5uWXCxXRHbat+WhRNEC8AUjlj2 ogU2ELERIQPePAT6RxyYQhaIUfEJEcYCNa+KySd+as+IFqgIPXpy1FAeSfVv2we+HhtP QLCY3QuI44aV2/ZEJSNWI1406KkjJwSN26qgcagBdNU19GAZW7T7SZGH5eb3AIzP15P1 idnpGz1GcyK1vEfZr3dqorFO5c/1xOU22IN9s+fFc9F21d9BAYJbyCxgvQ137kzYU6D0 2c1Q==
X-Gm-Message-State: ABUngvewYRDqB7TlQrOTkL3bJPqphIR1Isst8K6hZ1NpiRoIuYNr+SVHOzyrAUc64Ij3gXzxHDtIME892VSu7g==
X-Received: by with SMTP id ui4mr5325851wjb.92.1477424511476; Tue, 25 Oct 2016 12:41:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 25 Oct 2016 12:41:50 -0700 (PDT)
In-Reply-To: <>
References: <20161020215938.GE1074@Vurt.local> <> <> <> <> <> <> <> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <> <> <> <>
From: Brian Dickson <>
Date: Tue, 25 Oct 2016 12:41:50 -0700
Message-ID: <>
To: Nick Hilliard <>
Content-Type: multipart/alternative; boundary="089e0122840a306869053fb5b349"
Archived-At: <>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Oct 2016 19:41:55 -0000

On Tue, Oct 25, 2016 at 4:10 AM, Nick Hilliard <> wrote:

> Brian Dickson wrote:
> > I agree with the consensus sentiment, and only have suggestions for
> > making that sentiment clearer.
> >
> > I think some recent discussion here has helped identify the corner
> > cases/nuances, which I think can inform that wording.
> >
> > Here's a first cut at a suggested changes, and rationale:
> >
> > [Replace all instances of "Global Administrator" with "Global
> > Administrator ASN" and/or GA_ASN.]
> >
> > "Global Administrator ASN: a four-octet namespace identifier.  The
> > namespace is under exclusive control of the Global Administrator of
> > the ASN. There is no requirement that this namespace be used only
> > within this ASN."
> The sentiment in your suggestion is to harden the association between
> the term "Global Administrator" and "ASN".  This isn't making things
> clearer: it's proposing to change the meaning of what's currently in the
> draft, in a direction which has already been discussed.

Actually, no.

What I am proposing, is to make the document internally consistent.

The last paragraph of section 1 (Introduction) reads as follows:

To address these shortcomings, this document defines a Large BGP
   Communities attribute encoded as one or more twelve-octet values,
   each consisting of 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

 Making the field descriptions and wording in section 2 agree with this, is
the intent.

Since there has been no disagreement on the introduction, and in fact that
introduction was offered as proof that there was no need to change
the wording (to which I disagree), I was suggesting the changes that move
the general understanding conveyed in the introduction.

I have also asked if anyone can come up with a specific counter-example,
where a value
other than an ASN would be legitimately be used in the first 4 octets.

Is it the case that any ASN owner gets to exclusively define the LC for
their ASN?

If not, then this is not accurately documented in the proposed standard,
and it also
fails to achieve parity with RFC1997.

If it is the case (exclusive ASN->LC definitions), it would behoove us to
say so.

None of the above implies any need to enforce anything, on the part of

It does not need to be any stronger than making the definitions consistent
with the Introduction.
IMHO, that is what my wording accomplishes, and is the reason for proposing
wording changes.


P.S. In case it isn't clear:

ASN->Global Administrator is 1:1

Global Administrator -> ASN is 1:many (where "many" includes "1" as the
degenerate case).

Which GA_ASN value is actively used by GA, is entirely up to GA.

Who can use the LCs defined by GA is "anyone".

Whose LC announcements are honored by GA (and/or third parties) is up to GA
(or those third parties).

Example of hypothetical use case:
A group of GAs agree to define amongst themselves, a special-purpose LC.
In order to simplify the situation, they agree to use GA_ASN_1:X:Y as the
(X and Y are a single set of fixed values.)

This avoids replicating the same functionality with different values
and simplifies the operator's processing of the LC.

The LC may be common knowledge, but is likely only accepted by the ASNs
the group of GAs, when received from each other.

The LC is used by multiple ASNs, but is only defined by the owner of

So, the binding of "exclusive" is on "definition of LC value->semantic
but is not exclusive in the use by sending or receiving ASNs.

All of this detail is stuff that will (I expect) end up in the GROW

However, the IDR document needs to have support in its definitions, for
those nuances.

Simply weakening the definition to "SHOULD", IMHO places undue restrictions
on the intended
GROW document.

I have yet to see anyone give a single use case that requires "SHOULD"
rather than "MUST".