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
