[ARIN-consult] [ARIN-Suggestions] New Suggestion - ACSP 2016.4 - Waiting List for 2 Byte ASNs

Owen DeLong owen at delong.com
Thu Mar 31 13:49:30 EDT 2016


Your argument amounts to the convenience of the networks in question in that they
have not implemented (apparently) appropriate extended-community schemes to address
clients with 32-bit ASNs.

Owen

> On Mar 31, 2016, at 04:45 , Job Snijders <job at ntt.net> wrote:
> 
> On Wed, Mar 30, 2016 at 10:12:16PM -0700, Owen DeLong wrote:
>> Actually, the community thing is largely a red herring in lieu of
>> “convenience”.
>> 
>> There are perfectly valid ways to address the community functionality
>> desired using 4-byte ASNs.
> 
> This is news to me. Can you back this claim up by providing references
> to both the appropiate standardization and the publically known
> deployment of such standards?
> 
> Some of my own digging: If I look at NTT's BGP Community scheme at
> http://www.us.ntt.net/support/policy/routing.cfm#communities under the
> "Customers wanting to alter their route announcements to selected
> peers." section - you can easily conclude that 16-bit ASNs are
> first-class citizens, but 32-bit ASNs don't even fit the scheme. This
> pattern seems to be employed by other significant networks such as
> Level3 (http://onestep.net/communities/as3356/), GTT
> (http://onestep.net/communities/as3257/) or for example Comcast
> (http://onestep.net/communities/as7922/)
> 
> I won't pass value judgement on the design of these schemes, they are
> what they are. I want to stipulate that in my opinion the "community
> thing" is not a "red herring", but that there is a tangible difference
> between 16-bit and 32-bit ASNs in today's BGP landscape.
> 
> I think the waiting list idea is worth considering.
> 
> Kind regards,
> 
> Job




More information about the ARIN-consult mailing list