[ppml] Proposed Policy: 4-Byte AS Number Policy Proposal

[Geoff Huston]

At 08:34 AM 15/12/2005, Robert E.Seastrom wrote:

>Geoff Huston <gih at apnic.net> writes:
>
> > I went through a similar thought process and came to the conclusion that
> > the combination of Appletalk and BGP and AS numbers was going to be a rare
> > one out there in the field!
>
>That was an attempt to be funny whilst punchy from jet lag.
>
>On a more serious note, I think what you're suggesting is actually
>three separate proposals..


not really - I am trying to identify particular phases in transition and 
place reasonable milestone dates against each phase that generate some 
predictability for the industry to work to.


>The first proposal (start allocating 32 bit ASNs upon request), I'm
>all for, and the sooner the better.


As has already been noted it cannot be any sooner given the preconditions 
to get this undertaken.


>The second proposal (start allocating 32 bit ASNs by default), my
>problem is not with the body of the proposal so much as I take issue
>with the notion that we can set a date for it before we have some
>operational experience with proposal 1.  I would fully support this
>phase as part of an omnibus roll-up if it were altered to say "after
>no less than $MONTHS of operational experience with 32 bit ASNs, at
>the registry staff's discretion, $REGISTRY may change its operational
>procedures to issue 32 bit ASNs by default and only issue 16 bit ASNs
>upon special request." or words to that effect.

I had thought of this and thought that the notion of a fixed 24 month lead 
period of 32 bite AS numbers being available upon request was adequate in 
terms of vendor actions to deploy BGP code versions that supported this, 
and also to avoid having to place registry staff in the position of having 
to make calls relating to operational readiness. The date also implies that 
there should be a reasonable remaining pool of unallocated 16 bit AS 
Numbers (some 15,000) so that in this second phase the criteria for 16 bit 
AS numbers allocations upon request should be exactly that  - that the 
client has requested a 16 bit AS number. If we leave this second phase too 
late we will get into "allocation upon request as justified" and then head 
off into all kinds of justification criteria. I thought that by specifying 
the date we will have a better assurance that there will be an adequate 
pool of 16 bit AS numbers left that would be able to satisfy requests 
without providing any further justification and evaluation and assessment 
of the justification by registry staff.


>The third proposal (discontinue issuance of 16 bit ASNs), is one for
>which I don't see any compelling reason.  If we let them be available
>upon request indefinitely, they'll be requested with lower and lower
>frequency, until finally there are no more.  Beyond the notion to
>"save for a rainy day" (or maybe a router museum with CSC2s and
>Proteons and a BBN C30 speaking EGP on a VDH or X.25 interface),
>what's the motivation?


There is no proposal to discontinue issue of 16 bit ASNs. The proposal 
states that as of the third date the 32 bit AS number pool is treated as a 
single pool, and there is no further special treatment of 16 bit ASNs or 32 
bit ASNs. Its all just one big AS number pool as of the third date.


>Assuming that there's actually a good reason for the third propsal
>which I am not understanding, I would think it would be premature to
>propose such a policy change until the first and second proposals are
>solidly behind us and executed.

The third part of the proposal is in fact the removal of this temporary 
policy, because as of that date we are back to allocating AS numbers from a 
AS number pool - _precisely_ the same as today.

>My $0.02 on the notation: It's just a u_int32.  Write it that way.  It
>will be easy for humans to differentiate between old style and new
>style by the fact that the 32 bit ASNs are all bigger than 65535.


So are IP v4 addresses. The dotted quad IPv4 notation is a human use 
convenience. The splitting into two decimal numbers on the 16 bit position 
is also just a simple human use convenience.

thanks,

     Geoff