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

["Jakob Heitz (jheitz)" <[e-mail]>]

I have no IPR, know of no IPR and have no intention of claiming any IPR.

Thanks,
Jakob.


> On Sep 6, 2016, at 12:56 PM, Susan Hares <[e-mail]> wrote:
> 
> 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:[e-mail]] On Behalf Of Job Snijders
> Sent: Tuesday, September 6, 2016 7:39 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr