2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC
On 14 apr 2009, at 14:57, Ingrid Wijte wrote:
PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs
Dear Colleagues
A new RIPE Policy Proposal has been made and is now available for discussion.
Personally I don't like the following phrase: 'In case the routing policies would no longer be unique and/or the networks have effectively merged, the additional /32 allocations must be returned to the RIPE NCC' IMHO this should be extended to at least give a decent timeframe to renumber and possibly should differentiate between LIR's which have requested additional blocks for routing and/or administrative purposes and those who ended up with multiple allocations because they merged with some other LIR. And as an open question, what would happen if I would merge 2 autonomous systems in 1 LIR (If I understand correctly this is after all what is being proposed) both are operating a /32 which is over 50% usage ? a) grow one of the 2 allocations to /31 and renumber the other b) keep the 2 /32's on expense of 1 extra route in the DFZ but save yourself the renumbering task and secondly doesn't this open up the path to /32 per AS instead to / 32 per LIR ? Groet, MarcoH
Marco Hogewoning wrote:
On 14 apr 2009, at 14:57, Ingrid Wijte wrote:
PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs
Dear Colleagues
A new RIPE Policy Proposal has been made and is now available for discussion. Summary of Proposal: This is a proposal to allow an LIR operating separate networks in unconnected geographical areas to receive multiple /32 IPv6 allocations.
This policy is a must-have policy for hundreds of thousand users in my county and more than 20 LIRs. However there is a strong limitation for me in this policy, because we are using at least two different policies but within ONE single geographical areas. The differences in routing policies are not because of different geographical areas but because of different kind of customers we are serving. Currently we have to divide single /32 into multiple pieces and announce them under different ASs we have, which weak but the only possible solution. We do not have any chance to get a second /32 from RIPE so far. It would be really helpful to reflect this real life situation in single policy like this one. So after removing the part about "different unconnected geographical areas" this policy will get strong support from LIRs I'm writing about. Best regards, Bartek Gajda
Hang on a second. This is now devolving into a proposal where you can get a separate AS and /32 for every customer your LIR serves and I will definitely not support that. I want a pony, too. Remco On 15-04-09 10:08, "Bartek Gajda" <gajda@man.poznan.pl> wrote:
Marco Hogewoning wrote:
On 14 apr 2009, at 14:57, Ingrid Wijte wrote:
PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs
Dear Colleagues
A new RIPE Policy Proposal has been made and is now available for discussion. Summary of Proposal: This is a proposal to allow an LIR operating separate networks in unconnected geographical areas to receive multiple /32 IPv6 allocations.
This policy is a must-have policy for hundreds of thousand users in my county and more than 20 LIRs. However there is a strong limitation for me in this policy, because we are using at least two different policies but within ONE single geographical areas. The differences in routing policies are not because of different geographical areas but because of different kind of customers we are serving. Currently we have to divide single /32 into multiple pieces and announce them under different ASs we have, which weak but the only possible solution. We do not have any chance to get a second /32 from RIPE so far.
It would be really helpful to reflect this real life situation in single policy like this one. So after removing the part about "different unconnected geographical areas" this policy will get strong support from LIRs I'm writing about.
Best regards, Bartek Gajda
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote:
Hang on a second. This is now devolving into a proposal where you can get a separate AS and /32 for every customer your LIR serves and I will definitely not support that. I want a pony, too.
Correct me if I'm wrong, but allocation's goes to LIRs and not to customers. Moreover, AS'es are owned by clearly distinguished "entities". We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification). Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
I'm sorry but that goes back to my previous e-mail - a request for an AS is a request for an AS and I don't see how that should be related in any way to address space. What this achieves is the same level of fragmentation of the IPv6 space, but then in /32 blocks instead of /33, /34 and /35s. I don't see what the wider community gains here. If you need more space, request a larger block. If your issue is that some people filter smaller than /32 announcements then try to solve that. It's not like the global IPv6 routing table is going to explode any time soon. Personally I think IPv6 is going to be a runaway success by the time the DFZ hits 10,000 routes - filtering more specifics I can see the reason for, filtering smaller announcements I can not. Remco On 15-04-09 10:46, "Piotr Strzyzewski" <Piotr.Strzyzewski@polsl.pl> wrote:
On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote:
Hang on a second. This is now devolving into a proposal where you can get a separate AS and /32 for every customer your LIR serves and I will
definitely
not support that. I want a pony, too.
Correct me if I'm wrong, but allocation's goes to LIRs and not to customers. Moreover, AS'es are owned by clearly distinguished "entities". We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification).
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Remco van Mook wrote:
I’m sorry but that goes back to my previous e-mail – a request for an AS is a request for an AS and I don’t see how that should be related in any way to address space. What this achieves is the same level of fragmentation of the IPv6 space, but then in /32 blocks instead of /33, /34 and /35s. I don’t see what the wider community gains here. If you need more space, request a larger block. If your issue is that some people filter smaller than /32 announcements then try to solve that.
So what about is the current policy? You want to give some LIRs additional /32 because: "According to the IPv6 policy an IPv6 allocation must be announced as one prefix. Therefore, an organization operating four separate networks with one /32 IPv6 allocation cannot de-aggregate into for example a /34 route announcement per network." And here you are suggesting me to de-agradate my allocation which this proposal trying to avoid! Doesn't it looks like one can get what he or she wants but the other "can de-agraaate"?? Bartek
It’s not like the global IPv6 routing table is going to explode any time soon.
Personally I think IPv6 is going to be a runaway success by the time the DFZ hits 10,000 routes – filtering more specifics I can see the reason for, filtering smaller announcements I can not.
Remco
On 15-04-09 10:46, "Piotr Strzyzewski" <Piotr.Strzyzewski@polsl.pl> wrote:
On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote: > > Hang on a second. This is now devolving into a proposal where you can get a > separate AS and /32 for every customer your LIR serves and I will definitely > not support that. I want a pony, too.
Correct me if I'm wrong, but allocation's goes to LIRs and not to customers. Moreover, AS'es are owned by clearly distinguished "entities". We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification).
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
..or you can file a proposal to change the current policy. You're very obviously trying to solve a problem and I don't disagree that the problem exists; I just don't like the proposed solution. Remco On 15-04-09 11:06, "Bartek Gajda" <gajda@man.poznan.pl> wrote:
I'm sorry but that goes back to my previous e-mail - a request for an AS is a request for an AS and I don't see how that should be related in any way to address space. What this achieves is the same level of fragmentation of the IPv6 space, but then in /32 blocks instead of /33, /34 and /35s. I don't see what the wider community gains here. If you need more space, request a larger block. If your issue is that some people filter smaller than /32 announcements then try to solve that.
So what about is the current policy? You want to give some LIRs additional /32 because: "According to the IPv6 policy an IPv6 allocation must be announced as one prefix. Therefore, an organization operating four separate networks with one /32 IPv6 allocation cannot de-aggregate into for example a /34 route announcement per network." And here you are suggesting me to de-agradate my allocation which this
Remco van Mook wrote: proposal trying to avoid! Doesn't it looks like one can get what he or she wants but the other "can de-agraaate"??
Bartek
It's not like the global IPv6 routing table is going to explode any time soon.
Personally I think IPv6 is going to be a runaway success by the time the DFZ hits 10,000 routes - filtering more specifics I can see the reason for, filtering smaller announcements I can not.
Remco
On 15-04-09 10:46, "Piotr Strzyzewski" <Piotr.Strzyzewski@polsl.pl> wrote:
On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote:
> > Hang on a second. This is now devolving into a proposal where you
can get a
> separate AS and /32 for every customer your LIR serves and I will
definitely
> not support that. I want a pony, too.
Correct me if I'm wrong, but allocation's goes to LIRs and not to customers. Moreover, AS'es are owned by clearly distinguished "entities". We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification).
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
On 15 apr 2009, at 11:11, Remco van Mook wrote:
..or you can file a proposal to change the current policy. You’re very obviously trying to solve a problem and I don’t disagree that the problem exists; I just don’t like the proposed solution.
All, Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation. How do you solve this at the moment iin IPv4-land ? How many of you actually use RIPE-449 section 5.4 and won't PI solve your problem ? I'm happy with a proposal to include similair wording as seciotn 5.4 into RIPE-450 as long as it comes with a big disclaimer saying it's at your own risk and routing as always isn't guaranteed (point to 450, 4.2). At the same time we can set boundaries onto it to ease up filttering, like in the v4 case. As it stands I won't support the proposal as-is, it's far to specific and it harms fairness as the only requirement is an AS number and no references are made to HD-ratio or the regular subsequent allocation policy. Groet, MarcoH
On 15/04/2009 2:34, "Marco Hogewoning" <marcoh@marcoh.net> wrote: [...]
Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation.
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit? Regards, Leo Vegoda
Hello Leo, Just requesting an extra AS and PI space is now possible I guess. Maybe someone from Leaseweb/Fiberring can say how they do it? With kind regards, Mark -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Leo Vegoda Sent: woensdag 15 april 2009 18:02 To: Marco Hogewoning; Remco van Mook Cc: Bartek Gajda; Piotr Strzyzewski; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On 15/04/2009 2:34, "Marco Hogewoning" <marcoh@marcoh.net> wrote: [...]
Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation.
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit? Regards, Leo Vegoda
On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote:
On 15/04/2009 2:34, "Marco Hogewoning" <marcoh@marcoh.net> wrote:
Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation.
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit?
Sometimes it is not that case. For example, there could be one entity (LIR) which serves with the same staff (one business unit; limited resources) both commercial and academic customers using different boxes, IPs and ASes and (sometimes the most important) funds, which (all) due to whatever reason(s) which is beyond the scope of this thread, could not be mixed together. Opening a separate LIR is either an abuse of current policy (*) or unnecessary waste of time and money. (*) And let me remind that this abuse is necessary only for ipv6 (which we should promote). It seems that in ipv4 world people either do filters based on route objects or use fixed /24 size. Both options give some flexibility in announcing routes smaller then allocation. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Piotr Strzyzewski pisze:
Sometimes it is not that case. For example, there could be one entity (LIR) which serves with the same staff (one business unit; limited resources) both commercial and academic customers using different boxes, IPs and ASes and (sometimes the most important) funds, which (all) due to whatever reason(s) which is beyond the scope of this thread, could not be mixed together. Opening a separate LIR is either an abuse of current policy (*) or unnecessary waste of time and money.
We have similar situation as described above. And - as it was probably said before in this discussion - many many LIRs in Poland, not only academic ones. I completely agree with your opinion, Piotr. Second LIR shouldn't be created just for achieving same policy of routing as in today's IPv4 world. Business and political rules are staying the same for IPv6, we are only changing type of addresses we use, thats all. With only one prefix we can't get same setup as we have right now. -- Tomasz Klicki ICM Core Network Services, University of Warsaw t.klicki@net.icm.edu.pl (+48-22) 5520527, 8268009, fax. 8284195 http://www.net.icm.edu.pl/
Leo, On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote:
On 15/04/2009 2:34, "Marco Hogewoning" <marcoh@marcoh.net> wrote:
Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation.
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit?
Your solution, although possible, has some drawbacks: It adds administrative burden, this was discussed here. But it also will diminish the remaining unallocated IPv4 space. I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category. This, plus requirement of seperate routing policy may convince people to support the new policy. Jurek
Dear Jurek, I think you¹re still missing the point that some of us are trying to make. I simply don¹t think that the proposal is a good way of solving the problem (which is apparently part of a sentence in current policy). Adding a second /32 to the global routing table has just as much impact as splitting up a /32 in 2 /33s so there¹s no gain there. And as indicated, filters that are set by people are outside the scope of the address policy WG, and arguably also outside the scope of RIPE policy. Now, if you were to suppose to just take out the offending part of current policy, that would have my undying support. Kind regards, Remco On 16-04-09 10:11, "Jerzy Pawlus" <Jerzy.Pawlus@cyf-kr.edu.pl> wrote:
Leo,
On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote:
On 15/04/2009 2:34, "Marco Hogewoning" <marcoh@marcoh.net> wrote:
Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation.
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit?
Your solution, although possible, has some drawbacks:
It adds administrative burden, this was discussed here. But it also will diminish the remaining unallocated IPv4 space.
I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category. This, plus requirement of seperate routing policy may convince people to support the new policy.
Jurek
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi, On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote:
I think you¹re still missing the point that some of us are trying to make. I simply don¹t think that the proposal is a good way of solving the problem (which is apparently part of a sentence in current policy). Adding a second /32 to the global routing table has just as much impact as splitting up a /32 in 2 /33s so there¹s no gain there.
Mmmh, it's actually more than this. If you are a large multinational ISP, and run separate networks, these different networks might have completely different addressing needs, and growth rates. So one country network might be perfectly happy with a /35, another might need a /33, and a third one might grow into a /29 over time... Splitting a single /32 into something that has no potential for individual growth is likely to lead to more fragmentation and *more* routes in the medium run. (Of course, some other networks know their size perfectly well, and know that they will not grow much - like a NREN that serves universities that bring their own address space, so the NREN will likely be happy forever with a /48 for their infrastructure... (and *could* use PI for that) ) 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
On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote: Hi
I think you?re still missing the point that some of us are trying to make. I simply don?t think that the proposal is a good way of solving the problem (which is apparently part of a sentence in current policy). Adding a second /32 to the global routing table has just as much impact as splitting up a /32 in 2 /33s so there?s no gain there. And as indicated, filters that are set by people are outside the scope of the address policy WG, and arguably also outside the scope of RIPE policy.
I don't agree with that. People tend to believe RIPE NCC (which is good). And if RIPE NCC publish in RIPE-447 that the longest prefix is /32, then this is the solid message on which one can easily setup filters with that prefix. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hello, -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Piotr Strzyzewski Sent: donderdag 16 april 2009 10:46 To: Remco van Mook Cc: Jerzy Pawlus; leo.vegoda@icann.org; marcoh@marcoh.net; gajda@man.poznan.pl; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote: Hi
I think you?re still missing the point that some of us are trying to make. I simply don?t think that the proposal is a good way of solving the problem (which is apparently part of a sentence in current policy). Adding a second /32 to the global routing table has just as much impact as splitting up a /32 in 2 /33s so there?s no gain there. And as indicated, filters that are set by people are outside the scope of the address policy WG, and arguably also outside the scope of RIPE policy.
I don't agree with that. People tend to believe RIPE NCC (which is good). And if RIPE NCC publish in RIPE-447 that the longest prefix is /32, then this is the solid message on which one can easily setup filters with that prefix. Piotr =================== And don't forget all the systems that filter based on route objects in the RIR databases. So it should be allowed/possible to create route object for everything with more IPs as a /48 if you ask me. If you are required to aggregate it into 1 /32 if you have PA space there will be filters that check it and require it to be a /32 or refuse it at all. Please note that this requirement is by RIPE policy the case at this moment if I am correct. Just my 0.2 cents. Regards, Mark
Hi, On Thu, Apr 16, 2009 at 11:05:38AM +0200, Stream Service wrote:
And don't forget all the systems that filter based on route objects in the RIR databases. So it should be allowed/possible to create route object for everything with more IPs as a /48 if you ask me.
This is very well possible. The RIPE database permits route6: objects of any size, as long as they fit into your inet6num: object (so you can't create a /30 route if you only have a /32 inet6num, but you can perfectly well create a /40 route). So, please, get your facts right - heating up the discussion based on incorrect information isn't helping us to figure out how the new policy should look like. 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 Jerzy, On 16/04/2009 1:11, "Jerzy Pawlus" <Jerzy.Pawlus@cyf-kr.edu.pl> wrote: [...]
How do you solve this at the moment iin IPv4-land ?
Good question. Isn't the normal answer to open a separate LIR for the separate business unit?
Your solution, although possible, has some drawbacks:
It adds administrative burden, this was discussed here.
True. I think that administrative burden would act as a restraint against unnecessary additional allocations.
But it also will diminish the remaining unallocated IPv4 space.
How does it do that at a different rate than not opening a new LIR? While I understand that the proposal requires a one-to-one relationship between IPv4 and IPv6 networks, my reading of the text was that the requirement was there to ensure that a separate IPv6 network was required. If someone has opened a new LIR then I suspect that separate test is not required.
I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category. This, plus requirement of seperate routing policy may convince people to support the new policy.
While I agree that this proposal could have a negative financial impact on the RIPE NCC I don't believe that we can change the charging scheme through the policy development process. Finally, if a network running an LIR closes the address space will naturally be reclaimed after the RIPE NCC's due diligence process. This proposal seems to put a burden on an LIR to remember to return space once it is not being used. Experience suggests that resources get lost as people move around between departments and companies. If the general concept is accepted I think a strong regular review mechanism is required to ensure that we don't leave a mess of unmanaged resources lying around in the RIPE database. Regards, Leo
On 16 apr 2009, at 10:11, Jerzy Pawlus wrote:
I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category.
Let's not do that, as it would simply reduce the whole policy to you get as much addresses as you can afford instead of you get the addresses you need. Skipping HD-ratio in favor of scoring units is bad, very bad. Groet, MarcoH
On Thu, Apr 16, 2009 at 04:18:34PM +0200, Marco Hogewoning wrote:
On 16 apr 2009, at 10:11, Jerzy Pawlus wrote:
I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category.
Let's not do that, as it would simply reduce the whole policy to you get as much addresses as you can afford instead of you get the addresses you need. Skipping HD-ratio in favor of scoring units is bad, very bad.
Which is what we have right now. Setup new (another) LIR (money). Get allocation. Merge LIRs (or not). Which is: "you get as much address as you can afford". Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 16 apr 2009, at 16:23, Piotr Strzyzewski wrote:
On Thu, Apr 16, 2009 at 04:18:34PM +0200, Marco Hogewoning wrote:
On 16 apr 2009, at 10:11, Jerzy Pawlus wrote:
I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category.
Let's not do that, as it would simply reduce the whole policy to you get as much addresses as you can afford instead of you get the addresses you need. Skipping HD-ratio in favor of scoring units is bad, very bad.
Which is what we have right now. Setup new (another) LIR (money). Get allocation. Merge LIRs (or not). Which is: "you get as much address as you can afford".
In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 would equally apply to IPv6 as it does to IPv4. Groet, MarcoH (trimmed the CC a bit to avoid duplicates)
On Thu, Apr 16, 2009 at 04:33:10PM +0200, Marco Hogewoning wrote:
In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 would equally apply to IPv6 as it does to IPv4.
First of all, one doesn't have to close/merge LIR if "can afford" it. Moreover, existing LIR can (there is simplification here): 1. setup new LIR (withing the same organization; for example in another country, part of country, with different funds, etc.), 2. send RIPE-425 form, 3. obtain another allocation (probably /32). I assume, that in most cases this first IPv6 allocation is more than enough and HD-ratio in this scenario is not used. Note that there are organizations which (ab)use the current policy using that method just to obtain another "initial" allocation and this is exactly "you get as much address as you can afford" which is not a good policy. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Apr 16, 2009, at 6:07 PM, Piotr Strzyzewski wrote:
On Thu, Apr 16, 2009 at 04:33:10PM +0200, Marco Hogewoning wrote:
In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 would equally apply to IPv6 as it does to IPv4.
First of all, one doesn't have to close/merge LIR if "can afford" it. Moreover, existing LIR can (there is simplification here): 1. setup new LIR (withing the same organization; for example in another country, part of country, with different funds, etc.), 2. send RIPE-425 form, 3. obtain another allocation (probably /32). I assume, that in most cases this first IPv6 allocation is more than enough and HD-ratio in this scenario is not used. Note that there are organizations which (ab)use the current policy using that method just to obtain another "initial" allocation and this is exactly "you get as much address as you can afford" which is not a good policy.
Then maybe this is another hole that needs plugging, but I think we have to realise that we problem won't solve all of the world's problems right here and now. As Leo already suggested, opening up a new LIR will introduce some burden in the form of costs and overhead which will probably make people think twice about what they are doing and wether or not it is absolutely neccessary. Further that new LIR has to comply with the normal procedures and policies, which makes me think that this might help to achieve goals like fairness, registration and traceabillity. So yes, I understand your problem and I'm happy to voice my support for a proposal to solve it, as long as it is a good one and IMHO this isn't such a proposal. In the past few days various other solutions have been posted: - Open a second LIR - Use PI (in the works) - sub-allocated from the initial /32 (Like RIPE-449 allows for IPv4) And in fact we can even start a debate wether or not the current document (RIPE-450), although stating you MUST announce the allocated prefix as a whole, forbids you from deaggregating and announcing more specifics for that allocation as well. And yes this will put some additional strain on the routing table and create some extra BGP noise, but the same applies for the original concept of allocating an additional /32. The other big objections I read are concerning the filters. Routabillity of address blocks (any address block) is as always not guarenteed and routing policy for individual networks is way out of scope for this WG or the RIPE NCC as a whole. Maybe you should follow up to the IETF and draft a BCP on IPv6 route filtering, otherwise I guess the market will eventually solve it, if it turns out to really be a problem, and alter the filters. In the meantime the original proposal slipped into one where HD-ratio is being traded for scoring points. Call me old-fashioned, conservative or other, but I think that, although IPv6 'provides enough address space to last us a lifetime', we should still keep those old values like address space conservation and a fair and level playing field to distribute them in mind when creating or applying policies. To me a large part of what you are saying, in v4 land can would be put under 'administrative ease' which by RIPE-449 is not a valid reason for assignment and I personally don't see reasons to allow it for IPv6 even when it's not explicitly stated in the policy document. If somebody wants to rewrite this proposal, taking the comments made on this list into account or if you want to draft a new one, seeking another solution for this problem, I'm happy to help and make some time available. As it currently stands I cannot voice support for this proposal and it's very unlikely that this will happen in the future, unless changes are made. Greetings, MarcoH
Marco wrote: [...]
As Leo already suggested, opening up a new LIR will introduce some burden in the form of costs and overhead which will probably make people think twice about what they are doing and wether or not it is absolutely neccessary.
I can assure you that the burden of opening up a new LIR is nothing in comparison to maintaining a seperate routing policy up to the client. It costs additional money and an expertise and nobody sane will willingly do it. So raising up this as an argument that it will stop people from opening up a new LIR is probably meaningless. ---- I only state that the current RIPE policy will not stand. Either the 5.1.1 shall be removed or 5.2.1 modified. The policy, in my opinion, is and was in the past more restrictive than equivalent IPv4 policy. Lets just recall 200 clients rule or lack of IPv6 PI space. In its current form it is harmful to IPv6 deployment. So far we have seen only two groups interested in changing it, but the others will follow when they try to bring IPv6 into production. In it simplest: Under current policy some LIRs cannot offer the same set of services they used to offer in IPv4, and IPv6 was supposed to offer new oportunities. ---- [...]
The other big objections I read are concerning the filters. Routabillity of address blocks (any address block) is as always not guarenteed and routing policy for individual networks is way out of scope for this WG or the RIPE NCC as a whole. Maybe you should follow up to the IETF and draft a BCP on IPv6 route filtering, otherwise I guess the market will eventually solve it, if it turns out to really be a problem, and alter the filters.
But we also cannot create a policy for policy itself. It must respect a real life scenario too. Of course "Routabillity of address blocks (any address block) is as always not guarenteed" but as practise shows most "legally" obtained legacy prefixes are still routable and special rules for some IPv4 ranges are generally accepted. I am afraid you can't say the same for a more specific /32 PA prefix. [...]
To me a large part of what you are saying, in v4 land can would be put under 'administrative ease' which by RIPE-449 is not a valid reason for assignment and I personally don't see reasons to allow it for IPv6 even when it's not explicitly stated in the policy document.
It is not 'administrative ease'. It is be or not to be. Regards, Jurek
On 17 apr 2009, at 11:42, Jerzy Pawlus wrote:
---- I only state that the current RIPE policy will not stand. Either the 5.1.1 shall be removed or 5.2.1 modified. The policy, in my opinion, is and was in the past more restrictive than equivalent IPv4 policy. Lets just recall 200 clients rule or lack of IPv6 PI space.
I find it less restrictive, administrative ease is allowed and you'll always get a /32.
In its current form it is harmful to IPv6 deployment. So far we have seen only two groups interested in changing it, but the others will follow when they try to bring IPv6 into production.
Please stop this nonsense, you find a ton of reasons why IPv6 isn't deployed and I don't see proof that changing the policy actually caused an increase in IPv6 addoption. Surely somebody probably got himself a /32, which by now is gathering dust somewhere being bound to null0.
In it simplest: Under current policy some LIRs cannot offer the same set of services they used to offer in IPv4, and IPv6 was supposed to offer new oportunities.
Yes agian, we here you....it's not the problem that is bothering me, it's the proposed solution.
The other big objections I read are concerning the filters. Routabillity of address blocks (any address block) is as always not guarenteed and routing policy for individual networks is way out of scope for this WG or the RIPE NCC as a whole. Maybe you should follow up to the IETF and draft a BCP on IPv6 route filtering, otherwise I guess the market will eventually solve it, if it turns out to really be a problem, and alter the filters.
But we also cannot create a policy for policy itself. It must respect a real life scenario too. Of course "Routabillity of address blocks (any address block) is as always not guarenteed" but as practise shows most "legally" obtained legacy prefixes are still routable and special rules for some IPv4 ranges are generally accepted. I am afraid you can't say the same for a more specific /32 PA prefix.
I have had to lower my filters in the past a few times after complaints from customers and I guess I'm not the only one, at the same time I have had boxes which not even accepted /24 as a general rule because of memory shortage. That's what I meant by 'let the market do it's work'.
[...]
To me a large part of what you are saying, in v4 land can would be put under 'administrative ease' which by RIPE-449 is not a valid reason for assignment and I personally don't see reasons to allow it for IPv6 even when it's not explicitly stated in the policy document.
It is not 'administrative ease'. It is be or not to be.
We'll I've been running networks in the same situation, one company with 2 policies and 2 ASns which from time to time didn't touch eachother and I'm still here :) Groet, MarcoH
Marco wrote: [...]
I find it less restrictive, administrative ease is allowed and you'll always get a /32.
As you will always get a minimum allocation slot for IPv4. So you can't say it is less restrictive. The problem with /32 is that it is too big and 99% of LIR's will never approach to HD-Ratio. So in the future IPv6 table you will have a few thousand of PA prefixes and possible ten's of thousand PI prefixes. Certainly we can spare a few hundred additional PA prefixes for the new policy. Regards, Jurek
The problem with /32 is that it is too big and 99% of LIR's will never approach to HD-Ratio. So in the future IPv6 table you will have a few thousand of PA prefixes and possible ten's of thousand PI prefixes. Certainly we can spare a few hundred additional PA prefixes for the new policy.
If a /32 is 'too big,' then I am yet to be convinced that more of them in the routing table is the answer as opposed to /33s, /34s, /35s or /36s. Maybe I'm just not 'thinking IPv6.' Filtering guidelines change. Just because a /32 is what people filter on at the moment, it doesn't mean that is the way it should remain. Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
It is really amazing how many unqualified comments I saw on this during the last couple of days. Seems that a lot of people on this list just see an incredible small slice of the net and believe they see the whole internet. Good luck to all those which plan to use PI space for their services and also to all those which believe they can get an IPv6 PA smaller /32 routed through all T1 ISPs. You'll sooner or later face some serious problems in the IPv6 world (if you even participate in that at all). Anyway, for me it does not matter whether this proposal gets through or not. We have a workaround and that covers us for the coming years. - I wanted to prevent others from being forced the same ugly road too but I leave it to those ISPs to get that process/rules fixed when they face the problem. I'll remove my self from this list. Dani Rueegg
On Wed, Apr 15, 2009 at 10:54:38AM +0200, Remco van Mook wrote:
I'm sorry but that goes back to my previous e-mail - a request for an AS is a request for an AS and I don't see how that should be related in any way to
So, as I understand, are you going to say, that RIPE NCC is assigning more than one/few ASNs to the same unique LIR just "for free"? If not (I hope so ;-) ), why we couldn't base new policy (IPv6 allocations) on other solid policy and practice (ASN assignments)? It's like in math - you must (or at least should ;-) ) base one thing on another. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
* Piotr Strzyzewski:
We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification).
This is more IETF material, IMHO. There could be a magic /5 which contains a /32 for every 27-bit AS number, and a magic /16 with a /48 for every 32 bit AS number. RIRs are only needed to handle the reverse delegation. In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Either that or a global policy proposal to use a /4 to automatically allocate a /32 to every 28-bit AS (maximizing the potential here :) - that should keep everybody happy and remove the need for the RIRs to be involved with all but the largest IPv6 requirements. Future generations might ask why we wasted all this space linking it to AS-numbers but at least it will then be in a block that can be easily filtered. Not that I¹d support that proposal, either. We¹ve already wasted quite enough bits of IPv6 space in policy, IMHO. Remco On 15-04-09 11:16, "Florian Weimer" <fweimer@bfk.de> wrote:
* Piotr Strzyzewski:
We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification).
This is more IETF material, IMHO. There could be a magic /5 which contains a /32 for every 27-bit AS number, and a magic /16 with a /48 for every 32 bit AS number. RIRs are only needed to handle the reverse delegation.
In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
* Remco van Mook:
Either that or a global policy proposal to use a /4 to automatically allocate a /32 to every 28-bit AS (maximizing the potential here :) - that should keep everybody happy and remove the need for the RIRs to be involved with all but the largest IPv6 requirements.
Note that the RIRs still need to handle reverse delegations (more so with DNSSEC; without DNSSEC, you can use magic addresses). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Wed, Apr 15, 2009 at 11:16:13AM +0200, Florian Weimer wrote:
In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go.
From the proposal: "According to the IPv6 policy an IPv6 allocation must be announced as one prefix." There is more than one (filters) problem.
Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
* Florian Weimer
In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go.
But you can't build your long term business plan on that assumpion There will be be some who would filter it. Jurek
People can also filter all ASNs ending with the digit 4. There¹s no policy against it. Doesn¹t make it less stupid, though. Remco On 15-04-09 11:37, "Jerzy Pawlus" <Jerzy.Pawlus@cyf-kr.edu.pl> wrote:
* Florian Weimer
In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go.
But you can't build your long term business plan on that assumpion There will be be some who would filter it.
Jurek
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
On Wed, Apr 15, 2009 at 11:43:46AM +0200, Remco van Mook wrote:
People can also filter all ASNs ending with the digit 4. There?s no policy against it. Doesn?t make it less stupid, though.
And guess what is more probable. Be realistic. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
People can also filter all ASNs ending with the digit 4. There=B9s no policy against it. Doesn=B9t make it less stupid, though.
Yes they can, but they certeinly will if it contradics offical RIPE policy Jurek
* Jerzy Pawlus:
In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go.
But you can't build your long term business plan on that assumpion There will be be some who would filter it.
There's no long-term guarantee of routability for /32s, either. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
There's no long-term guarantee of routability for /32s, either.
This is interesting. Could you give a time frame? Jurek
* Jerzy Pawlus:
There's no long-term guarantee of routability for /32s, either.
This is interesting. Could you give a time frame?
Malfunction due to more or less unforeseen routing table growth. Some operators might think that your prefix/ASN has no place on their network. We've seen it with IPv4 from time to time. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
We've seen it with IPv4 from time to time.
Indeed - I remember seeing it many years ago on a FreeBSD box running bgpd which fell over when the number of kernel routes exceeded 2^16. Ray
Remco van Mook wrote:
Hang on a second. This is now devolving into a proposal where you can get a separate AS and /32 for every customer your LIR serves and I will definitely not support that. I want a pony, too.
Remco
But I do not need any new AS.The current policy for getting AS number is fine for me! I only need to announce a "production quality" IPv6 allocation which is /32 within each AS I have. And I am in ONE geographical location. Can this policy take care of me (and not only me)? So I only recommend to remove this statement about "unconnected geographical areas" because this reflect only some too narrow LIRs' situation. Best regards, Bartek
On 15-04-09 10:08, "Bartek Gajda" <gajda@man.poznan.pl> wrote:
Marco Hogewoning wrote: > > On 14 apr 2009, at 14:57, Ingrid Wijte wrote: > >> PDP Number: 2009-05 >> Multiple IPv6 /32 Allocations for LIRs >> >> Dear Colleagues >> >> A new RIPE Policy Proposal has been made and is now available for >> discussion. > Summary of Proposal: > This is a proposal to allow an LIR operating separate networks in > unconnected geographical areas to receive multiple /32 IPv6 allocations.
This policy is a must-have policy for hundreds of thousand users in my county and more than 20 LIRs. However there is a strong limitation for me in this policy, because we are using at least two different policies but within ONE single geographical areas. The differences in routing policies are not because of different geographical areas but because of different kind of customers we are serving. Currently we have to divide single /32 into multiple pieces and announce them under different ASs we have, which weak but the only possible solution. We do not have any chance to get a second /32 from RIPE so far.
It would be really helpful to reflect this real life situation in single policy like this one. So after removing the part about "different unconnected geographical areas" this policy will get strong support from LIRs I'm writing about.
Best regards, Bartek Gajda
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
On Tue, Apr 14, 2009 at 03:53:46PM +0200, Marco Hogewoning wrote:
and secondly doesn't this open up the path to /32 per AS instead to / 32 per LIR ?
And is there anything wrong with that? I clearly understand the conservation goal, but to be honest - is there any problem with (for example) 1k more /32s which could be allocated under that policy? I sometimes personally wonder if we are going to promote ipv6 or not by using too strict policies. And yes - i know the history of ipv4. ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce@ripe.net Cc: address-policy-wg@ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi Remco, I'm not sure where you see that a second AS would allow a LIR to get a second /32. I'm happy to reword the Policy Text but I think it already specifies the rule: "...separate AS number and a unique routing policy..." The unique routing policy implies that the two AS will have different peering relations so are operated as two different networks. I'm happy to add a sentence about peering too it that makes it clear. I agree to the comment Marco wrote. It would make sense to specify a time-line by when a low used /32 has to be returned after AS have merged together. Dani -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Remco van Mook Sent: Tuesday, April 14, 2009 5:01 PM To: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce@ripe.net Cc: address-policy-wg@ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hi Daniel, The 'unique routing policy' is already a requirement to get a second (or any subsequent) AS as far as I know, so it doesn't really add any limitation. Best, Remco -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Rueegg, Daniel Sent: dinsdag 14 april 2009 17:23 To: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Hi Remco, I'm not sure where you see that a second AS would allow a LIR to get a second /32. I'm happy to reword the Policy Text but I think it already specifies the rule: "...separate AS number and a unique routing policy..." The unique routing policy implies that the two AS will have different peering relations so are operated as two different networks. I'm happy to add a sentence about peering too it that makes it clear. I agree to the comment Marco wrote. It would make sense to specify a time-line by when a low used /32 has to be returned after AS have merged together. Dani -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Remco van Mook Sent: Tuesday, April 14, 2009 5:01 PM To: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce@ripe.net Cc: address-policy-wg@ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
Hello Remco, On Tue, Apr 14, 2009 at 05:36:09PM +0200, Remco van Mook wrote:
The 'unique routing policy' is already a requirement to get a second (or any subsequent) AS as far as I know, so it doesn't really add any limitation.
Oh yes it does add limitation to a number of AS assigned by RIPE NCC to a given LIR. Recently I faced it. There has to be solid unique routing policy reason. Jakub Jermak -- - Jakub Jermak Silesian University of Technology - jermak@polsl.pl (JJ1214-RIPE) Akademicka 16, 44-100 Gliwice, Poland - PGP: http://hydra.ck.polsl.pl/~jermak phone: +48 32 230-76-86
Hi There has been similar informal proposal issued by me and my collegues during RIPE-54. The proposal and presentation could be seen here: http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_Subsequent_Allo... Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 14 apr 2009, at 14:57, Ingrid Wijte wrote:
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
There is a need of changing ripe-450. There are some LIR's which have more than one routing policy. This was possible with IPv4 and is impossible with IPv6. We are all worried about a slow deployment of IPv6 but we ourselves are slowing it down. Look, where IPv4 started. In IPv6 we want to be perfect from the beginning. It is O.K but there is a "real life" too. I will support this proposal if the reference to "different unconnected geographical areas" is removed. It is a bit unclear, and what area we have in mind? My original thought of new version of ripe-450 was: New version: --------------------- 5.2.1. Subsequent allocation criteria a) Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below. b) An LIR may request an additional minimum allocation size for a second and subsequent Autonomus System assigned to that LIR. -------------------------- Regards, Jurek P.S. Allow our children to fix something.
On 15 apr 2009, at 11:25, Jerzy Pawlus wrote:
New version:
--------------------- 5.2.1. Subsequent allocation criteria
a) Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below.
b) An LIR may request an additional minimum allocation size for a second and subsequent Autonomus System assigned to that LIR.
--------------------------
And there are basically no limitittations on getting a seperate AS number to work around a), so you might as well drop 5.2.1 completely. Groet, MarcoH
And there are basically no limitittations on getting a seperate AS number to work around a), so you might as well drop 5.2.1 completely.
Do you observe an unlimited number of requests for an AS assignment now? Jurek
On 14 Apr 2009, at 13:57, Ingrid Wijte wrote:
Multiple IPv6 /32 Allocations for LIRs
I do not support this proposal. If an org (LIR or not) needs a separate address block for routing reasons, then this should be catered for through the PI policy. PA should be aggregatable. There's a clue in the name. ;-) Andy
*Andy,
Multiple IPv6 /32 Allocations for LIRs
I do not support this proposal. If an org (LIR or not) needs a separate address block for routing reasons, then this should be catered for through the PI policy.
PA should be aggregatable. There's a clue in the name. ;-)
And guess what is more scalable. PI per client or PA per AS. Jurek
On 15 Apr 2009, at 10:57, Jerzy Pawlus wrote:
*Andy,
Multiple IPv6 /32 Allocations for LIRs
I do not support this proposal. If an org (LIR or not) needs a separate address block for routing reasons, then this should be catered for through the PI policy.
PA should be aggregatable. There's a clue in the name. ;-)
And guess what is more scalable. PI per client or PA per AS.
If I read this as "routing table slots per client" or "routing table slots per AS" then the two are broadly equivalent... Andy PS, I would like a pony too.
Hi, Andy Davidson schrieb:
On 14 Apr 2009, at 13:57, Ingrid Wijte wrote:
Multiple IPv6 /32 Allocations for LIRs
I do not support this proposal. If an org (LIR or not) needs a separate address block for routing reasons, then this should be catered for through the PI policy.
PA should be aggregatable. There's a clue in the name. ;-)
...soo... instead of announcing an aggregated /32 for say 200 customers you want 200 unaggregated say /48s in the routing table? Requesting an ALLOCATION usually means, you want to ASSIGN Subnets of the allocation to 3rd parties (internal branches, customers....). PI .. a) ..forbids "sub-assignments" b) ..means that you have to announce each PI prefix seperately even if you could aggregate it due to same routing policy Your idea only works smoothly if you really only need ONE assignment. (But then it would be the right thing to do, getting PI.) But for the record: I don't really support the proposal eiter since it's rather a workaround for the "i-can-only-annonce-a-/32-to-certain-parties"-problem mentioned earlier in the thread. I do recognize the problem though, hust hopeing someone comes up with a nicer solution to this. I have a similar problem where i have to descide upon continuing to announce /40s ("Sub-Allocations") of a /32 PA Allocation for seperate ASNs with "fallback tunnels" to the AS announcing the /32 (so i don't loose traffic from providers doing strict-RIR-filtering) - or to get ~50 PI assignments (for now, more in the future) and announce each of those seperately since i can't aggregate that. I think i have to roll dice, both is somewhat ridiculous in the end<...> And no, none of those ASNs wants to become a LIR in their own right due to multiple reasons beyond the scope of this mail (let's call it "reality"). -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Sascha Lenz writes:
I don't really support the proposal eiter since it's rather a workaround for the "i-can-only-annonce-a-/32-to-certain-parties"-problem mentioned earlier in the thread. I do recognize the problem though, hust hopeing someone comes up with a nicer solution to this.
Time is running faster and faster. Perhaps we can put a time limit to "Multiple IPv6 /32 Allocations for LIRs" Jurek
Sascha Lenz writes:
I have a similar problem where i have to descide upon continuing to announce /40s ("Sub-Allocations") of a /32 PA Allocation for seperate ASNs with "fallback tunnels" to the AS announcing the /32 (so i don't loose traffic from providers doing strict-RIR-filtering) - or to get ~50 PI assignments (for now, more in the future) and announce each of those seperately since i can't aggregate that.
We all have similar problems and think how much time we wasted on finding solution. Jurek
Hi, On Tue, Apr 14, 2009 at 02:57:40PM +0200, Ingrid Wijte wrote:
PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs
let me try to summarize the discussion so far: - (some/most) people acknowledge that there is a need for a number of network operators to run two distinct networks - for different reasons, be it "commercial" vs. "national research network", or be it "different country networks for large multinational ISPs". - the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording) - the main issue right now seems to be the definition of criteria, under which circumstances a LIR can be eligible to receive further /32s - tieing this criteria to the 'the LIR has multiple AS numbers' is seen as problematic, because it could lead to "if we can't get the address space we want, we sneak it through the 'AS number' backdoor" I do not think that "waste of addresses" is the primary issue we should worry about, at least not when talking about a few thousand extra /32s (out of a billion). "Routing table slots" is something we need to be careful about, and "fairness and clear rules", and "make IPv6 workable". So I think this discussion should move towards: - find examples of networks that have problems with the current policy, and try to figure out common criteria - formulate criteria for "additional allocations" that can get (rough) consensus - re-word the policy proposal accordingly 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
Gert,
So I think this discussion should move towards:
- find examples of networks that have problems with the current policy, and try to figure out common criteria
Can anybody (maybe from a RIPE staff) give a number of LIR's with more than one AS assigned? This can give us a rough estimate. Jurek
Hi, On Wed, Apr 15, 2009 at 04:43:04PM +0200, Jerzy Pawlus wrote:
So I think this discussion should move towards:
- find examples of networks that have problems with the current policy, and try to figure out common criteria
Can anybody (maybe from a RIPE staff) give a number of LIR's with more than one AS assigned? This can give us a rough estimate.
Not for the paragraph you quoted. Currently, AS numbers are used with PA blocks, PI space, sub-allocations of PA blocks, etc. I was asking specifically for real-world examples of networks that cannot operate with "a single PA block (plus a number of PI blocks for customers) per LIR". IPv6 PI does not exist today, but is likely going to exist in a few months (the IPv6 PI proposal passed last call and is currently in WG chairs last call). Gert Doering -- NetMaster -- 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
Can anybody (maybe from a RIPE staff) give a number of LIR's with more than one AS assigned? This can give us a rough estimate.
There are also companies like us who have a dozen or more LIR's. Some of those LIRs might only have one AS. It's not necessarily easy for RIPE or anyone else to figure out which LIRs belong to the same organization. It is risky to make assumptions based on trawling the RIPE database because it is: a) a warped and incomplete view b) historical information We don't really know how closely IPv6 networks will resemble IPv4 networks. Of course, many organizations will come up with some network transition plan that mirrors their IPv4 networks onto IPv6, but there will also be innovators who do something completely different. When other organizations begin to copy the innovators, it is a whole new environment. IPv6 makes it much easier to create push-type services like phone-ringing and it is hard to predict the impact of such services. For example, the simply ability to make a telephone ring in your house, created a huge increase in demand for telephones, far beyond the demand created by merely transmitting sound over the wire. Many of the original telephone services faded away completely, once phone-ringing was invented, and nowadays, the only people who know about services other than telephone calls, are the people who read books on telephone history. RIPE policy on IPv6 needs to avoid being restrictive, and if we have accidentally made the policy restrictive, or if too many people mistakenly interpret the policy as being restrictive, then we need to change it. --Michael Dillon
On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote:
- the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording)
I think this would be most easily solved by removing the condition that each /32 must be announced as such. In my opinion an "address allocation/ assignment" policy is not supposed to make routing decisions anyway.
On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote:
- the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording)
I think this would be most easily solved by removing the condition that each /32 must be announced as such. In my opinion an "address allocation/ assignment" policy is not supposed to make routing decisions anyway.
This is acceptable solution, however it leaves more space to "uncontrolable deaggregation". The net result will be more inconsistent filters. Jurek
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jerzy Pawlus Sent: woensdag 15 april 2009 16:48 To: lists-ripe@c4inet.net Cc: gert@space.net; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote:
- the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording)
I think this would be most easily solved by removing the condition that each /32 must be announced as such. In my opinion an "address allocation/ assignment" policy is not supposed to make routing decisions anyway.
This is acceptable solution, however it leaves more space to "uncontrolable deaggregation". The net result will be more inconsistent filters. Jurek --------------------- Just make it policy that it shouldn't be smaller as a /48. This will reduce it a little bit, also requesting to aggregate where possible should be fine I guess. Mark
Hi, On Wed, Apr 15, 2009 at 04:41:56PM +0100, lists-ripe@c4inet.net wrote:
On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote:
- the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording)
I think this would be most easily solved by removing the condition that each /32 must be announced as such. In my opinion an "address allocation/ assignment" policy is not supposed to make routing decisions anyway.
The current policy requires announcement of the aggregate, but does not forbid announcements of more-specifics. Whether or not more-specifics *work*, as in "all important peers accept your routes", is not something the APWG can decide. 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, On Wed, Apr 15, 2009 at 04:59:32PM +0200, Gert Doering wrote:
The current policy requires announcement of the aggregate, but does not forbid announcements of more-specifics.
Announcing the aggregate falls down in the "disconnected networks" case, though.
Whether or not more-specifics *work*, as in "all important peers accept your routes", is not something the APWG can decide.
There's not even a guarantee that a /32 (or more that one, fwiw) are going to be accepted. Who knows what people put in their filters? Regards, Sascha Luck
Hi, On Wed, Apr 15, 2009 at 05:12:45PM +0100, lists-ripe@c4inet.net wrote:
On Wed, Apr 15, 2009 at 04:59:32PM +0200, Gert Doering wrote:
The current policy requires announcement of the aggregate, but does not forbid announcements of more-specifics.
Announcing the aggregate falls down in the "disconnected networks" case, though.
This is why we need to see specific examples of networks having problems with the current policy. To make more educated decisions about what problems we are trying to solve. 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
Gert wrote:
So I think this discussion should move towards:
- find examples of networks that have problems with the current policy, and try to figure out common criteria
Gert, I don't think that at the moment we can find more examples other than you mentioned in your letter, ie. Telcos and NREN networks. To some extent it understandable. Big ISP need more time to prepare themselves, especially in the access area. NREN networks tend to see problems rather sooner than later. Others will follow as Dami said "when they face the problem". On the other hand the interest in and discussion on this matter is surpisingly small.
- formulate criteria for "additional allocations" that can get (rough) consensus
As you clearly stated in one of your letters it almost impossible to apply HD-Ratio to a big ISP. To succesfully run such a business you must assume some hierarchy in addressing scheme. Any hierarchy leads to address waste anf if you stick to this you will never reach HD-Ratio. This is a 'real life' If not to big ISP where else we can apply HD-ratio? Other LIRs will never reach it. The conclusion is rather surpising. We can silently drop HD-Ratio criteria and nothing wrong will happen. In IPv6 world HD-Ratio seems not to work as well as in IPv4 The only criteria which is meaningfull to me is: "The routing reason" whatever it means. Maybe we can leave it to the hostmaster staff to decide whether subsequent allocations are justifiable. They earned our trust. For the beginning they can apply this to those LIR's which already use separate routing polices in IPv4 world.
- re-word the policy proposal accordingly
We can have something like this: --- 5.2.1. Subsequent allocation criteria: a) An LIR may request an additional minimum allocation size for a second and subsequent separate routing policy. b) Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below. --- We can leave point b) in a case somebody reaches the HD-Ratio :) The policy does not have to be perfect. It was changed several times and it will be changed again. At worst we will end up with a few fundered additional IPv6 prefixes which is insignificant to what we have in IPv4 now. Kind regards, Jurek
Hi Jerzy, On 17/04/2009 6:27, "Jerzy Pawlus" <Jerzy.Pawlus@cyf-kr.edu.pl> wrote: [...]
Maybe we can leave it to the hostmaster staff to decide whether subsequent allocations are justifiable. They earned our trust.
I think it would be unfair on the RIPE NCC to do this to it. I agree that its staff are both competent and trustworthy but I think that giving them this responsibility would put them in a very awkward position. The RIPE NCC has to implement the policies set by RIPE - but unless the policy is clearly described and documented RIPE is effectively giving the RIPE NCC the task of deciding on the policy each and every time it evaluates a request. Perhaps more importantly, if the RIPE NCC is asked to do this on a case-by-case basis the policy ceases to be consistent, open and transparent, unless the details of the requests are published. It also puts the RIPE NCC at risk of claims that it didn't act in a neutral and impartial way towards all applicants. I can see that some network operators have a genuine problem but I don't think this option would hold water for long. Regards, Leo
Hi, On Fri, Apr 17, 2009 at 03:27:11PM +0200, Jerzy Pawlus wrote:
So I think this discussion should move towards:
- find examples of networks that have problems with the current policy, and try to figure out common criteria
Gert, I don't think that at the moment we can find more examples other than you mentioned in your letter, ie. Telcos and NREN networks. To some extent it understandable. Big ISP need more time to prepare themselves, especially in the access area. NREN networks tend to see problems rather sooner than later. Others will follow as Dami said "when they face the problem". On the other hand the interest in and discussion on this matter is surpisingly small.
Actually, "Big Telcos" and "NRENs" seem to be able to work with the current IPv6 policy fairly well. "Big Telcos" seem to be able to get up to a /20, and I see a number of NRENs with IPv6...
- formulate criteria for "additional allocations" that can get (rough) consensus
As you clearly stated in one of your letters it almost impossible to apply HD-Ratio to a big ISP. To succesfully run such a business you must assume some hierarchy in addressing scheme. Any hierarchy leads to address waste anf if you stick to this you will never reach HD-Ratio. This is a 'real life'
Please read up on how HD ratio works. The whole point about HD ratio is to handle the additional waste caused exactly due to *hierarchy* in addressing. IPv4 has a fixed 80% usage ratio. IPv6 is much more flexible here.
If not to big ISP where else we can apply HD-ratio? Other LIRs will never reach it. The conclusion is rather surpising. We can silently drop HD-Ratio criteria and nothing wrong will happen. In IPv6 world HD-Ratio seems not to work as well as in IPv4
I don't understand what you are trying to tell us. There is no HD-ratio in IPv4. There is HD-ratio in IPv6 (and whether it works or not remains to be seen, as I don't know any ISP that has filled up his IPv6 allocation and has come back to the RIPE NCC for more space). 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, [...]
Please read up on how HD ratio works. The whole point about HD ratio is to handle the additional waste caused exactly due to *hierarchy* in addressing.
Sorry, I have stopped reading Appendix A Of the http://www.ripe.net/ripe/docs/ripe-450.html when I saw it referring to HD-Ratio equal to 0.94. There is another paragraph that says that it is equal to 0.8 [...]
I don't understand what you are trying to tell us. There is no HD-ratio in IPv4. There is HD-ratio in IPv6 (and whether it works or not remains to be seen, as I don't know any ISP that has filled up his IPv6 allocation and has come back to the RIPE NCC for more space).
My point was that it is doubtfull that we will ever see an LIR reaching HD-Ratio. Regards, Jurek
participants (20)
-
Andy Davidson -
Bartek Gajda -
Florian Weimer -
Gert Doering -
Ingrid Wijte -
Jakub Jermak -
Jerzy Pawlus -
Leo Vegoda -
lists-ripe＠c4inet.net -
Marco Hogewoning -
michael.dillon＠bt.com -
Piotr Strzyzewski -
Ray.Bellis＠nominet.org.uk -
Remco van Mook -
Remco van Mook
-
Rob Evans -
Rueegg, Daniel -
Sascha Lenz -
Stream Service -
Tomasz Klicki