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

[Owen DeLong]

You don’t actually need 32:32. You really only need 32:16 since what is really needed
is ASN:action rather than ASN:ASN.

There are plenty of possible ways to address 32:16 described in RFC4360 and several that
I can think of relatively easily if one goes beyond 4360 and defines an additional extended
community type.

Extended communities are 64 bit attributes which reserve 16 bits for describing the contents
of the remaining 48 bits.

It is, in fact, possible to define a type where only 8 bits are used to describe the contents
of the remaining 56 bits.

So, until we get into the past 16.7 million of the 32-bit ASNs, you could, actually, have the
equivalent functionality of 32:32 using an 8 bit type to indicate that the remaining bits
contain two 32-bit where the first 8 bits of the first ASN are assumed to be 0.

Owen


> On Mar 31, 2016, at 11:43 , Job Snijders <job at ntt.net> wrote:
> 
> On Thu, Mar 31, 2016 at 10:49:30AM -0700, Owen DeLong wrote:
>> 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.
> 
> Can you recommend a specific Extended Community Type and Subtype for
> this purpose? Or maybe point me at a standard that defines something
> akin to "32bit:32bit"-style (64 bits in total), much like how many
> networks use "16bit:16bit" as I described?
> 
> It would also be helpful if you can point me at publicly-known
> deployments of such schemes based on Extended Communities.
> 
> Alternatively, we can accept that "the community thing" is not a red
> herring. Acknowledging the tangible difference between 16-bit and 32-bit
> ASNs should help the discussion at hand.
> 
> Kind regards,
> 
> Job