2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4
Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise.
after all, that has worked out so well for ipv4 space randy
* Job Snijders <job@instituut.net> [2015-08-11 11:18]:
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise.
As we all have seen how well "our community" works for IPv4 from the last-/8 I would not like to see something like that happen again. We could use rough consensus to decide if someone gets a new AS number. (I'm only 85% joking). Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Hi Job,
Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review:
""" A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
It occurs to me that in the absence of an economic disincentive against hoarding, there is not really any realistic way forward here except to have the NCC continue to evaluate the applicant's need. That is not to say that "need" must necessarily be equated with "multihoming", as it is today. Two possible approaches: 1) The «Job and Saku scratches their own itch» variant: 2014-03 is changed to simply add its authors' use case(s) to a list of valid use cases (alongside multihoming). If another applicant has some other use case he feels should also be valid, he'll just have to submit his own itch-scratching proposal. 2) Ask the NCC to maintain a public out-of-policy list of valid use cases. Whenever a new applicant comes with potentialy valid use case currently not on the list, APWG could be consulted and greenlight it using a much more informal and fast/lightweight consensus determining procedure than the PDP (e.g., sending a mail to APWG describing the use case and asking if anyone sees any problems with it, if N weeks of silence, it's good). If it ends up being shot down, the applicant can always try his luck with the PDP instead. Tore
Hi, On Tue, Aug 11, 2015 at 12:09:04PM +0200, Tore Anderson wrote:
2) Ask the NCC to maintain a public out-of-policy list of valid use cases. Whenever a new applicant comes with potentialy valid use case currently not on the list, APWG could be consulted and greenlight it using a much more informal and fast/lightweight consensus determining procedure than the PDP (e.g., sending a mail to APWG describing the use case and asking if anyone sees any problems with it, if N weeks of silence, it's good). If it ends up being shot down, the applicant can always try his luck with the PDP instead.
I like this :-) - of course I'd like to hear what RS would have to say about it ("we can do this" vs. "there are too many different cases to make sense out of this", etc.) - but the general idea is nicely lightweight and flexible... Gert Doering -- no hats (this is not formal PDP anyway right now!) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Tue, Aug 11, 2015 at 12:13:36PM +0200, Gert Doering wrote:
On Tue, Aug 11, 2015 at 12:09:04PM +0200, Tore Anderson wrote:
2) Ask the NCC to maintain a public out-of-policy list of valid use cases. Whenever a new applicant comes with potentialy valid use case currently not on the list, APWG could be consulted and greenlight it using a much more informal and fast/lightweight consensus determining procedure than the PDP (e.g., sending a mail to APWG describing the use case and asking if anyone sees any problems with it, if N weeks of silence, it's good). If it ends up being shot down, the applicant can always try his luck with the PDP instead.
This sounds like a lot of work. The complicated process would hurt legitimate users, as it is safe to assume an intentional haorder will just lie to the NCC to get the resources. "Let me see what is whitelisted... Sure... i have l3vpns.. sure..."
I like this :-) - of course I'd like to hear what RS would have to say about it ("we can do this" vs. "there are too many different cases to make sense out of this", etc.) - but the general idea is nicely lightweight and flexible...
A year ago Martin Hannigan remarked: "Why isn't "I'm connecting to a network and speaking BGP" with at least one peer good enough?" I agree with that sentiment. It might be interesting if we could shift the discussion away from "How to justify to RIPE NCC how you run your network" to a slightly different angle: "Helping the community prevent hoarding". Nothing more, nothing less. Kind regards, Job
On Tue, Aug 11, 2015, at 12:24, Job Snijders wrote:
It might be interesting if we could shift the discussion away from "How to justify to RIPE NCC how you run your network" to a slightly different angle: "Helping the community prevent hoarding". Nothing more, nothing less.
Because AS numbers are still limited ressources. We are just making (since at least 5 years) the switch from 16-bit to 32-bit (which we found some time ago that it does not represent infinite). So for 16-bit ASNs, I find that yes, people should justify to RIPE NCC how do they run the network in order to get an unique number. For 32-bit ASNs, there is no problem YET, but let's not make a habit (quickly transformed into rule) about how to get exclusivity on unique numbers.
On Tue, Aug 11, 2015, at 12:13, Gert Doering wrote:
I like this :-) - of course I'd like to hear what RS would have to say about it ("we can do this" vs. "there are too many different cases to make sense out of this", etc.) - but the general idea is nicely lightweight and flexible...
The idea is good, but I would really really want to see what does it give implementation-wise. Generally speaking a text like "interconnection with several (= how many ???) external (how do you really define external) entities" should cover the need for one AS. A second ASN (*autonomous* system) , well it should require a second "autonomous" system/entity respecting the same conditions. Now we should probably ask about NCC's capacity to evaluate what is "external" and "autonomous". For LIR creation it doesn't seem to be very effective at this task. It didn't seem very effective in the past for IP address allocation neither (criteria slightly different, but not so much).
Hi APWG, It should be noted that the below message is an "in-between poll" to seek guidance for the next formal version. As Gert aptly pointed out to me, technically I now started a "random discussion". :-) Anyhow, please help us address the adversary argument. Kind regards, Job On Tue, Aug 11, 2015 at 11:15:36AM +0200, Job Snijders wrote:
Dear APWG,
Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review:
""" A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need.
The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database.
The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """
diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise.
Kind regards,
Job
On Tue, Aug 11, 2015 at 12:12:14PM +0200, Job Snijders wrote:
It should be noted that the below message is an "in-between poll" to seek guidance for the next formal version. As Gert aptly pointed out to me, technically I now started a "random discussion". :-)
It might be of interest to note that in the APNIC region a policy change, not unsimilar to 2014-03, is continuing forward: https://www.apnic.net/policy/proposals/prop-114 https://www.apnic.net/policy/proposals/prop-114/prop-114-v003.txt Kind regards, Job
On Tue, 11 Aug 2015, Job Snijders wrote:
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise.
Cap the number of ASNs handed out until the policy is evaluated. RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 has been reached, please come back and tell us how it went. If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't used up a huge amount of this limited resource. Also, having an ASN costs money per year, right? So if someone wants to sit on 1000 ASNs, this will actually cost significant money? -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, Aug 11, 2015 at 12:32:53PM +0200, Mikael Abrahamsson wrote:
On Tue, 11 Aug 2015, Job Snijders wrote:
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise.
Cap the number of ASNs handed out until the policy is evaluated.
RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 has been reached, please come back and tell us how it went.
If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't used up a huge amount of this limited resource.
Very interesting approach! We'd call it the "Anything goes" ASN pool. Arguably this approach mitigates the risk of depleting the entire pool.
Also, having an ASN costs money per year, right? So if someone wants to sit on 1000 ASNs, this will actually cost significant money?
ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on your bill. Unless the charging scheme is updated next year to bring changes in this area. The last AGM meeting made it clear to me that the community does not want to associate a linear cost with ASN assignment. Kind regards, Job
On Tue, 11 Aug 2015, Job Snijders wrote:
ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on your bill. Unless the charging scheme is updated next year to bring changes in this area. The last AGM meeting made it clear to me that the community does not want to associate a linear cost with ASN assignment.
The LIR with the largest amount of ASNs, how many ASNs do they have? Why not say it starts to cost money after 3x this current value and for RIPE to report back when single ASN has more than 2x current max value? If (for instance) current max is 100 ASNs then limiting (at least for now) to 300ASNs per LIR might be a way to go? I have no idea how hard it is for RIPE to handle these limits though, I don't want to make up a lot of rules just hapazardly that then causes significant CAPEX/OPEX for RIPE. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, Aug 11, 2015 at 01:00:58PM +0200, Mikael Abrahamsson wrote:
On Tue, 11 Aug 2015, Job Snijders wrote:
ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on your bill. Unless the charging scheme is updated next year to bring changes in this area. The last AGM meeting made it clear to me that the community does not want to associate a linear cost with ASN assignment.
The LIR with the largest amount of ASNs, how many ASNs do they have?
It is easier to focus on the End User with the largest amount of ASNs rather then the middle-person the LIR. I believe at a previous RIPE meeting it was highlighted in the APWG session that the largest consumer of ASNs has 100 ASNs (ignoring legacy).
Why not say it starts to cost money after 3x this current value and for RIPE to report back when single ASN has more than 2x current max value? If (for instance) current max is 100 ASNs then limiting (at least for now) to 300ASNs per LIR might be a way to go?
I have no idea how hard it is for RIPE to handle these limits though, I don't want to make up a lot of rules just hapazardly that then causes significant CAPEX/OPEX for RIPE.
APWG cannot and will not decide on the charging scheme. As I mentioned before an attempt to start charging for ASNs was shot down by the last AGM. Kind regards, Job
Hi, On 11/08/15 13:44, Job Snijders wrote:
On Tue, Aug 11, 2015 at 12:32:53PM +0200, Mikael Abrahamsson wrote:
On Tue, 11 Aug 2015, Job Snijders wrote:
I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Cap the number of ASNs handed out until the policy is evaluated.
RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 has been reached, please come back and tell us how it went.
If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't used up a huge amount of this limited resource. Very interesting approach! We'd call it the "Anything goes" ASN pool. Arguably this approach mitigates the risk of depleting the entire pool. I also like this approach.
I would even go further and say that only 32bit ASNs should be handed out using this approach. 16bit ASNs (the few hundred still remaining) should be handed out only based on multihoming/verification requirements while 32bit ASNs could be handed out upon request. I believe that using a very small (*) cap may require us to re-visit this proposal in a short period of time. I propose to cap at 1/8 of the 32bit ASN pool (~4 billion divided by # of RIRs and then divided by 8 = approx 100million) and re-visit the ASN policy once we have been notified by the RIPE NCC that we are 6-12 months into reaching this cap or when we notice that something has gone wrong and needs to be changed. regards, elvis (*) as the ASN32 pool is over 4 billion, 50k out of 4billion is very small
On Tue, Aug 11, 2015, at 12:44, Job Snijders wrote:
ASNs have no associated cost.
To my understanding they do, but the cost is set to zero until further notice or vote. Someone please confirm or correct please ?
participants (8)
-
Elvis Daniel Velea -
Gert Doering -
Job Snijders -
Mikael Abrahamsson -
Radu-Adrian FEURDEAN -
Randy Bush -
Sebastian Wiesinger -
Tore Anderson