[address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)

Gert,

On 15/05/2015 13:34, Gert Doering wrote:
> Feedback for this proposal so far was, if I simplify a bit
> 
>  - we want to take care not to exhaust 16bit-ASNs
>  - there is unlimited number of 32bit ASNs
>     (but there *also* was feedback about "N. from I. could go out and
>     register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
> 
>  - we might want a garbage collection / reclamation mechanism
> 
>  - the current policy text is too complicate, arbitrary numbers are bad
> 
> but there *is* quite a bit of support for the generic idea of "loosen up
> the rules for 32bit ASNs, as the multihoming requirement is often hard
> or impossible to demonstrate or check".

I'm going to suggest taking a step back and looking at the problem from a
distance so that we can get a better view of how to approach it.

We have two generic categories of assignment policy in the RIPE region:
needs-based and entitlement-based.

- needs-based policies operate on the basis of a stated requirement of some
form, where this requirement undergoes some form of evaluation.

- entitlement-based assignment operates on the principal that if you
request a resource of some form within particular parameters, you will get
the resource with no requirement to justify it.  If you stray outside the
specified parameters, then one of two things happens: either a needs-based
policy will apply or the request will be denied by policy.

Needs-based policies have historically worked well for constrained
resources (ipv4 and ASNs).  On the other hand where a resource is abundant,
these policies can be cumbersome or unnecessary.

In terms of resource run-out, ASN16s will be gone sooner or later, pretty
much no matter what policy is put in place.  Conversely, the supply of
ASN32s is not constrained; nor is it likely to be in future.

We have an ASN transfer policy, which is good.

The questions relevant to creating a new policy for handling ASN
assignments are:

- would it be useful to implement an asn16 runout policy?

- outside that, is there a need to have separate policies for ASN16s and
ASN32s?

- for all these cases, would it be best to use needs-based policies,
entitlement-based policies or something else?

- if it's appropriate to put in a needs-based policy, can we define what
"need" is?  e.g. would it be useful to collate a set of use-cases that the
RIPE NCC could use to evaluate requests?

- if an entitlement-based policy is implemented, is it an unlimited
entitlement policy, or does it transform to a needs-based or a deny based
policy outside specific parameters?

No doubt I have left many important things out.

If the answers to these questions suggest that we need a new policy, we
need also need to evaluate whether the new policy which results is better
than the existing one, for some meaning of the word "better".

Nick