[arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage

Mon May 7 00:27:17 EDT 2012

Hello Gentlemen,

I hope I am welcomed to chime in on the subject in a general manner with 
some thoughts for whatever they're worth.

Maybe I'm a day late and a dollar short, or even on the riding on the wrong 
bus as to your specific debate.

Relative to an Org being able to choose a specific ASN if they are aware of 
its availability, may I toss in a couple of comparisons in both directions?

I'll not comment on any technical aspects of backward compatibility, 
AS_Trans 23456, new & old interoperability with older equipment, etc.

I would agree that an Org may have valid have reasons for desiring a 
specific AS number, whether it be for aesthetics, superstition, or to 
provide a unified structure with any other numeric configurations they might 
have; or recovering a lost 4byte AS number for whatever reason.

Vanity ASN's like vanity license plates? Now that's a real seller. ASDOT 
looks nice--  ASPLAIN, just another bigger number.That may boil down to how 
your equipment wants it formatted.

We didn't get to pick IP nets for allocations, but if ARIN desires to 
bolster the issuance of 32 bit ASN's then allowing specific choices might 
help.

Sooner or later [sooner] the16 bit depletion aspect leaves no choice if an 
Org wants an ASN.

When starting up new telephone account or adding an extra line, you're 
generally given the choice to pick from a group of available phone numbers
in your area within reason.

If your street address numeral is all that important, then you could choose 
to buy one house over another.

The US Postal service along with the City actually renumbered the street I 
live on. It was done for unification and to eliminate duplicate and 
misaligned house numbers. I do not like the new number, but am stuck with a 
longer and undesirable house number. An overlay/transition period of a year, 
allowing
either house number to be was employed to alert necessary persons that the 
address has changed.

This can remotely be compared to network renumbering via IP or AS.
With a US Postal street-renumbering there is a finite period before mail 
showing the old house number would be returned to sender. Any comparison to 
Internet routing?

After the overlay period, NO backward compatibility existed, so to extend 
the finite cutover date for ourselves, we used both the new house number and 
the old one in parentheses. However this is not the case as with AS 2 & 4 
byte but it makes for an analogy.

If an Org's management desires certain combinations of numerals I would 
agree with a request for a specific 4byte AS number. Naturally a good
practice would be to allow returned (yeah) unneeded numbers an adequate 
cool-off period before re-issuance as a second-hand ASN may come with
skeletons in the closet. The quantity of 32 bit is so large that surrendered 
ones could cool off for a very long time. An exception would be in a 
recovering of a negligently or otherwise lost ASN.

On the other hand, and generally speaking it makes sense administratively to 
start at the beginning and work their way upward while issuing. That would
prevent the AS number inventory from being scattered all over the place. I 
would see an all out ASN-4 issuing-by-request as a potential administrative
nightmare for ARIN, with large unfilled issuance gaps. A mitigating idea for 
that may be as follows:

Summary:
I suppose my suggestion would be to allow requested specific ASN's within 
ranges as ARIN might open up a new range and requests could be made from 
that range only; until a new range was made available for issuing via 
sequential selection or by request. To keep honoring requested ASN's, gaps 
would still remain in each range. If ARIN's desire is to not maintain big 
gaps, (hence an administrative nightmare), then perhaps an additional 
component might be employed such as a premium fee for a requested number and 
a discounted fee for a random assignment. In the end the premiums and 
discounted may even out dollar-wise. If ARIN's stewardship is developing a 
commercial twist, then a request for a specific ASN from a not-yet opened 
range could even be accommodated for yet an extra premium. Since IPv6 and 
32bit ASN's have been phasing in around the same timeframe then it might 
even be considered to allow speific IP net allocations.

Conclusion: It would not be a terrible thing to issue a requested ASN 
provided the Org has a decent reason, and such a practice doesn't impose an 
administrative nightmare on ARIN.

Only Best Regards,
Drake Pallister

----- Original Message ----- 
From: "Joe Maimon" <jmaimon at chl.com>
To: "Owen DeLong" <owen at delong.com>
Cc: <arin-ppml at arin.net>
Sent: Thursday, May 03, 2012 4:28 PM
Subject: Re: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage

> Owen,
>
> Thanks for the excellent feedback. I suppose at this time I can wait and
> see if the AC wants to adopt the proposal and to work on it or if a
> rewrite is in order.
>
> I'll give it some thought.
>
> Joe
>
> Owen DeLong wrote:
>> On May 2, 2012, at 12:20 PM, Joe Maimon wrote:
>>
>>> Hey Owen,
>>>
>>> Owen DeLong wrote:
>>>> I could support this policy with the following changes:
>>>>
>>>> 5.2.2 Remove "AS Number or" from the first sentence.
>>>
>>> To clarify, you are objecting to language that would allow an org to
>>> request a specific AS from ARIN, assuming it knows it is available.
>>>
>>> Yes, this allows an org the chance to try and get an aesthetically or
>>> otherwise pleasing ASN they may not have otherwise.
>>>
>>> Whats the harm in that?
>>>
>> I'm generally opposed to putting ARIN in the "custom license plate"
>> business because I think there are other better higher priorities for
>> number resource management.
>>
>>> But if dropping it is all it would take to win public support, its an
>>> easy loss.
>>>
>> Don't know about that. Certainly dropping it is a requirement to garner
>> my support.
>>
>>>> 5.2.3 I don't understand what causes are being rectified, so, this
>>>> entire
>>>> paragraph does not yet make sense to me. I would appreciate
>>>> clarification
>>>> from the author.
>>>
>>> In the simplest case, it would allow ARIN to explain to the room at some
>>> future ppm why 4byte ASN utilization is so low, put the pages in the
>>> wiki, document and present to the community other potentially valid
>>> concerns, produce material that can be useful to parties involved in
>>> similar situations, etc...
>>>
>>> Yes, this may allow ARIN to operate a 4byte wall of shame.
>>>
>> I have no problem with policy enabling ARIN to operate a 4-octet wall of
>> shame. However, if that is the intent, let's have the paragraph say that.
>> I can't even parse what it says currently.
>>
>> I don't think ARIN knows why 4-octet ASN utilization is so low (in the
>> ARIN region and uniquely in the ARIN region, btw).
>>
>>>> 5.2.4 I would prefer to see a longer period.
>>> Anything from 12-48 months is fine with me, personally.
>>>
>>> However, consider that this restriction as written applies to both 8.2
>>> and 8.3 transfers.
>>>
>> I would modify to remove the restriction from 8.2 transfers and set the
>> limit at 48 months (if we're going to allow 8.3 transfers of ASNs at all
>> which I still feel is a bad idea).
>>
>>>> 5.2.5 I don't really see a purpose to this clause. I would delete it.
>>>
>>> An organization that wants to transfer an ASN, but cannot because 5.2.4
>>> applies to it, has the option to exchange the ASN for a 5.2.1 which has
>>> no such restriction, should they wish to avail themselves of it.
>>>
>>> I suppose some grace time for renumbering may not be a bad idea.
>>>
>> Ah, but if we eliminate 5.2.3 as I suggested, that becomes inoperative.
>>
>>>> 5.2.6 is a no-op. It should be removed.
>>>
>>> Its there to prevent ARIN staff from concluding that in order to
>>> implement 5.2.2 they need to publish an entire list of available ASNs,
>>> which they may reasonably do so without making it explicitly
>>> non-dependent.
>>>
>> Move that statement to the rational. It's an operational concern, not a
>> policy issue.
>>
>>>> 5.2.7 should also be removed. The policy can be retired by a proposal
>>>> that
>>>> achieves community consensus. There is no need for an auto-
>>>> expiry process that is optional at the discretion of staff.
>>>
>>> How much effort is expended on policy cleanup for unused sections?
>>>
>> A fair amount, actually. I don't think that there are many, if any unused
>> or obsolete sections currently in the NRPM and there have been several
>> proposals which have removed them just in my tenure so far on the AC (a
>> little more than 4 years) and many more in the decade+ that I have been
>> active in the policy process.
>>
>>> Without active interest, I dont expect such a proposal to ever show up,
>>> unless the ARIN staff solicits one for disuse. So in that case, let them
>>> just remove it at that point.
>>>
>> In the past, we have generally eschewed sunset clauses. As such, I don't
>> think having one in this policy is particularly more desirable than any
>> of the past cases where the community has opted not to put one in.
>>
>>> Also not a pivotal aspect of the proposal.
>>>
>>>
>>>> I don't believe this policy will do anything to achieve the objective
>>>> stated
>>>> in the title, however, perhaps that is because I cannot decipher 5.2.3.
>>>> If the author manages to sufficiently clarify 5.2.3 and/or modify the
>>>> policy
>>>> such that it would demonstrably achieve the titled objective, I would
>>>> support that objective.
>>>>
>>>> Otherwise, it just looks like an attempt to back-door ASN transfers
>>>> which
>>>> I oppose.
>>>>
>>>>
>>>> Owen
>>>
>>> The proposal was written with the expectation that directed ASN
>>> transfers are likely to be allowed via policy sometime soon, it is not
>>> intended to allow or disallow them on its own, except to add this
>>> additional restriction, applicable ONLY inasmuch as an ASN transfer is
>>> allowed, either via 8.2 currently or as 8.3 might be amended.
>>>
>> Then it should say that. The proposal for ASN transfers is
>> (unfortunately) in last call, but, it has not been recommended to the
>> board for adoption, let alone been adopted.
>>
>> Owen
>>
>>
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>