IETF Logo Mail Archive

Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

"Susan Hares" <shares@ndzh.com> Tue, 06 September 2016 16:56 UTC

Return-Path: <shares@ndzh.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 D829612B3FB for <idr@ietfa.amsl.com>; Tue, 6 Sep 2016 09:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 fdcS5wipaNkG for <idr@ietfa.amsl.com>; Tue, 6 Sep 2016 09:56:15 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 877CB12B3EC for <idr@ietf.org>; Tue, 6 Sep 2016 09:56:12 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.155;
From: Susan Hares <shares@ndzh.com>
To: 'Job Snijders' <job@ntt.net>, idr@ietf.org
Date: Tue, 06 Sep 2016 12:54:59 -0400
Message-ID: <01ab01d2085f$67c6e8d0$3754ba70$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdIIXx8kYqc7BdVrTmq7GfG1a3fUeA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/c1ln_sITvtUONhSLhdQ2To8JKh8>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)
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 16:56:17 -0000

Job:

We'd be glad to start a WG adoption poll starting today (9/6 to 9/20).  

The Authors should indicate if they have IPR or know of any IPR.   If the
authors indicate IPR within 1-2 days, we'll let the poll continue.  If not,
we'll halt this adoption poll to await the authors response. 

Thank you, 

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders
Sent: Tuesday, September 6, 2016 7:39 AM
To: idr@ietf.org
Subject: [Idr] Request to adopt draft-heitz-idr-large-community

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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email