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

In reply to Nick Hilliard's post this evening, I wanted to share some data.

In AS8075 (Microsoft's primary network), we have a lot of incompatibility with 4-byte AS numbers.  We have equipment from some vendors who don't support it at all (like Arista), or support it without being able to remove-private on the extended range (important for locally-unique AS number usage) We've filed feature requests with all parties, and our spend with these vendors should justify fast tracking feature requests.  And yet ... nothing here in May 2015. RFC4893 was published EIGHT years ago, and vendors are just not all that far along.

If the RIRs don't do anything to preserve 2-byte AS numbers, then things are going to start really breaking.  That should get vendors to wake up.  But that's not a good scenario.    On the other hand, there's no stopping 2-byte exhaustion: the velocity of 2-byte number registration is too fast - we'll be out soon enough no matter what we do.

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation

> -----Original Message-----
> From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On
> Behalf Of Nick Hilliard
> Sent: Friday, May 15, 2015 4:40 PM
> To: Gert Doering; address-policy-wg at ripe.net
> Subject: Re: [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
>