Fwd: Suggestions on a new asn assignment policy
AP-WG, I've included below an email which was sent to the authors of 2014-03 as a followup to this email (dated Sat May 16 01:40:13 CEST 2015):
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-May/009982.ht...
Saku, Job and I discussed these ideas but the discussions didn't come to anything. The suggestions below don't fix everything with ASN assignment because 100% solutions don't work. However they provide a practical and workable mechanism which trivially deals with the vast majority of cases, and provides a known working mechanism for creating a run-out pool for ASN16, all based on policy principals which are either in place for other resources, or else which have been tried and tested in practice. I'm planning to write this up as a formal policy proposal in the next short while, as an alternative to 2014-03. If anyone has suggestions or tweaks, please feel free to bring them up. Nick -------- Forwarded Message -------- Subject: Suggestions on a new asn assignment policy Date: Sat, 16 May 2015 00:43:18 +0100 From: Nick Hilliard <nick@foobar.org> To: Job Snijders <job@instituut.net>, Saku Ytti <saku@ytti.fi> CC: AP WG Chairs <apwg-chairs@ripe.net> Saku, Job, WG Chairs, re: my email to ap-wg of a couple of moment ago, here are some ideas I've been mulling over: - if an end user wants a single ASN32 and they don't already have one, they should get it on the basis of entitlement. - if an end user wants more than one ASN32, they should get it on the basis of a needs-based policy. - if an end user wants one or more ASN16s, they should get it on the basis of an needs-based policy, unless the remaining pool of ASN16s has reached a certain threshold - regardless of the requirement, end users may only receive one ASN16 from the remaining pool, and this should be assigned on the basis of a needs-based policy. The needs criteria can be collated by both operator input and by taking a look at historical assignment reasons: the ripe ncc have 25 years of experience in assigning ASNs and have a large database of reasons that end-users have put forward on their application forms. But we already have a pretty good idea of what this list should include. Basing a new policy along the lines of these principals will provide the following: - no requirement for charging - trivially deals with the most common case, namely assignment of a single asn32 - a runout policy for asn16s which both has well-understood limitations and will probably be palatable to the ripe community, as it's proposed on a similar basis to the last /8 + will be subject to 24m rule. - no practical way of asn32 resource exhaustion because each application will be individually evaluated by an IPRA (either on the basis of 2007-01 for end-user authentication or else on the basis of needs evaluation once that authentication has been completed). - continuation of existing ASN16 policy until a hard limit is hit, after which a run-out policy will apply - conceptually very similar to ipv4 / ipv6 policy. - hopefully an end to lies on asn application forms for asn32s I don't know what you guys feel about these suggestions, but I think they could be used to create something a good deal better than what we have right now. If you want to use these suggestions to form 2014-03 v3.0, you are welcome to do so, but I would ask you kindly to acknowledge my input as appropriate. Alternatively, if either or both of you have got tired of 2014-03, I would be happy to take up the baton and run with something along the lines of the above. Nick
- if an end user wants a single ASN32 and they don't already have one, they should get it on the basis of entitlement.
- if an end user wants more than one ASN32, they should get it on the basis of a needs-based policy.
- if an end user wants one or more ASN16s, they should get it on the basis of an needs-based policy, unless the remaining pool of ASN16s has reached a certain threshold
- regardless of the requirement, end users may only receive one ASN16 from the remaining pool, and this should be assigned on the basis of a needs-based policy.
those last two do not correlate and, does end user include lir? randy
Respectfully, I think the WG is trying to solve a problem which doesn't exist. And I STRONGLY dislike policy discussions and text which penalize 99.9% of the people just trying to operate a network because of the 0.1% of idiots who might think it's fun to do something stupid. I believe ASNs should be given out to LIRs in an on-demand basis without cost and in an automated fashion. If at some point in the future, the NCC or community discovers some child has abused the system and taken an absurd number of ASNs, the NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the RIPE NCC Standard Service Agreement. David R Huberman Principal, Global IP Addressing Microsoft Corporation
I fully agree with David on this. The initial intent of the policy was to remove the multi-homing requirement when requesting for an AS number. <full stop> Any stop that the NCC will use in their automated process of provisioning to detect that someone is abusing the system and stop further provisioning is all up to the NCC to implement. For all I care, they stop their automated provisioning after assigning 50 AS's within the last 12 months to $LIR.. And do additional requests manually ... It should not be at the APWG to dictate how they should implement this in software or policy imho. The AGM showed that the membership decided there will be no charge for ASn's for the near future. For a simple policy change like this, it is amazing how much we are looking at eachother in order to fluff this up ... If someone has a specific requirement for a 16 bit AS number ( yes they are on short supply atm .. ) feel free to ask the justification for it, or to ask if they can deal with a 32 bit ASn... If they can't and they really need a 16 Bit AS and the NCC doesn't have any anymore .. There is a transfer policy for AS numbers ... but let's not put more clutter in the policy than strictly required. Erik Bais
On Tue, 11 Aug 2015, David Huberman wrote:
If at some point in the future, the NCC or community discovers some child has abused the system and taken an absurd number of ASNs, the NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the RIPE NCC Standard Service Agreement.
I just read 6.3, 9.3 and 9.4. I don't see which of these I would be in violation of if I went to RIPE NCC and asked for 10k ASNs "because I need them" under the proposed new policy of just recording reason. With the proposed policy of just recording reason given, I don't see how the resources can be revoked (because I have given reason and those reasons have been registered by RIPE NCC), at least not referring to 6.3, 9.3 and 9.4. -- Mikael Abrahamsson email: swmike@swm.pp.se
I just read 6.3, 9.3 and 9.4. I don't see which of these I would be in violation of if I went to RIPE NCC and asked for 10k ASNs "because I need them" under the proposed new policy of just recording reason.
Correct! Which is why I don't think I like the new policy. Existing ASN policy suffices if we simply strike one sentence about multi-homing (and then ask the NCC to generally automate the implementation). Existing ASN policy references the criteria in RFC1930 as justification for an ASN, and an audit can rely on the text to clear out any stupidity. Yes?
On Tue, 11 Aug 2015, David Huberman wrote:
Existing ASN policy suffices if we simply strike one sentence about multi-homing (and then ask the NCC to generally automate the implementation). Existing ASN policy references the criteria in RFC1930 as justification for an ASN, and an audit can rely on the text to clear out any stupidity.
Yes?
Hm, so you want to move to a model that does post-auditing in case of suspected misbehavior (which would involve revokation in case of abuse has been detected), instead of doing pre-auditing of each request? So this sounds like the model employed for DNS domains. This requires committes of impartial people judging the facts and blah blah blah. It also involves text how this process works. So while I am not opposed to this suggestion, I fear that's it's more complicated to implement than what might be obvious at first glance. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hm, so you want to move to a model that does post-auditing in case of suspected misbehavior (which would involve revokation in case of abuse has been detected), instead of doing pre-auditing of each request?
Correct. Automate and remove the hostmasters from making engineering decisions about OUR networks.
So this sounds like the model employed for DNS domains. This requires committes of impartial people judging the facts and blah blah blah. It also involves text how this process works.
So while I am not opposed to this suggestion, I fear that's it's more complicated to implement than what might be obvious at first glance.
Strongly disagree. It relies on the NCC to do what the NCC has done well for 25 years: be a numbers registry. Where fraud is suspected or discovered, act in the best interests of the Internet. The NCC is well practiced in detecting and fighting fraud, and continually improves in this regard. Trust the NCC staff to do their jobs well; they know what they're doing.
On Tue, 11 Aug 2015, David Huberman wrote:
Strongly disagree. It relies on the NCC to do what the NCC has done well for 25 years: be a numbers registry. Where fraud is suspected or discovered, act in the best interests of the Internet. The NCC is well practiced in detecting and fighting fraud, and continually improves in this regard. Trust the NCC staff to do their jobs well; they know what they're doing.
Well, I would like to hear this from NCC itself in that case. From what I can see, RIPE NCC doesn't currently have to necessary text in the contracts and policies to enable it to do what you want it to do. -- Mikael Abrahamsson email: swmike@swm.pp.se
David, thanks for your comments. On 11/08/2015 12:41, David Huberman wrote:
Respectfully, I think the WG is trying to solve a problem which doesn't exist.
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. 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.
And I STRONGLY dislike policy discussions and text which penalize 99.9% of the people just trying to operate a network because of the 0.1% of idiots who might think it's fun to do something stupid.
The suggestion provides for an ASN32 on demand to anyone who wants one without any justification. If you look at the numbers, this means that about 85% of ASN assignments can be automated fully. This is a serious win in terms of registry efficiency which directly benefits those 85% of assignments. The remaining 15% will have more relaxed policies in place after their first ASN assignment until the ASN16 pool has reached a certain point. Future market entrants will benefit by being given a toe-hold in the door, in the same way that future market entrants are given a toe-hold in the door with the last /8 ipv4 allocation policy. I.e. we already have a precedent for community support for this.
I believe ASNs should be given out to LIRs in an on-demand basis without cost and in an automated fashion.
At current run-rates, there are a 3-4 years of ASN16s left. This wouldn't be a problem if ASN32s were semantically identical to ASN16s, but unfortunately they are not. As has been pointed out repeatedly, there is a root cause problem here which is not being addressed by the IETF and if/when it's addressed, it will take may years to roll out - far longer than 3-4 years.
If at some point in the future, the NCC or community discovers some child has abused the system and taken an absurd number of ASNs, the NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the RIPE NCC Standard Service Agreement.
As Mikael Abrahamsson points out, this is extremely difficult to implement in practice. Nick
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
If at some point in the future, the NCC or community discovers some child has abused the system and taken an absurd number of ASNs, the NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the RIPE NCC Standard Service Agreement.
there lurk lawyers. i don't think you want to go there. avoide as much as humanly possible. randy
participants (5)
-
David Huberman -
Erik Bais -
Mikael Abrahamsson -
Nick Hilliard -
Randy Bush