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

["Bertrand Duvivier (bduvivie)" <[e-mail]>]

Same for me, I do support adoption
Best Regards Bertrand Duvivier
https://www.youtube.com/playlist?list=PLcSD8Cbk0fFHTO4bnb3NC8pJka3_ZvoRY






On 06/09/16 16:04, "Acee Lindem (acee)" <[e-mail]> wrote:

>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
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr