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

["John G. Scudder" <[e-mail]>]

Forwarding on behalf of Jens Ott.

--John

> Begin forwarded message:
> 
> From: Jens Ott - Opteamax GmbH <[e-mail]>
> Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community
> Date: September 19, 2016 at 1:48:32 PM EDT
> To: <[e-mail]>
> 
> Hi,
> 
> I subscribed to the idr list (and got confirmation). Then I tried sending this mail below but I get bounce I'd not be subscribed. I was told to ask you as chair of idr, if you could please forward it to the list on my behalf.
> 
> Thank you and kind regards
> Jens  
> 
> 
> I represent AS48200, a small German IP-Transit Provider. 
> 
> Several IXP route-servers are offering Do-Not-Announce communities in the format IXPASN:PEERASN. This works fine for route-server-peers with 16bit ASN, but it's no longer possible to set DNA for peers with 32bit ASN. Only choice for not being seen from our customers over the IXP is currently to not peer with the route-servers. 
> 
> Additionally we needed to implement a complex mapping for giving our customers the opportunity to prepend their prefixes to specific peers, which always requires long explanation to new customers. 
> 
> Therefore I highly support Job's request to adopt the draft.
> 
> Best regards 
> Jens Ott 
> 
> Am 6. September 2016 14:39:19 OESZ, schrieb Job Snijders <[e-mail]>:
>> 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
>> 
>> !DSPAM:1229,57dfd6a4170271841914067!
> 
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: [phone]
> Fax: [phone]
> Email: [e-mail]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: [phone]
> Fax: [phone]
> Email: [e-mail]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: [phone]
> Fax: [phone]
> Email: [e-mail]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989