Input request for the PI Transfer policy
Hi, As you might know, we are currently working on a policy proposal to allow the transfer of PI space. One of the topics that I would like some input (prior to sending out the proposal itself) it the following: In the current draft, Ive phrased one of the rules for the PI transfer as follows: - Assignments smaller than the minimal allocation size, cant be split into smaller assignments, but can be re-assigned as a complete assignment. My reasoning is that it would disallow cutting up small assignments into even smaller assignments. So in the current situation a /23 PI assignment is smaller than the minimal allocation size, however assigned in the past by the RIPE NCC. With the above stated rule in the proposal, it would not be allowed to split up a PI assignment into 2 PI assignments of a /24 .. or 4 PI assignments of a /25, but it would be allowed to do a complete re-assignments as a /23. With the current new proposal 2014-1 put forward today, the question that we discussed last week (myself, Marco and Andrea ) is that if we would put this forward, that this might need to be re-phrased. The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI. The goal of the PI transfer policy proposal is to have it similar as the current Transfer policy for PA space. Lets hear it. Regards Erik Bais
- Assignments smaller than the minimal allocation size, can't be split into smaller assignments, but can be re-assigned as a complete assignment.
it's before brekkie and only one cuppa, so i am a little slow. it might help if you explained why. randy
Hí Randy, On Tue, Mar 25, 2014 at 12:10 AM, Randy Bush <randy@psg.com> wrote:
- Assignments smaller than the minimal allocation size, can't be split into smaller assignments, but can be re-assigned as a complete assignment.
it's before brekkie and only one cuppa, so i am a little slow. it might help if you explained why.
randy
Just not to create more junks in the routing table... -- if I may repeat my wellknown argument. (I am also slow, btw) Best, Geza
- Assignments smaller than the minimal allocation size, can't be split into smaller assignments, but can be re-assigned as a complete assignment. it's before brekkie and only one cuppa, so i am a little slow. it might help if you explained why. Just not to create more junks in the routing table... -- if I may repeat my wellknown argument. (I am also slow, btw)
then it should say so fwiw, persoally i gave up this battle years ago. and i suspect there will be serious fragmentation as we go down the run-out path. randy
* Erik Bais
- Assignments smaller than the minimal allocation size, can’t be split into smaller assignments, but can be re-assigned as a complete assignment.
My reasoning is that it would disallow cutting up small assignments into even smaller assignments.
That is would be somewhat illogical IMHO. Assignments and allocations are two different things. The minimum allocation size has never been applied to assignments, so why start now? We've never had a minimum assignment size, at least not in recent years.
The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI.
Without. I am not at all concerned about the routing table here. There is nothing in policy nor in the RIPE database software that prevents people from adding /32 route objects and attempting to advertise them into the DFZ. There are at the moment 3888 route objects in the database with that are /25 or longer, but the routing community seem to be able to ignore them just fine. I don't see how "nano-PI" would be any different, the routing community won't have any difficulty ignoring those either. After all, a router couldn't care less if a route is from an inetnum with status "ASSIGNED PA" or "ASSIGNED PI". Or to put it another way, we don't need policy to forbid every bad idea under the sun. Let the routing community decide how they want to deal with this one. Tore
My reasoning is that it would disallow cutting up small assignments into even smaller assignments.
That is would be somewhat illogical IMHO. Assignments and allocations are two different things. The minimum allocation size has never been applied to assignments, so why start now? We've never had a minimum assignment size, at least not in recent years.
is that the pink integers or the red ones?
Hello Tore, May I interpret your words this way: Policy making and routing are two very separated, distinct actions?! While I fully understand the attitude of the routing community, I would encourage people raise their voices against bad policy making. Thanks, Geza On Tue, Mar 25, 2014 at 4:12 AM, Tore Anderson <tore@fud.no> wrote:
* Erik Bais
- Assignments smaller than the minimal allocation size, can't be split into smaller assignments, but can be re-assigned as a complete assignment.
My reasoning is that it would disallow cutting up small assignments into even smaller assignments.
That is would be somewhat illogical IMHO. Assignments and allocations are two different things. The minimum allocation size has never been applied to assignments, so why start now? We've never had a minimum assignment size, at least not in recent years.
The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI.
Without.
I am not at all concerned about the routing table here. There is nothing in policy nor in the RIPE database software that prevents people from adding /32 route objects and attempting to advertise them into the DFZ. There are at the moment 3888 route objects in the database with that are /25 or longer, but the routing community seem to be able to ignore them just fine. I don't see how "nano-PI" would be any different, the routing community won't have any difficulty ignoring those either. After all, a router couldn't care less if a route is from an inetnum with status "ASSIGNED PA" or "ASSIGNED PI".
Or to put it another way, we don't need policy to forbid every bad idea under the sun. Let the routing community decide how they want to deal with this one.
Tore
Hi, On Tue, Mar 25, 2014 at 08:56:35AM +0100, Turchanyi Geza wrote:
While I fully understand the attitude of the routing community, I would encourage people raise their voices against bad policy making.
"light policy that does not try to solve problems other people are fully qualified to handle themselves" is not "bad policy making". Gert Doering -- APWG chair -- 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
* Turchanyi Geza
May I interpret your words this way: Policy making and routing are two very separated, distinct actions?!
Not as a general statement, although in this specific case I suppose you could say that - the prefix length threshold of what's considered routable globally or not simply isn't going to be decided by the RIPE Address Policy Working Group, even if we pretend to make decision... We could make a policy that demanded «every network operator in the RIPE region MUST accept all routes up to and including /32s from all of their peers and upstreams». Or we could make a policy that stated «every network operator in the RIPE region MUST reject all routes with prefix lengths longer than or equal to the minimum allocation size of /22». Neither would have any effect out in the real world; the operators would continue to decide for themselves what they are willing to accept, just as they do today. We might as well try to outlaw the moon. That said, there are cases where a policy mandated minimum allocation size makes perfect sense and have a positive impact on routing. This is most apparent in IPv6, where every LIR is basically forced to accept a absolutely ridiculous amount of addresses no matter their actual perceived need. This prevents LIRs from underestimating their need (easy if you're used to IPv4), asking for too small blocks, and as a result having to return to the NCC for new and distinct allocations a few years down the line. The same was true for IPv4 allocations too before run-out, but to a lesser extent.
While I fully understand the attitude of the routing community, I would encourage people raise their voices against bad policy making.
«If it ain't broken, don't fix it» We don't currently have a minimum assignment size in policy (neither for PI or PA), nor do we have a minimum size of route objects. It's not broken. We don't need to fix it. Tore
Hi Erik, I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block. cheers, elvis On 24/03/14 23:44, Erik Bais wrote:
Hi,
As you might know, we are currently working on a policy proposal to allow the transfer of PI space.
One of the topics that I would like some input (prior to sending out the proposal itself) it the following:
In the current draft, I've phrased one of the 'rules' for the PI transfer as follows:
-Assignments smaller than the minimal allocation size, can't be split into smaller assignments, but can be re-assigned as a complete assignment.
My reasoning is that it would disallow cutting up small assignments into even smaller assignments.
So in the current situation a /23 PI assignment is smaller than the minimal allocation size, however assigned in the past by the RIPE NCC.
With the above stated 'rule' in the proposal, it would not be allowed to split up a PI assignment into 2 PI assignments of a /24 .. or 4 PI assignments of a /25, but it would be allowed to do a complete re-assignments as a /23.
With the current new proposal 2014-1 put forward today, the question that we discussed last week (myself, Marco and Andrea ) is that if we would put this forward, that this might need to be re-phrased.
The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI.
The goal of the PI transfer policy proposal is to have it similar as the current Transfer policy for PA space.
Let's hear it.
Regards
Erik Bais
On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote:
Hi Erik,
I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block.
That seems like an arbitrairy limit. What is so magic about /24? I can think of a few use-cases where globally unique ip space (and proper registration in a database) are useful, but global routability is not expected. Kind regards, Job
Hi, On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote:
I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block.
Why? Gert Doering -- APWG chair -- 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
Hi, On 25/03/14 10:57, Gert Doering wrote:
Hi,
On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote:
I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block. Why? First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit for Inter-RIR transfers and I do hope that our region will eventually have an Inter-RIR transfer policy compatible with theirs .. so, for consistency with the others.
Secondly, because most of the routing is done by filtering at the /24 level and even though not all the IPv4 space is used on the internet and publicly advertised, it seems to be the limit already adopted by most of the ISPs. Thirdly, setting up reverse dns for blocks lower than /24 requires that any minor changes for reverse dns would need to involve the RIPE NCC. Lastly, allowing any level of fragmentation could lead to an exploding IPv4 routing table (now at almost 500k routes). I'm not saying that adding an (arbitrary) transfer limit like the /24 would stop the routing table growth. There might be other reasons as well.. It's just a feeling that limiting at /24 is the right thing to do. On the other hand, while writing this e-mail I've been having second thoughts on each of the paragraphs and reasons :-) cheers, elvis
* Elvis Velea
First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit for Inter-RIR transfers and I do hope that our region will eventually have an Inter-RIR transfer policy compatible with theirs .. so, for consistency with the others.
The Inter-RIR transfer policy to be could simply say that if the other RIR has a minimum size limitation (or any other limitation really), then that limitation applies for transfers to/from that RIR, could it not? Seems to me that the fewer rules and restrictions we put in place in our end, the smaller the risk of any irreconcilable incompatibilities with other the other RIRs' policies.
Secondly, because most of the routing is done by filtering at the /24 level and even though not all the IPv4 space is used on the internet and publicly advertised, it seems to be the limit already adopted by most of the ISPs.
That is happening completely independent of RIPE address policy today and the practice will in all likelihood continue tomorrow too, regardless of what policy we might pass.
Thirdly, setting up reverse dns for blocks lower than /24 requires that any minor changes for reverse dns would need to involve the RIPE NCC.
The same is true for assignments smaller than /24 today, which already exist; we didn't have a minimum PI assignment size, so the NCC has issued quite a few >=/25s already. If those >=/25 PI assignments issued by the NCC aren't a problem today, I don't see why transferred >=/25 PI assignments should be one tomorrow.
Lastly, allowing any level of fragmentation could lead to an exploding IPv4 routing table (now at almost 500k routes). I'm not saying that adding an (arbitrary) transfer limit like the /24 would stop the routing table growth.
See my response to your «secondly»... Also I think that concerns over an «exploding» routing table are unfounded in reality. I mean we've only had 233 transfers _in total_ so far, and that's only of blocks that the recipient could reasonably expect to route on the internet. How many people are we seriously expecting to want to transfer these mostly useless >=/25 PI assignments to themselves? Anyone at all? I seriously doubt that those weirdos are numerous enough to worry about in the the slightest... Tore
* Tore Anderson
we've only had 233 transfers _in total_ so far
Correction: 265 Cut'n'paste mistake, apologies. Tore
Hi, On Tue, Mar 25, 2014 at 02:17:26PM +0200, Elvis Velea wrote:
On 25/03/14 10:57, Gert Doering wrote:
On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote:
I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block. Why? First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit for Inter-RIR transfers and I do hope that our region will eventually have an Inter-RIR transfer policy compatible with theirs .. so, for consistency with the others.
I don't see this as particularily desirable, follow the other regions "because they do it this way". Look there, learn from them, but make our own decisions.
Secondly, because most of the routing is done by filtering at the /24 level and even though not all the IPv4 space is used on the internet and publicly advertised, it seems to be the limit already adopted by most of the ISPs.
So this should limit the amount of what people *want* to transfer automatically, without putting it into the policy, no? It's commonly known that announcing a /25 won't work, so why would you transfer one, if not "for internal use"?
Thirdly, setting up reverse dns for blocks lower than /24 requires that any minor changes for reverse dns would need to involve the RIPE NCC.
That's indeed quite a strong argument for not *wanting* to transfer anything smaller, but would it need to go into the policy document? (My personal feeling is "nobody would want to transfer smaller blocks anyway, so we don't need to codify it", but it certainly needs to be discussed and agreed-upon...)
Lastly, allowing any level of fragmentation could lead to an exploding IPv4 routing table (now at almost 500k routes). I'm not saying that adding an (arbitrary) transfer limit like the /24 would stop the routing table growth.
It wouldn't... there's about 16 million /24s out there, so even limiting at /24 won't stop the explosion if people really start announcing everything up to the limit...
There might be other reasons as well.. It's just a feeling that limiting at /24 is the right thing to do. On the other hand, while writing this e-mail I've been having second thoughts on each of the paragraphs and reasons :-)
It's good to have the arguments out, so we can think through them - thanks! Gert Doering -- no hats -- 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
Hi Gert, On 25/03/14 15:26, Gert Doering wrote: [...]
There might be other reasons as well.. It's just a feeling that limiting at /24 is the right thing to do. On the other hand, while writing this e-mail I've been having second thoughts on each of the paragraphs and reasons :-) It's good to have the arguments out, so we can think through them - thanks! I tried to play the devil's advocate role this time. As said, even when writing all my con's I realized these aren't too strong.
As you already know, I'm in favor of not adding any limitations in policy. I was just trying to voice all the possible con's.
Gert Doering -- no hats
cheers, elvis -- blue hat to protect against the sun :-)
Dear Elvis, all, On 25/03/14 13:17, Elvis Velea wrote:
Thirdly, setting up reverse dns for blocks lower than /24 requires that any minor changes for reverse dns would need to involve the RIPE NCC.
We would just like to offer a little clarification regarding this point: Since December 2010, the RIPE NCC is no longer involved in reverse DNS of blocks smaller than a /24. Our Global Information Infrastructure (GII) department confirms that this is now handled automatically for RIPE Database users. Details on how to set up reverse delegation can be found here: http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegat... Kind regards, Marco Schmidt Policy Development Officer RIPE NCC
Hi Marco,
Since December 2010, the RIPE NCC is no longer involved in reverse DNS of blocks smaller than a /24.
This wording can be a bit misleading. I suspect you mean 'Since December 2010, the RIPE NCC does not have to perform any manual actions to provide reverse DNS of blocks smaller than a /24 as this is now fully automated.' I hope I understood you correctly :) Sander
On Mon, Mar 24, 2014 at 10:44:21PM +0100, Erik Bais wrote: Dear Erik
In the current draft, Ive phrased one of the rules for the PI transfer as follows:
- Assignments smaller than the minimal allocation size, cant be split into smaller assignments, but can be re-assigned as a complete assignment.
[cut]
The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI.
I would prefer not to have this put into policy text. I don't think we have any effective tools to enforce it. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (10)
-
Elvis Velea -
Erik Bais -
Gert Doering -
Job Snijders -
Marco Schmidt -
Piotr Strzyzewski -
Randy Bush -
Sander Steffann -
Tore Anderson -
Turchanyi Geza