IETF Logo Mail Archive

[Idr] Request to adopt draft-heitz-idr-large-community

Job Snijders <job@ntt.net> Tue, 06 September 2016 11:43 UTC

Return-Path: <job@ntt.net>
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 E419B12B418 for <idr@ietfa.amsl.com>; Tue, 6 Sep 2016 04:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.443
X-Spam-Level:
X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 LwAFrCUFNGek for <idr@ietfa.amsl.com>; Tue, 6 Sep 2016 04:43:55 -0700 (PDT)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 6C1C412B528 for <idr@ietf.org>; Tue, 6 Sep 2016 04:39:24 -0700 (PDT)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1bhEio-00040U-Re (job@us.ntt.net); Tue, 06 Sep 2016 11:39:24 +0000
Date: Tue, 06 Sep 2016 13:39:19 +0200
From: Job Snijders <job@ntt.net>
To: idr@ietf.org
Message-ID: <20160906113919.GC17613@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vEa3744YRl5Sj8bUB_I54Uay-fE>
Subject: [Idr] Request to adopt draft-heitz-idr-large-community
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: Tue, 06 Sep 2016 11:43:57 -0000

Dear IDR, fellow network operators,

I would like to request that the IDR Working Group adopts
draft-heitz-idr-large-community [1] as a working group document.

Background
----------
RFC1997 BGP communities are the most common method to signal
meta-information between autonomous systems. RFC1997 communities are a
32 bit entity. The convention is that the first 16 bits are the ASN in
which the last 16 bits have a meaning. RFC1997 is so popular because of
its elegant simplicity and ubiquitous support.

The operator community (no pun intended!) is suffering from a fatal
flaw. One in five ASNs in the Default-free zone are a 4-byte ASN (RFC
4893). One cannot fit a 32-bit value into a 16-bit field.

4-byte ASN Operators work around this issue by either resorting to
kludges such as using private 16-bit ASNs as in the "Global
Administrator" field, or by returning the ASN to their respective RIR
and requesting a 16-bit ASN. However, both the RIRs and the IANA have
depleted their supply of 16-bit ASNs.

Work to address the issue of BGP communities has been ongoing for years.
Notable examples are 'flexible communities' (12 years ago) and 'wide
communities' (6 years ago). The WG so far has been unable to produce an
internet standard which enjoys a status similar to RFC1997. Now that the
RIRs are running out, the issue has become a matter of extreme urgency.

The Large BGP Community specification gives every network operator
(regardless of whether they have a 2-byte ASN or a 4-byte ASN) 8 bytes
to signal meta-information in an opaque fashion. This will align with
current, well-established practices deployed by network operators.

The Large BGP Community has purposefully been specified to be narrow and
as simple as possible to meet the operator community immediate needs,
without dissuading from existing community extensions that are in the
standards process pipeline.

The Large Community, by design, is not extendable, because extensibility
comes at a cost. Knowing that the amount of noise generated by an idea
is inversely proportional to the complexity of the idea, I urge the WG
to consider the Large Community's simplicity not a disadvantage, but a
virtue.

We ask for your support in this narrow focus to re-imagine the RFC1997
communities in this way as it should have been done when RFC4893 was
published.

Kind regards,

Job Snijders
(co-author draft-heitz-idr-large-community)

[1]: https://tools.ietf.org/html/draft-heitz-idr-large-community

v2.23.0 | Report a Bug | By Email