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

Support!

Regards,
Jeff

> On Sep 6, 2016, at 4:39 AM, Job Snijders <job@ntt.net> 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