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

["Acee Lindem (acee)" <[e-mail]>]

I support WG adoption.

On 9/6/16, 7:39 AM, "Idr on behalf of Job Snijders" <[e-mail]
on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr