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
