Re: [Idr] Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)

Nick Hilliard <> Wed, 04 January 2017 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89B01129594; Wed, 4 Jan 2017 07:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id biosfYQqn_ss; Wed, 4 Jan 2017 07:29:56 -0800 (PST)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BEEC129592; Wed, 4 Jan 2017 07:29:56 -0800 (PST)
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v04FTld1074958 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2017 15:29:47 GMT (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
Message-ID: <>
Date: Wed, 04 Jan 2017 15:29:46 +0000
From: Nick Hilliard <>
User-Agent: Postbox 5.0.9 (Macintosh/20161202)
MIME-Version: 1.0
To: Benoit Claise <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,,,, The IESG <>
Subject: Re: [Idr] Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)
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: Wed, 04 Jan 2017 15:29:57 -0000

Hi Benoit,

thanks for your comments.  This issue was brought up on idr@ on a couple
of occasions.  We deliberately didn't include text on the issue for
several reasons, one of them being the text in rfc6793 that you noted
below; two others were listed here:


With regard to implementation, there have been no queries raised by any
code authors about this part of the spec, and we haven't come across any
reports about incompatibilities between any of the existing implementations.

If there had been any ambiguity here, it would have been specified
explicitly, but there isn't.


Benoit Claise wrote:
> I see from the abstract: "The attribute is suitable for use with
> four-octet ASNs."
> I also see this text, which doesn't mention four-octet ASNs
>   The Global Administrator field is intended to allow different 
>   Autonomous Systems to define BGP Large Communities without 
>   collision. This field SHOULD be an Autonomous System Number (ASN), in
>   which case the Local Data Parts are to be interpreted as defined by
>   the owner of the ASN. The use of Reserved ASNs (0 [RFC7607], 65535
>   and 4294967295 [RFC7300]) is NOT RECOMMENDED.
> What if the ASN is two bytes, we use padding? How?
> Even if we would say: "This field SHOULD be an four-octet Autonomous
> System Number (ASN)", it doesn't preclude inserting a two-octet ASN in
> the Global Administrator field.
> Isn't it better to specify how? 
>>From RFC 6793:
>    Currently assigned two-octet AS numbers are converted into four-octet
>    AS numbers by setting the two high-order octets of the four-octet
>    field to zero.  Such a four-octet AS number is said to be mappable to
>    a two-octet AS number.