[address-policy-wg] Fwd: Suggestions on a new asn assignment policy

Sorry for the delay in reply.

I wrote:

> > Respectfully, I think the WG is trying to solve a problem which
> > doesn't exist.

Nick Hilliard replied:
 
> the policy has one problem now and is facing ASN16 depletion in the future.
> 
> The problem now is that you can only get an ASN if you are "multihomed" and there are a bunch of 
> situations where this is causing unnecessary problems.  People work around this by lying on the
> application form and this is not good stewardship of number resources.

I agree that the multi-homed sentence in the current ASN policy should be struck. By striking it, 
you allow the requestor to rely on the precepts in RFC1930 to make a technical argument for 
why they should be assigned an AS number. [Or, in a world where AS number requests are 
automated, allow the registrant to defend why they have the AS number.]

With respect to 2-byte AS number depletion, Nick further wrote:

> Regarding depletion, we have an option of viewing this as a problem, or not.
> I view it as a problem because BGP community support for ASN32 is very
> poor, and future entrants to the IP market will be penalised for being future
> entrants.
>
> There are substantial regulatory problem associated with existing market
> players effectively locking out future players, and given that the RIPE NCC
> has a monopoly in ip number resource assignments in this part of the world,
> this is an issue which would be best avoided if possible.

This part I have a problem with, and is what I intended to reply to with my "the WG is trying to 
solve a problem which does not exist".  

1) When I look at my table, there are over 38,000 unique prefixes being advertised to me that 
originate from, or propagate through, 4-byte AS numbers.

2) I work at a pretty darn big network, which relies heavily on BGP communities to make 
critical routing decisions.  While our main AS is an old 2-byte, we have new deployments of
significantly-sized networks which are only using 4-byte AS numbers, both for external
BGP and for internal use.    And it DOES work.  Now, it certainly isn't easy.  Our biggest challenge
as a large network is figuring out how to have a single policy rule to cover both 2-byte and
4-byte communities together.  We haven't overcome that hurdle yet.  And there are niggly 
little challenges like the fact that JunOS doesn't support remove private 4-byte ASN in the
code we are running.    But we've found ways to engineer around the lack of feature support, 
and of course, we are constantly banging on our vendors to do better.  

3) I am REALLY uncomfortable with making policy out of fear of future regulatory violations.
We should concentrate on making the best policy for "the Internet" and leave the lawyers
out of it.  As engineers, we all know that there is no future for 2-byte AS numbers, and that
operators and equipment must fully support 4-byte AS number implementation for both
themselves and their peers.  To that end, I'm against a policy which allows operators to 
plan on being able to obtain 2-byte AS numbers in the future to purposely avoid using a 4-byte
AS number.  It is my opinion that kind of thinking hurts everyone else trying to make 4-bytes
Work.

I hope I stated #3 clearly and wrote it accurately.  

I appreciate this discussion, and giving me the opportunity to provide my opinion.  As always,
I am happy to be shown that I am wrong :)

David

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation