I support the concept that AS number allocation rules should be
relaxed, but I think further work is required to properly define the
residual criteria for allocation.|
Having read the past month's discussion about prop-114, I'll make some observations:
Let's not treat 4 billion (4-byte) AS numbers as precious. They're only route attributes, and not actual routes, and they can only be used with BGP routing, so their utility is high restricted, and their potential for direct abuse limited. (Large numbers of AS numbers by themselves don't explode routing tables, for example.)
If we consume 10,000 per year globally, then it will be 400,000 years before we exhaust the space - so I think we can afford some waste. We also only allocate AS numbers as individual numbers, and not as blocks of thousands or millions in the way we did for IPv4, and so greatly reducing the chance for massive waste.
We could argue back and forth what constitutes "appropriate" use of an AS number, but I see limited value in doing so given the enormous space now available (for 4-byte ASs); I feel the pragmatics outweigh the principles here.
I therefore believe it is not worth the Hostmasters' time (and therefore the members' money) to make onerous checks on whether AS numbers are being or will be used in a "suitable" way. I'd rather see fees charged to put the onus on the requester to decide whether they really needed the AS. A cap on the number of ASs per account could also be imposed if considered warranted.
So I feel that:
- 4-byte ASs should simply be allocated upon request, with existing checks removed;
- Reasonable annual fees (for example, $ per AS per year) could be charged as a disincentive for frivolous requests.
- Or a cap could be imposed on the number of AS numbers allocated per account;
- Or a combination of cap and charging; for example, up to xx ASs per account are free, and then each additional AS will be charged at $yy per AS per year.
- Existing constraints should remain for 2-byte ASs
On 4/02/2015 4:57 AM, Masato Yamanishi wrote: