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

I for one support this initiative, as this problem has existed for far 
too long without resolution, and actually does have material real world 
impact for networks utilizing 4-byte ASN's.  I also like the simplistic 
approach which not only provides a solution for the root issue, but 
should make it significantly easier for the applicable vendors to 
support such a change on their respective platforms.

Adam Davenport / adam.davenport@gtt.net
Director, Interconnection Strategy
GTT Communications / www.gtt.net

On 9/6/16 7:39 AM, Job Snijders wrote:
> 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