new policy idea for PA allocations
[ This email is *not* about 2007-08 but something else that crossed my mind, expect a revised 2007-08 soon ] Dear all, I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request. Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)? What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies. As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see. I'm hesitant whether we should apply this to PI requests as well - I'd say yes but that does have an impact on the way we're currently handling that... Let me know what you think. Best, Remco Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Hi Remco, On Wed, Aug 06, 2008 at 11:44:56PM +0200, Remco van Mook wrote:
What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14.
I can see the rationale, and I also think that it makes sense to do it that way, operationally. I'm not sure whether this is something the APWG can/should decide - it's borderland between "policy" and "procedure". We do policy, the NCC does procedure... "Feedback, please!" :) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, Actually not a bad idea not to put it through the policy process :-) Best, Remco -----Original Message----- From: Gert Doering [mailto:gert@Space.Net] Sent: donderdag 7 augustus 2008 10:34 To: Remco van Mook Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations Hi Remco, On Wed, Aug 06, 2008 at 11:44:56PM +0200, Remco van Mook wrote:
What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14.
I can see the rationale, and I also think that it makes sense to do it that way, operationally. I'm not sure whether this is something the APWG can/should decide - it's borderland between "policy" and "procedure". We do policy, the NCC does procedure... "Feedback, please!" :) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
On Thu, 7 Aug 2008 08:34 UTC Gert Doering <gert@space.net> wrote:
I'm not sure whether this is something the APWG can/should decide - it's borderland between "policy" and "procedure". We do policy, the NCC does procedure... "Feedback, please!" :)
My feedback is that we're still missing the complete picture. If we make it "difficult" for users to be allocated large IP ranges then at least some of those users will simply announce ranges which they believe are not being used, without the luxury of allocation. Right now that's already being done by or for some criminal-types, and I'd guess this behaviour will soon spread to less-scrupulous entities, leaving the reputable organisations out in the cold. We need some agreements in place - at least with backbone providers - if we are to retain any semblance of order in the IPv4 numberspace. -- Richard (who is now back after a rather longer period of convalescence than I would have wished to have been required!)
Hi Richard, In all honesty I don't know what you mean with 'the complete picture' because the complete picture can only be drawn up in hindsight. Making good decisions after the fact is easy but beside the point. I'm voicing an idea about how to proceed when we can't allocate large IP ranges anymore the way we do today. A practical idea for us to provide guidance rather than have the NCC figure that one out for themselves. What that has to do with criminal types, unscrupulous providers and bright-faced 'backbone providers' is beyond me. A semblance of order is having a functional registry for ALL IPv4 address space - not just the stuff that has been originally allocated by the RIRs or predecessors. And this is something these 'backbone providers' vehemently oppose. Yes, this is another 2007-08 reference. Best, Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Richard Cox Sent: donderdag 7 augustus 2008 16:47 To: Gert Doering Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations On Thu, 7 Aug 2008 08:34 UTC Gert Doering <gert@space.net> wrote:
I'm not sure whether this is something the APWG can/should decide - it's borderland between "policy" and "procedure". We do policy, the NCC does procedure... "Feedback, please!" :)
My feedback is that we're still missing the complete picture. If we make it "difficult" for users to be allocated large IP ranges then at least some of those users will simply announce ranges which they believe are not being used, without the luxury of allocation. Right now that's already being done by or for some criminal-types, and I'd guess this behaviour will soon spread to less-scrupulous entities, leaving the reputable organisations out in the cold. We need some agreements in place - at least with backbone providers - if we are to retain any semblance of order in the IPv4 numberspace. -- Richard (who is now back after a rather longer period of convalescence than I would have wished to have been required!) Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Remco, On Wed, Aug 06, 2008 at 11:44:56PM +0200, Remco van Mook wrote:
I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request.
<snip/>
What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space.
Makes sense. Could someone submit another request immediately afterwards though, since current policies are based on need? -- Shane
Shane wrote:
What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space.
Makes sense.
Could someone submit another request immediately afterwards though, since current policies are based on need?
That's why I referred to the 80% rule in my mail - if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate. I do think that you raise a valid point here - should allocations in that phase still be based on need or does 'share the pain' come into play? Best, Remco Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Remco,
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Remco van Mook Sent: 07 August 2008 10:12 Subject: RE: [address-policy-wg] new policy idea for PA allocations
Could someone submit another request immediately afterwards though, since current policies are based on need?
That's why I referred to the 80% rule in my mail - if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate.
What's the point? If I qualify for a /15 and I want a /15 but all the RIR has available is a bunch of /18s, I'll take those /18s. That sucks but it doesn't suck as much as if I have to make 8 applications to get those /18s.
The point is quite simple - why bother being strict in allocating small blocks when in the end you're going to hand them over to a single request anyway. I don't want anyone filing a request that cleans out the cupboard in one go. If that's what the community wants, fine. But somehow I don't think so. We can also do a 'one size fits all' trick, or how about saying any organization (note that I'm not saying LIR here) is not allowed more than x% of the TOTAL space in that RIR region? Those /18s are not going to save BT or any other super-duper-large LIR from drowning but they might have a significant impact on the less gigantic or maybe, shock, new entrants. Or maybe we should just allow the space to run out as quickly as we can so new mechanisms can establish themselves de facto, rather than arguing about the inevitable. (yes that's a 2007-08 reference) Best, Remco -----Original Message----- From: matthew.ford@bt.com [mailto:matthew.ford@bt.com] Sent: donderdag 7 augustus 2008 12:13 To: Remco van Mook; shane@time-travellers.org Cc: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] new policy idea for PA allocations Remco,
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Remco van Mook Sent: 07 August 2008 10:12 Subject: RE: [address-policy-wg] new policy idea for PA allocations
Could someone submit another request immediately afterwards though, since current policies are based on need?
That's why I referred to the 80% rule in my mail - if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate.
What's the point? If I qualify for a /15 and I want a /15 but all the RIR has available is a bunch of /18s, I'll take those /18s. That sucks but it doesn't suck as much as if I have to make 8 applications to get those /18s. Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Remco van Mook wrote:
The point is quite simple - why bother being strict in allocating small blocks when in the end you're going to hand them over to a single request anyway.
then don't <doh> randy
Remco,
Could someone submit another request immediately afterwards though, since current policies are based on need? if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate. What's the point? If I qualify for a /15 and I want a /15 but all the RIR has available is a bunch of /18s, I'll take those /18s. The point is quite simple - why bother being strict in allocating small blocks when in the end you're going to hand them over to a single request anyway. I don't want anyone filing a request that cleans out the cupboard in one go.
So, you're proposing the addition of increased administrative overhead (in the form of requiring multiple applications for address space to obtain the amount of address space originally requested) as a mechanism to reduce the demand on the fragmented pool? Thanks, -drc
Hi David, I'm not sure how big the extra overhead will be - my estimate is not a lot - but putting it that way, that is indeed what I'm suggesting. Allocating all the fragments to a single request or small number of requests is in my opinion the worst possible thing we could do with it. Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy. Best, Remco -----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: donderdag 7 augustus 2008 18:28 To: Remco van Mook Cc: matthew.ford@bt.com; shane@time-travellers.org; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations Remco,
Could someone submit another request immediately afterwards though, since current policies are based on need? if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate. What's the point? If I qualify for a /15 and I want a /15 but all the RIR has available is a bunch of /18s, I'll take those /18s. The point is quite simple - why bother being strict in allocating small blocks when in the end you're going to hand them over to a single request anyway. I don't want anyone filing a request that cleans out the cupboard in one go.
So, you're proposing the addition of increased administrative overhead (in the form of requiring multiple applications for address space to obtain the amount of address space originally requested) as a mechanism to reduce the demand on the fragmented pool? Thanks, -drc Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy.
you may want to actually read the apnic proposal to which you are referring. it is only for the last /8 randy
I have read it and I understand that it's only about the last /8. I apologise for not making a more elaborate and eloquent reference. But considering the scenario, wouldn't you agree that I'm also talking about the same timeframe? AFAIK we don't have any significant number of requests for PA larger than a /8 (fortunately) And it is a 'one size fits all' approach :-) Remco -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: donderdag 7 augustus 2008 18:56 To: Remco van Mook Cc: David Conrad; matthew.ford@bt.com; shane@time-travellers.org; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations
Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy.
you may want to actually read the apnic proposal to which you are referring. it is only for the last /8 randy Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Remco van Mook wrote:
I have read it and I understand that it's only about the last /8. I apologise for not making a more elaborate and eloquent reference. But considering the scenario, wouldn't you agree that I'm also talking about the same timeframe?
[ just trying to be precise here ] the apnic region has no policy or policy proposals other than the current you-get-what-you-justify for space other than the last /8 from the free pool.
AFAIK we don't have any significant number of requests for PA larger than a /8 (fortunately)
in this case, i suspect a 'significant number' would be about one. listen to alain durand (comcast) and miyakawa shin (ntt) some time and be very fearful. they are in a terrible trade-off space. they either get a lot of public /8s or break the ipv4 internet [0] for their customers. currently they are opting for the latter.
And it is a 'one size fits all' approach :-)
actually, not exactly. the spnic proposal very purposfuly says the then current smallest allocation size. as things get tight, one might expect that size to change. randy --- [0] with 'carrier class nat' in the net core, you will get to write to comcast's walled garden lawyers when you want to deploy a new application that needs help from the nat.
Remco, On Aug 7, 2008, at 9:50 AM, Remco van Mook wrote:
I'm not sure how big the extra overhead will be - my estimate is not a lot - but putting it that way, that is indeed what I'm suggesting.
If the overhead is not a lot (something I suspect the request evaluation staff at RIPE-NCC might disagree with), it isn't clear to me how this would significantly impact address distribution.
Allocating all the fragments to a single request or small number of requests is in my opinion the worst possible thing we could do with it.
But wouldn't this be the outcome with your proposal as written since the folks most likely to consume the most address space are the ones with the resources to throw at writing a zillion applications? Or are you assuming there would be a significant increase in the number of requests submitted essentially simultaneously such that distribution of the fragments would be distributed more evenly over a number of requesters?
Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy.
Or you could put a wait time between requests, e.g., a new request from the same organization will only be reviewed (say) 30 days after the last request. If nothing else, this could increase RIPE-NCC's membership fee revenues (1/2 :-)). Regards, -drc
Hi David, Thanks for helping me clarify this. I don't see a reason for a 30-day rule because I think current policy will help us here. Allow me to explain. I'm assuming that most organizations will ask for a new allocation quickly after reaching the 80% usage mark on their current space. Also, that LIR would then ask, within current policy, for a years supply. Let's say for a period of 64 weeks because I'm lazy and I like round numbers :-) Now if that LIR were to request a /15 and only get a /17, it stands to reason that they don't pass the 80% mark again for about 16 weeks. If they get a /18, 8 weeks, a /19, 4 weeks, and so on. In order for them to come back within a day we're down to /23s anyway. So, a LIR that comes back immediately is clearly up to something fishy or might not be completely truthful in filling out their templates. I'm not convinced we can't work out a way to give this a proper write-up, but currently I just want to see whether the general idea has merit according to the community. So, does it ? Best, Remco -----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: donderdag 7 augustus 2008 22:31 To: Remco van Mook Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations Remco, On Aug 7, 2008, at 9:50 AM, Remco van Mook wrote:
I'm not sure how big the extra overhead will be - my estimate is not a lot - but putting it that way, that is indeed what I'm suggesting.
If the overhead is not a lot (something I suspect the request evaluation staff at RIPE-NCC might disagree with), it isn't clear to me how this would significantly impact address distribution.
Allocating all the fragments to a single request or small number of requests is in my opinion the worst possible thing we could do with it.
But wouldn't this be the outcome with your proposal as written since the folks most likely to consume the most address space are the ones with the resources to throw at writing a zillion applications? Or are you assuming there would be a significant increase in the number of requests submitted essentially simultaneously such that distribution of the fragments would be distributed more evenly over a number of requesters?
Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy.
Or you could put a wait time between requests, e.g., a new request from the same organization will only be reviewed (say) 30 days after the last request. If nothing else, this could increase RIPE-NCC's membership fee revenues (1/2 :-)). Regards, -drc Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Remco, On Thu, Aug 07, 2008 at 11:03:56PM +0200, Remco van Mook wrote:
So, a LIR that comes back immediately is clearly up to something fishy or might not be completely truthful in filling out their templates .
Good point!
I'm not convinced we can't work out a way to give this a proper write-up, but currently I just want to see whether the general idea has merit according to the community. So, does it ?
I think it is relatively simple and has merit; the potential benefit is not very large, but it is almost free. The main problem is people who only see the pain it will cause them when addresses run out. But, if you need a /16 and there is only a /17, and two /18 blocks left, then you are going to be screwed in a few months when you come back and there are only a handful of /24s lying around anyway. Time to get that IPv6 plan rolled out? (More likely time to set up a monster NAT box and give your users RFC 1918 addresses.) :( -- Shane
Remco and all, I am sure glad that shoes are not sold/avaliable on the one size fits all paradign. >:) Remco van Mook wrote:
Hi David,
I'm not sure how big the extra overhead will be - my estimate is not a lot - but putting it that way, that is indeed what I'm suggesting. Allocating all the fragments to a single request or small number of requests is in my opinion the worst possible thing we could do with it.
Alternatively we could take the 'one size fits all' approach as has been proposed in the APNIC region as referred to by Randy.
Best,
Remco
-----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: donderdag 7 augustus 2008 18:28 To: Remco van Mook Cc: matthew.ford@bt.com; shane@time-travellers.org; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] new policy idea for PA allocations
Remco,
Could someone submit another request immediately afterwards though, since current policies are based on need? if you again qualify for another allocation you can come back for one. If that's immediate, it's immediate. What's the point? If I qualify for a /15 and I want a /15 but all the RIR has available is a bunch of /18s, I'll take those /18s. The point is quite simple - why bother being strict in allocating small blocks when in the end you're going to hand them over to a single request anyway. I don't want anyone filing a request that cleans out the cupboard in one go.
So, you're proposing the addition of increased administrative overhead (in the form of requiring multiple applications for address space to obtain the amount of address space originally requested) as a mechanism to reduce the demand on the fragmented pool?
Thanks, -drc
Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager.
This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Regards, Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
Remco, If it's a choice between [2 /17s, 1 /18, 5 /19s and 2 /20s] and [1 /17 and a note that says 'come back when you need more'], I'll take the former every time. I don't agree that a 'requester is not going to be happy to to get a bunch of /24s from all over the swamp space to fill their request' - they are going to be happy if that's all there is available. Preventing a single request from wiping out the remaining RIR reserves can more easily be prevented by some policy along the lines of 'no more than x% of remaining reserves', coupled with some lower bound. Regards, Mat
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Remco van Mook Sent: 06 August 2008 22:45 To: address-policy-wg@ripe.net Subject: [address-policy-wg] new policy idea for PA allocations
[ This email is *not* about 2007-08 but something else that crossed my mind, expect a revised 2007-08 soon ]
Dear all,
I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request.
Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)?
What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies.
As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see.
I'm hesitant whether we should apply this to PI requests as well - I'd say yes but that does have an impact on the way we're currently handling that...
Let me know what you think.
Best,
Remco
Mat wrote:
Preventing a single request from wiping out the remaining RIR reserves can more easily be prevented by some policy along the lines of 'no more than x% of remaining reserves', coupled with some lower bound.
I can see where you're coming from with this. However, any percentage scheme is going to be fraught with implementation complexity. I'd rather have a clear, well-defined limit than one that arguably depends on what time of day you filed your request (or when the request was approved - what counts?) How far do we go? Will we allocate /28s to fill that percentage? Please don't. Doing it my way will allow the NCC to put up a webpage saying 'the current largest block we hand out is a /xx'. Very transparent, very educational for your users and a very visible sign that they ought to move to IPv6. Best, Remco Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
On Thu, 7 Aug 2008, Remco van Mook wrote:
Date: Thu, 7 Aug 2008 11:22:42 +0200 From: Remco van Mook <Remco.vanMook@eu.equinix.com> To: matthew.ford@bt.com Cc: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] new policy idea for PA allocations
Mat wrote:
Preventing a single request from wiping out the remaining RIR reserves can more easily be prevented by some policy along the lines of 'no more than x% of remaining reserves', coupled with some lower bound.
I can see where you're coming from with this. However, any percentage scheme is going to be fraught with implementation complexity. I'd rather have a clear, well-defined limit than one that arguably depends on what time of day you filed your request (or when the request was approved - what counts?) How far do we go? Will we allocate /28s to fill that percentage? Please don't.
Doing it my way will allow the NCC to put up a webpage saying 'the current largest block we hand out is a /xx'. Very transparent, very educational for your users and a very visible sign that they ought to move to IPv6.
I personally think this will only increase the effort to get that biggest block availlable, in a time when v4 is running out, i think some will use any trick availlable to get the last free (v4) ip:s.
Best,
Remco
Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager.
This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
************************************************************ Raymond Jetten Phone: +358 3 41024 139 Tietoliikenneasiantuntija Fax: +358 3 41024 199 Elisa Oyj / Verkonhallinta IP/MPLS Mobile: +358 45 6700 139 Hermiankatu 3A raymond.jetten@elisa.fi FIN-33720, TAMPERE http://www.elisa.fi ************************************************************
Raymond wrote:
Doing it my way will allow the NCC to put up a webpage saying 'the current largest block we hand out is a /xx'. Very transparent, very educational for your users and a very visible sign that they ought to move to IPv6.
I personally think this will only increase the effort to get that biggest block availlable, in a time when v4 is running out, i think some will use any trick availlable to get the last free (v4) ip:s.
I think this will happen regardless. Waiting for a strategic moment to file that /large request is currently the obvious way to ensure this and is what I'm trying to prevent. Best, Remco Any opinions expressed in the email are those of the individual and not necessarily of the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient and do not constitute an offer or acceptance by Equinix, Inc., Equinix Europe Ltd or any of their group entities to buy or sell any products or services in any jurisdiction. If you have received this email in error please delete this email immediately and notify the IT manager. This communication is sent on behalf of one of the European entities in the Equinix, Inc. Group. The ultimate holding company in Europe is Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW and the Company's registered number is 6293383. The registration details of other Group entities are available at www.eu.equinix.com
Preventing a single request from wiping out the remaining RIR reserves can more easily be prevented by some policy along the lines of 'no more than x% of remaining reserves', coupled with some lower bound.
you may find <http://www.apnic.net/policy/proposals/prop-062-v001.html> to small, but it's one approach. the core to this one is that, at the end, one may want to keep tiny bits still available to our grandchildren (and yes, i have them). randy
participants (7)
-
David Conrad
-
Gert Doering
-
Jeffrey A. Williams
-
matthew.ford@bt.com
-
Randy Bush
-
Raymond Jetten
-
Remco van Mook
-
Richard Cox
-
Shane Kerr