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

Job Snijders <> Thu, 20 October 2016 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C5B51294E2 for <>; Thu, 20 Oct 2016 09:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7nOLcskxqo_O for <>; Thu, 20 Oct 2016 09:01:46 -0700 (PDT)
Received: from ( [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1743129474 for <>; Thu, 20 Oct 2016 09:01:45 -0700 (PDT)
Received: by with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1bxFmp-000D8z-Gx (; Thu, 20 Oct 2016 16:01:44 +0000
Date: Thu, 20 Oct 2016 11:01:37 -0500
From: Job Snijders <>
To: Brian Dickson <>
Message-ID: <20161020160137.GV1033@Vurt.local>
References: <01f301d228b4$e3319ef0$a994dcd0$> <> <> <20161018191521.GT95811@Vurt.local> <> <007201d229f6$b4ae9680$> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <>
Cc: IETF IDR WG <>, Sue Hares <>
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: Thu, 20 Oct 2016 16:01:48 -0000

Dear Brian,

Thank you for your time and detailed review. I'll go over the concerns
one by one.

On Wed, Oct 19, 2016 at 12:46:27PM -0700, Brian Dickson wrote:
> 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.)

We've discussed this separately in the thread. The reality is that it is
a 32-bit field, and it is not possible with today's standards to enforce
any semantics on the contents of that 32-bit field. However, operators
have a rich experience in scrubbing bgp communities and sanitizing the

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

This strikes me as superfluous. The current text accomodates this
practise. But to be honest I expect the practise to die out. Given the
spaciousness of Large BGP Communities, I doubt we'll see a lot of
private ASN usage in the global administrator field because there is no
need to do so anymore. 

I'm making a note for the "Usage" document, where we can maybe describe
that if private ASNs are used in the Global Administrator field the
the propagationi characteristics might differ from globally unique ASNs.

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

All ASNs are 32-bit values as per 4893/6793 etc. I'm sorry to say, but
the added sentences are redundant. "any value" is a the superset of the
things you mention. 

Kind regards,