2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote:
This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05
Just because of "It no longer provides for IXPs that need more than a /23 of IPv4 space" I am against this proposal. Denis
Denis Fondras wrote on 29/05/2019 14:11:
On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote:
This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05
Just because of "It no longer provides for IXPs that need more than a /23 of IPv4 space" I am against this proposal.
Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy? /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties. Nick
On 29/05/2019 15:41, Nick Hilliard wrote:
Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy?
Agreed! Any historical data/graphs are a welcomed addition to the discussion.
/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties.
20 is very accurate. Roughly the same number when using PeeringDB as data source to do the math. [Connected networks to IXP Lan] ``` curl -snGL -X GET https://peeringdb.com/api/netixlan \ --data-urlencode fields=ix_id,name,ixlan_id | \ jq '.data | group_by(.ixlan_id) | map({"count":length,"data":(unique_by(.ixlan_id)[])}) | sort_by(-.count)' ``` Christoffer
Dear Nick, all, On 29 May 2019, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy?
Since September 2012, when the current IXP assignment policy came into effect, the RIPE NCC has issued 1x /22 and 3x /23 assignments to IXPs. Prior to this policy becoming active we had received specific requests from IXPs (for IP blocks not restricted to be used exclusively for their peering LANs). From these requests: - 23 were approved with a size of /23 - 1 with a size of /23,/24 - 9 with a size of /22 - 1 with a size of /23,/23,/24 Finally please note that, as some IXPs are also LIRs, they can use parts of their IPv4 allocations for their peering LANs (i.e. referring to some IP blocks larger than a /22 that have been mentioned in this thread). These are not considered as direct IXP assignments. I hope this helps. Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC
On 29 May 2019, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
Denis Fondras wrote on 29/05/2019 14:11:
On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote:
This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 Just because of "It no longer provides for IXPs that need more than a /23 of IPv4 space" I am against this proposal.
Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy?
/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties.
Nick
Consulting the PCH IXP directory as Nick did earlier (as well as the Euro-IX one), I think it is also reasonable to say that allocating a /24 is ambitious for the overwhelming majority of cases. Only 64 of listed IXPs have equal to, or more than, 100 participants, out of 958 IXPs, or about 6.6%. In this light, perhaps the default allocation discussed in 6.1.4 should go down to a /25. Looking at the the other end, it's not clear to me as to why an applicant cannot get more than a /23, if there is strong evidence necessitating it. To throw some random numbers as an example, this could be by demonstrating 70%-80% use of their current pool and submitting projected and historical growth rate data. Lastly, 6.1.2 mentions that "other uses are forbidden". Policies looking to enforce certain conditions are only meaningful if there is a framework for: a) Monitoring policy violations with accompanying documentation describing frequency, methodology etc. b) Describing disciplinary actions Kind regards, Aris
Aris Lambrianidis wrote on 04/06/2019 18:03:
Consulting the PCH IXP directory as Nick did earlier (as well as the Euro-IX one), I think it is also reasonable to say that allocating a /24 is ambitious for the overwhelming majority of cases.
Only 64 of listed IXPs have equal to, or more than, 100 participants, out of 958 IXPs, or about 6.6%.
In this light, perhaps the default allocation discussed in 6.1.4 should go down to a /25.
/25 is too small, even for smaller IXPs. ~400-500 of the entries in the PCH IXP directory are defunct. For the remainder, the participant numbers are inaccurate, mostly on the low side. A figure of about 500 active IXPs is largely corroborated by the IXP DB (650 entries, with some effectively defunct). The figure you need to look at is 50% usage rather than 100% usage. If you pin the assignment size to /25, then 50% of /25 is 64 participants, i.e. about ~20-25% of IXPs, not 6.6%. The current run-out rate for the RIPE pool is about 15k addresses per day. This means that a /16 is 4 days worth of allocations at the current rate. A /16 pool gives adequate breathing room for core internet infrastructure, with a /24 assignment size. The central question of this policy update is not the assignment size for IXPs, but whether it's worth investing 4 days out of 30 years worth of allocations in order to provide important flexibility for the internet core in the future. I'm inclined to think it is. Nick
Nick Hilliard wrote:
The central question of this policy update is not the assignment size for IXPs, but whether it's worth investing 4 days out of 30 years worth of allocations in order to provide important flexibility for the internet core in the future. I'm inclined to think it is.
I agree, and I support this policy proposal with a /24 default size. Ian Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
/25 is too small, even for smaller IXPs.
~400-500 of the entries in the PCH IXP directory are defunct. For the remainder, the participant numbers are inaccurate, mostly on the low side. A figure of about 500 active IXPs is largely corroborated by the IXP DB (650 entries, with some effectively defunct). Hmm.. why shouldn't defunct IXPs not be taken in consideration though? To me that sounds like ~400-500 IXPs requesting an allocation at some
Nick Hilliard wrote on 04/06/2019 20:17: point in time, and probably most of them not needing anything more than a /24 (or maybe less), assuming they failed in their mission. As much as I'd love to assume that all IXPs requesting allocations onwards will succeed (and thus needing more than /25 or /24), I don't think that's realistic. So I still believe averaging participants across all of the IXP entries, be it Euro-IX (probably more accurate), or even PCH, is an acceptable metric.
The central question of this policy update is not the assignment size for IXPs, but whether it's worth investing 4 days out of 30 years worth of allocations in order to provide important flexibility for the internet core in the future. I'm inclined to think it is. Agreed, and: Marco's email mentions "This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria."
IMO fine tuning the initial allocation to a /25 makes sense, if only to further the mission of the policy and extend the life of the pool. If anything, IXPs could always provide evidence as to why they need more IP space, even initially, regardless of whether it's a /24 or a /22. To summarize my point of view, having more stringent controls as to who gets what seems only reasonable, given the scarcity of the resource, but allow for flexibility, if the application is well justified. Kind regards, Aris
Aris Lambrianidis wrote on 05/06/2019 01:49:
Hmm.. why shouldn't defunct IXPs not be taken in consideration though?
Because they will have handed back their address space. The address assignment policies are explicitly designed to have a garbage collection mechanism under 2007-01. If you don't actively maintain your registration, it reverts to the registry. Nick
On 5 Jun 2019, at 11:41, Nick Hilliard <nick@foobar.org> wrote:
Because they will have handed back their address space. The address assignment policies are explicitly designed to have a garbage collection mechanism under 2007-01. If you don't actively maintain your registration, it reverts to the registry.
Nick
Sure, but consider this simplified scenario: 1. In June 2019, IXP A requests an allocation. They get a /24. 2. In June 2020, the reserved pool is exhausted. 3. In July 2020, IXP B requests allocation but can't get one due to 2. 4. Sometime in 2021 (or even later), IXP A hands over their allocation. What would IXP B do in the mean time between July 2020 and 2021 (or even later) when IXP A handed back their allocation? Of course another IXP could have handed back their address space, but this doesn't change the point made: Defaulting to a smaller allocation increases the chance (if ever so slightly) that the pool will be exhausted at a later point and thus IXP B will get an allocation in July 2020. On a smaller note, I could also tentatively argue that being able to hand over new allocations is more important to ecosystem diversity than being able to honor requests for increasing existing ones. Kind regards, Aris
Hi, I have compiled an in-depth analysis of peeringdb data. You can find a full description of the method, scripts, data and the main results on github: https://github.com/mwichtlh/address-policy-wg/ Some interesting takeaways: * Roughly 83% of all IXPs would theoretically fit into a /25. This already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At the same time, 74% of all peering LANs are /24s. Consequently, the default policy of assigning /24s has created large amounts of unused space. * Already today, more than 10% of all peering LANs are smaller or equal a /25. Having small peering LANs is not entirely unusual. * Large IXPs requiring a /23 or larger are rare (<3%). Thus, lowering the upper bound for assignments to /23 will not save large amounts of space. Conclusions: I back the proposal except for the limitation to a /23. I propose having a /21 as an upper limit with thorough checks by RIPE. Regards, Matthias On Wed, 2019-06-05 at 03:47 -0700, Randy Bush wrote:
Hmm.. why shouldn't defunct IXPs not be taken in consideration though?
Because they will have handed back their address space.
what are you trying to measure? the space utilization of current operating exchanges, or the distribution of request sizes?
randy
-- Dr.-Ing. Matthias Wichtlhuber Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber@de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne
* Matthias Wichtlhuber
I have compiled an in-depth analysis of peeringdb data. You can find a full description of the method, scripts, data and the main results on github:
Very nice work! Thank you for sharing this!
Some interesting takeaways:
* Roughly 83% of all IXPs would theoretically fit into a /25. This already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At the same time, 74% of all peering LANs are /24s. Consequently, the default policy of assigning /24s has created large amounts of unused space.
This makes me even more convinced that the default assignment size should not be set at /24, but that the assignment should be right-sized to best match the request - all the way down to the minimum assignment size. Another takeaway: looking at Figure 2 it would appear that more than 40% of IXPs would fit all their members in a /28. There are fragments as small as /29 sitting in NCC inventory. They are currently not allocatable or assignable due to the lack of any policy permitting this. I believe /29 should be minimum assignment size (and not /27 as currently proposed), as IXPs are one of the very few use cases where fragments smaller than /24 are useful. There is no reason to let these fragments rot in the NCC's cellar, if they could possibly be used by an IXP somewhere. (Just here in Norway there are four different IXPs that could make do with a /29 given their current member count: TRDIX, BIX, TIX and SIX. This is not because they are brand new or anything, they just happen to be located in regional locations where there is a limited number of potential members.) For IXPs that are about to grow out of an initial small assignment, swapping it for a larger one is doable (and the smaller they are, the less of a hassle the renumbering operation is). The policy already facilitates this (although it should probably not specify that the replacement is a /23, which the current proposal does).
I back the proposal except for the limitation to a /23. I propose having a /21 as an upper limit with thorough checks by RIPE.
I would not object to that. Tore
Dear all, I think Matthias' work aligns with my impression of the landscape: most IXPs never grow beyond 100 participants. I'd like to suggest that by default a /25 IPv4 block is assigned to IXPs requesting some space, rather than a /24. The main advantage is that the pool of available space for this purpose will last our community longer. Perhaps even as much as twice the number of IXPs can take advantage of this arrangement. Kind regards, Job On Fri, Jun 07, 2019 at 11:00:43AM +0000, Matthias Wichtlhuber wrote:
Hi,
I have compiled an in-depth analysis of peeringdb data. You can find a full description of the method, scripts, data and the main results on github:
https://github.com/mwichtlh/address-policy-wg/
Some interesting takeaways:
* Roughly 83% of all IXPs would theoretically fit into a /25. This already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At the same time, 74% of all peering LANs are /24s. Consequently, the default policy of assigning /24s has created large amounts of unused space.
* Already today, more than 10% of all peering LANs are smaller or equal a /25. Having small peering LANs is not entirely unusual.
* Large IXPs requiring a /23 or larger are rare (<3%). Thus, lowering the upper bound for assignments to /23 will not save large amounts of space.
Conclusions:
I back the proposal except for the limitation to a /23. I propose having a /21 as an upper limit with thorough checks by RIPE.
Regards, Matthias
On Wed, 2019-06-05 at 03:47 -0700, Randy Bush wrote:
Hmm.. why shouldn't defunct IXPs not be taken in consideration though?
Because they will have handed back their address space.
what are you trying to measure? the space utilization of current operating exchanges, or the distribution of request sizes?
randy
--
Dr.-Ing. Matthias Wichtlhuber Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber@de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne
Job Snijders wrote on 09/08/2019 12:54:
I'd like to suggest that by default a /25 IPv4 block is assigned to IXPs requesting some space, rather than a /24.
+1 (The default could be lowered to /26. On the conservative side. /25 is ; agreed ; a better suggestion.)
+1 for the /25. -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/
Am 09.08.2019 um 14:05 schrieb Chriztoffer Hansen <chriztoffer@netravnen.de>:
Job Snijders wrote on 09/08/2019 12:54:
I'd like to suggest that by default a /25 IPv4 block is assigned to IXPs requesting some space, rather than a /24.
+1
(The default could be lowered to /26. On the conservative side. /25 is ; agreed ; a better suggestion.)
Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net<mailto:kuenzler@init7.net>> wrote: +1 for the /25. -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/ Am 09.08.2019 um 14:05 schrieb Chriztoffer Hansen <chriztoffer@netravnen.de<mailto:chriztoffer@netravnen.de>>: Job Snijders wrote on 09/08/2019 12:54: I'd like to suggest that by default a /25 IPv4 block is assigned to IXPs requesting some space, rather than a /24. +1 (The default could be lowered to /26. On the conservative side. /25 is ; agreed ; a better suggestion.)
Support for /25 +1 Cheers, Ray From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Dominik Nowacki Sent: 9. elokuuta 2019 15:13 To: Fredy Kuenzler <kuenzler@init7.net> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net<mailto:kuenzler@init7.net>> wrote: +1 for the /25. -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/ Am 09.08.2019 um 14:05 schrieb Chriztoffer Hansen <chriztoffer@netravnen.de<mailto:chriztoffer@netravnen.de>>: Job Snijders wrote on 09/08/2019 12:54: I'd like to suggest that by default a /25 IPv4 block is assigned to IXPs requesting some space, rather than a /24. +1 (The default could be lowered to /26. On the conservative side. /25 is ; agreed ; a better suggestion.)
Hi, On Fri, Aug 09, 2019 at 12:26:37PM +0000, Jetten Raymond wrote:
Support for /25 +1
I hope you are all aware that you are asking for something which *was* in version 1.0 of this proposal, and which was *not* receiving positive feedback in the discussion phase. Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs). Just sayin. Gert Doering -- AWPG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 9 Aug 2019, at 13:41, Gert Doering <gert@space.net> wrote:
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
All the more reason for pursuing this wonderful idea Gert. Once v4's all gone, how about we develop v4 allocations policies that could be used if only there was address space to allocate? That would keep the WG busy for a long time. What's not to like? :-)
...and because of that I am happy with version 2.0 of 2019-05 as it is written. Wolfgang
On 9. Aug 2019, at 14:41, Gert Doering <gert@space.net> wrote:
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
I agree. I would like to see the current proposal 2.0 of 2019-05 implemented rather sooner than later. We shouldn't rely on the projected date of IPv4 depletion. I'd prefer to have a separate proposal on the lower boundary of allocation. This would allow for a broader discussion on how to handle the trade-off between size of allocation and renumbering. Matthias -- Dr.-Ing. Matthias Wichtlhuber Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber@de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ________________________________________ Von: address-policy-wg <address-policy-wg-bounces@ripe.net> im Auftrag von Wolfgang Tremmel <wolfgang.tremmel@de-cix.net> Gesendet: Freitag, 9. August 2019 15:17 An: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) ...and because of that I am happy with version 2.0 of 2019-05 as it is written. Wolfgang
On 9. Aug 2019, at 14:41, Gert Doering <gert@space.net> wrote:
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
I agree with Wolfgang - the current version is fine, and Gert - that it is important to move on this because otherwise we'll lose the opportunity forever, and that would be a shame because IXPs perform an important function for the Internet as a whole. Nick
Wolfgang Tremmel <mailto:wolfgang.tremmel@de-cix.net> 9 August 2019 at 16:17 ...and because of that I am happy with version 2.0 of 2019-05 as it is written.
Wolfgang
Gert Doering <mailto:gert@space.net> 9 August 2019 at 15:41 Hi,
I hope you are all aware that you are asking for something which *was* in version 1.0 of this proposal, and which was *not* receiving positive feedback in the discussion phase.
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
Just sayin.
Gert Doering -- AWPG chair Jetten Raymond <mailto:raymond.jetten@elisa.fi> 9 August 2019 at 15:26
Support for /25 +1
Cheers,
Ray
*From:*address-policy-wg <address-policy-wg-bounces@ripe.net> *On Behalf Of *Dominik Nowacki *Sent:* 9. elokuuta 2019 15:13 *To:* Fredy Kuenzler <kuenzler@init7.net> *Cc:* address-policy-wg@ripe.net *Subject:* Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number
With Kind Regards,
Dominik Nowacki
Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 <tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net <mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net <mailto:kuenzler@init7.net>> wrote:
Dominik Nowacki <mailto:dominik@clouvider.co.uk> 9 August 2019 at 15:13 Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number
With Kind Regards, Dominik Nowacki
Clouvider Limited is a limited company registered in England and Wales. Registered number: _08750969_ <tel:08750969>. Registered office: _88 Wood Street, London, United Kingdom, EC2V 7RS_. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify _abuse@clouvider.net_ <mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net <mailto:kuenzler@init7.net>> wrote:
Fredy Kuenzler <mailto:kuenzler@init7.net> 9 August 2019 at 15:08 +1 for the /25.
-- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland
I completely agree with Nick’s statement below. I support the proposal as it stands. Nurani
On 10 Aug 2019, at 10:29, Nick Hilliard <nick@foobar.org> wrote:
I agree with Wolfgang - the current version is fine, and Gert - that it is important to move on this because otherwise we'll lose the opportunity forever, and that would be a shame because IXPs perform an important function for the Internet as a whole.
Nick
Wolfgang Tremmel <mailto:wolfgang.tremmel@de-cix.net> 9 August 2019 at 16:17 ...and because of that I am happy with version 2.0 of 2019-05 as it is written.
Wolfgang
Gert Doering <mailto:gert@space.net> 9 August 2019 at 15:41 Hi,
I hope you are all aware that you are asking for something which *was* in version 1.0 of this proposal, and which was *not* receiving positive feedback in the discussion phase.
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
Just sayin.
Gert Doering -- AWPG chair Jetten Raymond <mailto:raymond.jetten@elisa.fi> 9 August 2019 at 15:26 Support for /25 +1
Cheers,
Ray
From: address-policy-wg <address-policy-wg-bounces@ripe.net> <mailto:address-policy-wg-bounces@ripe.net> On Behalf Of Dominik Nowacki Sent: 9. elokuuta 2019 15:13 To: Fredy Kuenzler <kuenzler@init7.net> <mailto:kuenzler@init7.net> Cc: address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number
With Kind Regards, Dominik Nowacki
Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 <tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net <mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net <mailto:kuenzler@init7.net>> wrote:
Dominik Nowacki <mailto:dominik@clouvider.co.uk> 9 August 2019 at 15:13 Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number
With Kind Regards, Dominik Nowacki
Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969 <tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS <applewebdata://D5E38BB3-4E77-42D6-96A0-64A0DD4328D9>. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net <mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net <mailto:kuenzler@init7.net>> wrote:
Fredy Kuenzler <mailto:kuenzler@init7.net> 9 August 2019 at 15:08 +1 for the /25.
-- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland
Hi I strongly agree with Nick and support version 2.0. No need to produce a revision changing the default away from /24. The discussion passim about smaller assignments needs no rehashing - happily give IXPs a smaller prefix if requested. Andy On 10 Aug 2019, at 09:59, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> wrote: I agree with Wolfgang - the current version is fine, and Gert - that it is important to move on this because otherwise we'll lose the opportunity forever, and that would be a shame because IXPs perform an important function for the Internet as a whole. Nick Wolfgang Tremmel<mailto:wolfgang.tremmel@de-cix.net> 9 August 2019 at 16:17 ...and because of that I am happy with version 2.0 of 2019-05 as it is written. Wolfgang Gert Doering<mailto:gert@space.net> 9 August 2019 at 15:41 Hi, I hope you are all aware that you are asking for something which *was* in version 1.0 of this proposal, and which was *not* receiving positive feedback in the discussion phase. Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs). Just sayin. Gert Doering -- AWPG chair Jetten Raymond<mailto:raymond.jetten@elisa.fi> 9 August 2019 at 15:26 Support for /25 +1 Cheers, Ray From: address-policy-wg <address-policy-wg-bounces@ripe.net><mailto:address-policy-wg-bounces@ripe.net> On Behalf Of Dominik Nowacki Sent: 9. elokuuta 2019 15:13 To: Fredy Kuenzler <kuenzler@init7.net><mailto:kuenzler@init7.net> Cc: address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net<mailto:kuenzler@init7.net>> wrote: Dominik Nowacki<mailto:dominik@clouvider.co.uk> 9 August 2019 at 15:13 Same here, +1 for /25 - /26 is too small, You don’t want IX to have to Re-number With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Aug 2019, at 13:09, Fredy Kuenzler <kuenzler@init7.net<mailto:kuenzler@init7.net>> wrote: Fredy Kuenzler<mailto:kuenzler@init7.net> 9 August 2019 at 15:08 +1 for the /25. -- Fredy Kuenzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur Switzerland http://www.init7.net/
I strongly agree with Nick and support version 2.0. No need to produce a revision changing the default away from /24.
how about /24.5? :) enough already. ship it. randy
Hi,
Op 11 aug. 2019, om 22:16 heeft Randy Bush <randy@psg.com> het volgende geschreven:
I strongly agree with Nick and support version 2.0. No need to produce a revision changing the default away from /24.
how about /24.5? :)
Brilliant idea ;)
enough already. ship it.
I agree, it's a good proposal. Cheers, Sander
On 13 Aug 2019, at 00:17, Randy Bush <randy@psg.com> wrote:
back when ip address assignment moved from sri to netsol, i applied for, and mark gave me, a /33 of ipv4 space. i probably have the record of it, but chances of finding it in my mail archive are miniscule.
Randy, think how much all that space would be worth on the transfer market. You should look *very* hard to find that email because you could make $$$$. :-)
Hi,
Op 13 aug. 2019, om 01:17 heeft Randy Bush <randy@psg.com> het volgende geschreven:
how about /24.5? :) Brilliant idea ;)
back when ip address assignment moved from sri to netsol, i applied for, and mark gave me, a /33 of ipv4 space. i probably have the record of it, but chances of finding it in my mail archive are miniscule.
Wow, I didn't know A+P/MAP had been invented back then. Which PSID did you get? ;) Cheers, Sander
On Sat, Aug 10, 2019, at 10:59, Nick Hilliard wrote:
I agree with Wolfgang - the current version is fine, and Gert - that it is important to move on this because otherwise we'll lose the opportunity forever, and that would be a shame because IXPs perform an important function for the Internet as a whole.
+1 We should go on with the current version. *IF* you consider that lowering the default to /25 is really necesarry, you can still submit a new proposal for thay, AFTER the current one is ik and the extra space secured. -- Radu-Adrian FEURDEAN
Dear all, As one of the proposers I would like to point out that this proposal is not about changing the default allocation size for IXPs, and as such I personally consider suggestions to change it out of scope for a discussion on this policy. On top of that, I don’t think it’s substantive opposition to enlarging the lifespan of the IXP pool, which is what this proposal aims to achieve - rather, I consider it an expansion of what is being proposed (do THIS and do THAT, too). That said, having seen the arguments and numbers, I will personally commit to drafting a policy proposal to change the default IXP location size to something smaller (/25, /26, /27?) once the process on the current proposal has been concluded. (With apologies to Radu for stealing his thread to reply) Kind regards Remco van Mook
On 12 Aug 2019, at 10:01, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
On Sat, Aug 10, 2019, at 10:59, Nick Hilliard wrote:
I agree with Wolfgang - the current version is fine, and Gert - that it is important to move on this because otherwise we'll lose the opportunity forever, and that would be a shame because IXPs perform an important function for the Internet as a whole.
+1 We should go on with the current version. *IF* you consider that lowering the default to /25 is really necesarry, you can still submit a new proposal for thay, AFTER the current one is ik and the extra space secured.
-- Radu-Adrian FEURDEAN
* Gert Doering
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
The IA states that the NCC can set aside the required /16 already at the point in time when this proposal enters Last Call. As I understand it, this means we have enough time to cut another version of this proposal if we want to. In particular, I am disappointed that the authors did not implement (or even comment on) my discussion phase suggestion[1] to use the 5.2 Unforeseen Circumstances pool for the IXP pool expansion. It is perfectly sized at /16, and it is adjacent to the current IXP pool, which means the resulting new IXP pool would have been an *actual* /15. As I understand the current proposal and the NCC's impact analysis, implementation of this proposal would necessarily mean that the resulting IXP pool would be at best two disjoint /16s, at worst one /16 plus a bunch of smaller fragments scattered all over the address space. That'd be a shame, in my opinion. [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-May/012885.ht... Tore
Hi, On Fri, Aug 09, 2019 at 03:50:37PM +0200, Tore Anderson wrote:
* Gert Doering
Also, you are certainly all aware that if we do another version of this proposal with changes and a new impact analysis, we'll have run out of IPv4 before this can be implemented (thus: no extra address space for IXPs).
The IA states that the NCC can set aside the required /16 already at the point in time when this proposal enters Last Call.
As I understand it, this means we have enough time to cut another version of this proposal if we want to.
You *could* play the PDP this way, by letting it pass review phase (where it is now), wait until the NCC sets aside the /16, and then call "foul!" in last call, to have it bounce back to the review phase... Between review and last call, no changes can be made - a new version with changed text (more than typos) would have to go through a new IA and a new review phase - which normally happens if there is sufficient opposition in review phase that a new version is warranted.
In particular, I am disappointed that the authors did not implement (or even comment on) my discussion phase suggestion[1] to use the 5.2 Unforeseen Circumstances pool for the IXP pool expansion. It is perfectly sized at /16, and it is adjacent to the current IXP pool, which means the resulting new IXP pool would have been an *actual* /15.
As I understand the current proposal and the NCC's impact analysis, implementation of this proposal would necessarily mean that the resulting IXP pool would be at best two disjoint /16s, at worst one /16 plus a bunch of smaller fragments scattered all over the address space. That'd be a shame, in my opinion.
Mmmh. Marco, can you comment on whether this is an implementation thing at the NCC, or whether you'd need a formal statement in the policy text to make this happen? (While it's all just numbers, some numbers look more familiar than others, so having all IXP space "in one block" is a bit easier on "oh, these numbers look IXPish" - so I can see that it would be nice) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
As I understand the current proposal and the NCC's impact analysis, implementation of this proposal would necessarily mean that the resulting IXP pool would be at best two disjoint /16s, at worst one /16 plus a bunch of smaller fragments scattered all over the address space. That'd be a shame, in my opinion. Mmmh. Marco, can you comment on whether this is an implementation thing at the NCC, or whether you'd need a formal statement in the policy text to make this happen?
(While it's all just numbers, some numbers look more familiar than others, so having all IXP space "in one block" is a bit easier on "oh, these numbers look IXPish" - so I can see that it would be nice) Yes, this is an implementation thing. While the IPv4 Policy requires
Hello Gert and colleagues, On 09/08/2019 21:43, Gert Doering wrote: that we set aside a /16 for unforseen circumstances, it doesn't specify the range or that it must be a contiguous block. At RIPE 77, Andrea Cima suggested that this (currently contiguous) /16 could be replaced with an equivalent of /23s and /24s as we near IPv4 runout: https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE... There was general support for the idea, though some questioned the intent of doing this to create more convenient /22 allocations. Now with this proposal, we plan to replace the currently-reserved 185.0.0.0/16 and use this for the IXP pool if this proposal reaches consensus. So Tore's suggestion would be achieved. It should be noted that for this to happen, there must be at least a /16 of regular space in our remaining pool when rough consensus is reached, to allow us to make the swap. The IPv4 Policy is clear that this reserved space must be used for IPv4 allocations as per section 5.1. Kind regards, Marco Schmidt Policy Officer RIPE NCC
* Dominik Nowacki
Same here, +1 for /25
Repeating myself a bit[1], I'd say the default should be /29. This because the /29s are the smallest fragments left behind in the NCC inventory. As the NCC's impact analysis states, these currently have no policy that allows for their use, so they'd be left to rot. Small IXPs can use them just fine, though, so I see no reason to not allow for that.
/26 is too small
Not at all. Quoting from Matthias's report: «71.73% of all IXPs would fit into a /26 including 100% overprovisioning»
You don’t want IX to have to Re-number
Why not? While it is somewhat of a hassle, renumbering an IXP is a relatively straightforward operation. I've participated in one such exercise myself (at NIX), and it wasn't difficult. It can certainly not compare to the challenge a regular network operator would face when renumbering out of a regular ALLOCATED PA block. We're at the end of the road when it comes for IPv4. If we take care to not assign IXP blocks gratuitously, the pool might actually end up lasting forever. [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-June/012909.h... Tore
On Fri, Aug 09, 2019 at 02:40:03PM +0200, Tore Anderson wrote:
Repeating myself a bit[1], I'd say the default should be /29. This because the /29s are the smallest fragments left behind in the NCC inventory.
I can't see how an IXP with 6 members (including RC/RS) would even be viable unless it's some hobby effort, so I wouldn't go overboard.
As the NCC's impact analysis states, these currently have no policy that allows for their use, so they'd be left to rot.
One possibility would be to assign them for PNIs - which is an IXP with two members, at the end of the day. ;p
We're at the end of the road when it comes for IPv4. If we take care to not assign IXP blocks gratuitously, the pool might actually end up lasting forever.
Why would this be desirable? Surely there is a functional limit on the numbers of viable IXPs in the service region? Besides, I still have some hope in RFC5549 eventually obsoleting IPv4 peering altogether... Meanwhile I could live with an either /25 or /26 IXP default assignment. rgds, Sascha Luck
* Sascha Luck [ml]
On Fri, Aug 09, 2019 at 02:40:03PM +0200, Tore Anderson wrote:
Repeating myself a bit[1], I'd say the default should be /29. This because the /29s are the smallest fragments left behind in the NCC inventory.
I can't see how an IXP with 6 members (including RC/RS) would even be viable unless it's some hobby effort, so I wouldn't go overboard.
Repeating myself again, just here in my small home country of Norway, there are (at least) four examples of such IXPs: BIX, SIX, TIX and TRDIX. https://www.nix.no/who-is-connected/ (scroll down to the bottom table). They have been around for a long time, so I'd assume they are «viable». They are run by the same organisation who runs NIX, so it's not «some hobby effort». Tore
On Fri, Aug 9, 2019 at 3:00 PM Tore Anderson <tore@fud.no> wrote:
* Sascha Luck [ml]
On Fri, Aug 09, 2019 at 02:40:03PM +0200, Tore Anderson wrote:
Repeating myself a bit[1], I'd say the default should be /29. This because the /29s are the smallest fragments left behind in the NCC inventory.
Well, I see that I could have participated at an earlier point in time and muttered agreement for this. Sorry about that, because I do agree. But as I understand it, there is not enough support for that? However, in the proposal, we do have the following paragraph, in which /29 could be substituted for /27, as a sort of compromise? 1. New IXPs will be assigned a /24 by default. Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined. On request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27. -- Jan
Hi, On Tue, Jun 04, 2019 at 07:03:21PM +0200, Aris Lambrianidis wrote:
Lastly, 6.1.2 mentions that "other uses are forbidden". Policies looking to enforce certain conditions are only meaningful if there is a framework for: a) Monitoring policy violations with accompanying documentation describing frequency, methodology etc. b) Describing disciplinary actions
Disciplinary actions in address policy violation is fairly much straightforward - if you get a block of addresses that comes with restrictions, and you ignore these even if told to stop doing so, the assignment is void and the address space returns to the RIPE NCC. This is the way all our policy framework is organized - like if a LIR receives an allocation and assigns space from that to their customers, the allocation holder is required to provide correct documentation. If this is not done, and the NCC gets to know about it, they will ask the holder to correct it and this is not happening, the address space will be reclaimed. Now, regarding the "monitoring" bit - since we're all mostly well-behaved here, describing the limitations and requirements upfront and only acting in cases where the NCC is informed about misuse works fairly well in practice (though some people in the anti-abuse community might not agree with me here). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Tue, 4 Jun 2019, Gert Doering wrote: (...)
Now, regarding the "monitoring" bit - since we're all mostly well-behaved here,
:-)))
describing the limitations and requirements upfront and only acting in cases where the NCC is informed about misuse works fairly well
In this specific case would you call the NCC "the police", or would you classify who informs the NCC as "the police"...? :-)
in practice (though some people in the anti-abuse community might not agree with me here).
Yes, it seems you are way too optimistic, most of the times... :-))) Cheers, Carlos
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In this specific case would you call the NCC "the police", or would you classify who informs the NCC as "the police"...? :-)
Hi, On Tue, Jun 04, 2019 at 08:57:55PM +0100, Carlos Friaças wrote:
On Tue, 4 Jun 2019, Gert Doering wrote:
(...)
Now, regarding the "monitoring" bit - since we're all mostly well-behaved here, :-)))
describing the limitations and requirements upfront and only acting in cases where the NCC is informed about misuse works fairly well
In this specific case would you call the NCC "the police", or would you classify who informs the NCC as "the police"...? :-)
Neither. The NCC is the registry who gives out addresses under very specific conditions, and if these conditions are not met by the receiving side, the address assignment/allocation is automatically voided. This is a pure contractual thing. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, May 29, 2019, at 15:11, Denis Fondras wrote:
Just because of "It no longer provides for IXPs that need more than a /23 of IPv4 space" I am against this proposal.
Hi, The alternative is that in just a few years it will no longer provide IXPs with any space. Right now, according to peeringdb, in RIPE region there are 5 IXPs holding a /21 and 5 (or 4, depending on how you consider the 2 LINX LANs) that hold a /22, and 14 (12, depending on how you count multi-LAN IXPs) that hold a /23. Let's hear their point of view, since building an IXP so big takes a lot of time (took almost 9 years for FranceIX to get there). Those being said, I'm in favour of the proposal. Just one reserve on wording of the assignment of "dust" (less than /24): if a request (for smaller than /24) is being made before the reserved pool exhaustion, will it be taken from he reserved pool or from the "dust" ? -- Radu-Adrian FEURDEAN
On Wed, May 29, 2019 at 04:13:15PM +0200, Radu-Adrian FEURDEAN wrote:
The alternative is that in just a few years it will no longer provide IXPs with any space.
Well, I agree that standing against this proposal on such a small point is a bit strong (I am totally in favor of reserving a /15 to IXPs) but I think setting in stone a limitation without a rationale does not make sense. I won't argue more, I guess you see my point :) Denis
Hi, On Wed, May 29, 2019 at 04:13:15PM +0200, Radu-Adrian FEURDEAN wrote:
Those being said, I'm in favour of the proposal. Just one reserve on wording of the assignment of "dust" (less than /24): if a request (for smaller than /24) is being made before the reserved pool exhaustion, will it be taken from he reserved pool or from the "dust" ?
Does this matter? Seriously: an IXP would only ever receive a "smaller than /24" assignment if they ask for it. And if they ask for it ("a /27 is sufficient enough, we're a small Island and there are only 10 ISPs here"), will it make a difference if they receive a dust-/27 or something from the IXP pool? (I could see arguments either way - so far the proposal is leaving it as an implementation detail to the NCC) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, May 29, 2019, at 17:48, Gert Doering wrote:
Does this matter?
For the IXP - definitely no. For the rest of the pool - maybe. This is why I was asking. -- Radu-Adrian FEURDEAN
IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes. 29.05.2019, 15:18, "Marco Schmidt" <mschmidt@ripe.net>:
Dear colleagues,
A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion.
This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 27 June 2019.
Regards,
Marco Schmidt Policy Officer RIPE NCC
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
They can’t. What participant uses it already in their network ? With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 29 May 2019, at 14:43, Alexandr Popov <alexp@ma.spb.ru<mailto:alexp@ma.spb.ru>> wrote: IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes. 29.05.2019, 15:18, "Marco Schmidt" <mschmidt@ripe.net<mailto:mschmidt@ripe.net>>: Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote:
IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes.
It has to be unique. On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote:
/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties.
And only 3 with more than 512 connected ASN. But can we imagine some ASN have more than 1 IP on the peering LAN ? I agree there is really a small chance an IXP will ask for more the /23. Still I can't see the point of this limitation. Denis
The small technical difficulties of using private networks by IXPs are easily solved. Ordinary companies that will lack the IPv4 will have much greater difficulties. Right, the IPs for IXPs should be unique. Perhaps it makes sense to create a policy of allocation Private-Use IPs for IXPs? If IXPs will follow that policy, they will have unique private IPs. 29.05.2019, 16:58, "Denis Fondras" <ripe@liopen.fr>:
On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote:
IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes.
It has to be unique.
On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote:
/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties.
And only 3 with more than 512 connected ASN. But can we imagine some ASN have more than 1 IP on the peering LAN ?
I agree there is really a small chance an IXP will ask for more the /23. Still I can't see the point of this limitation.
Denis
Hello, Some considerations about the pros and cons of using RFC1918 addresses (as well as other methods) were presented here: https://youtu.be/uJOtfiHDCMw?t=380 <https://youtu.be/uJOtfiHDCMw?t=380> With these in mind, I don't think RFC1918 addresses are a clean, scalable solution which works, something which I believe the authors of the original policy had in mind. Kind regards, Aris PS: Perhaps pushing vendors for RFC5549 support is a more long term solution?
On 29 May 2019, at 16:12, Alexandr Popov <alexp@ma.spb.ru> wrote:
The small technical difficulties of using private networks by IXPs are easily solved. Ordinary companies that will lack the IPv4 will have much greater difficulties. Right, the IPs for IXPs should be unique. Perhaps it makes sense to create a policy of allocation Private-Use IPs for IXPs? If IXPs will follow that policy, they will have unique private IPs.
29.05.2019, 16:58, "Denis Fondras" <ripe@liopen.fr>:
On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote:
IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes.
It has to be unique.
On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote:
/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties.
And only 3 with more than 512 connected ASN. But can we imagine some ASN have more than 1 IP on the peering LAN ?
I agree there is really a small chance an IXP will ask for more the /23. Still I can't see the point of this limitation.
Denis
Hello,
On 29. May 2019, at 16:12, Alexandr Popov <alexp@ma.spb.ru> wrote:
The small technical difficulties of using private networks by IXPs are easily solved.
well, you are mistaken. Here is a (not complete) list of reasons private networks cannot be used.... - Customers connect to multiple exchanges. Some of them with the same router. So each IXP peering LAN must be unique or you have the risk of having the same peering LAN twice (or more) to connect to on the same router. Which does not work. - Private IP space may be already in use at customers. And be routed within their AS. Thats the obvious argument, but not the only one. - Provisioning automation (at the customer side). We once used private IPv4 space to test customers for compliance during the connect phase and we encountered problems especially with large networks where engineers were not allowed to configure the routers directly but had to use some tool, which simply did not allow the engineer to configure any private IPv4 address on an interface. So IMHO private IPv4 space is not an option. Neither is using the same IXP lan on every exchange. best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
Hello, I do not argue, it creates some difficulties. But they CAN be solved. I think it’s wrong to give a priority to get IPv4 for IPXs. Because, in many other areas, there are no similar solutions. I mean companies providing services for ordinary users. Mail servers, etc. 31.05.2019, 10:22, "Wolfgang Tremmel" <wolfgang.tremmel@de-cix.net>:
Hello,
On 29. May 2019, at 16:12, Alexandr Popov <alexp@ma.spb.ru> wrote:
The small technical difficulties of using private networks by IXPs are easily solved.
well, you are mistaken.
Here is a (not complete) list of reasons private networks cannot be used....
- Customers connect to multiple exchanges. Some of them with the same router. So each IXP peering LAN must be unique or you have the risk of having the same peering LAN twice (or more) to connect to on the same router. Which does not work.
- Private IP space may be already in use at customers. And be routed within their AS. Thats the obvious argument, but not the only one.
- Provisioning automation (at the customer side). We once used private IPv4 space to test customers for compliance during the connect phase and we encountered problems especially with large networks where engineers were not allowed to configure the routers directly but had to use some tool, which simply did not allow the engineer to configure any private IPv4 address on an interface.
So IMHO private IPv4 space is not an option. Neither is using the same IXP lan on every exchange.
best regards Wolfgang
-- Wolfgang Tremmel
Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
Hi, On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote:
IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes.
IXPs say they need globally unique space, and they are the experts here. Could people *not* having experience in running an actual IXP please refrain from commenting on the technical aspects on "how an IXP should be run!"? Of course you're all free to agree or disagree with the proposal, but leave the actual IXP operations to those who do this as their daily job. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 29/05/2019 16:45:
IXPs say they need globally unique space, and they are the experts here.
From an architectural point of view, it's a good idea to use publicly registered numbering resources when interconnecting with third parties. IXPs are an extreme case of this because the same resource block is used to connect to multiple parties at the same time. One of the reasons this can cause problems is that the address block of the peering LAN often ends up redistributed in the IXP participant's routing tables. Lots of organisations redistribute rfc1997 address space internally in their own networks for their own purposes, so if this conflicts with the IXP peering LAN address block, the organisation is going to end up with connectivity problems. There are other reasons this can cause problems, but this is one of the more obvious ones. Nick
On 29.05.2019 17:45, Gert Doering wrote:
IXPs say they need globally unique space, and they are the experts here.
The same was true some years back, when the mobile operators asked for some dozen /16s for their customers. They didn't get those blocks, they were forced to look for alternatives, they found alternatives. ("NATs are good. CGNs doubly so.") Given the circumstances, for *any* request of "more v4 space for my use case" it is just and equitable to request a documented evidence the suggested soluion is the *only* way to accomplish the goal. I don't agree that it is the APWG chair's decision which request needs to be backed by facts and which isn't. Regards, -kai
Hi, On Wed, May 29, 2019 at 06:47:34PM +0200, Kai 'wusel' Siering wrote:
On 29.05.2019 17:45, Gert Doering wrote:
IXPs say they need globally unique space, and they are the experts here.
The same was true some years back, when the mobile operators asked for some dozen /16s for their customers. They didn't get those blocks, they were forced to look for alternatives, they found alternatives. ("NATs are good. CGNs doubly so.")
As far as I know, everybody who presented "documented need" *did* get their blocks. At least, this has always been the IPv4 policy as soon as there was space to allocate - and there has never been a clause "for this-and-that access technology, you can't have space". Neither for DSL, nor cable, nor for mobile. If mobile providers decided to not follow this route because they found it too complicated, or too cumbersome to document what some considered trade secrets and went with CGNAT instead - that's certainly their own decision, but was never mandated by policy.
Given the circumstances, for *any* request of "more v4 space for my use case" it is just and equitable to request a documented evidence the suggested soluion is the *only* way to accomplish the goal. I don't agree that it is the APWG chair's decision which request needs to be backed by facts and which isn't.
Since you've run an IXP yourself in the past, you should know the technical requirements quite well. So I'm not sure exactly what point you're trying to make. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Moin, on 29.05.2019 14:17, Marco Schmidt wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion.
This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05
[…]
Why is there a need for "globally-unique (but not necessarily globally-routed) IPv4 space" for IXPs? The IXPs I've experienced explicitely prohibit announcment (i. e. routing) of their space nor announce it theirselves; so why spend another whole /15 as private address space? Obviously, there is no need for global routabillity, where is the need for global uniqueness and why can't this be solved differently (everyone has to cope with IPv4 scarceness, why can't IXPs)? As the pool of unallocated IPv4 addresses depletes, new IXPs will need to adopt new strategies, just like their customers. I'd support a movement to repurpose e. g. 198.18.0.0/15 for post-exhaustion IXP address space — if that's coordinated between the RIRs, it would help to support emerging IXPs for some time. Churning even more IPv4 space for local uses feels wrong: I oppose 2019-05. Regards, -kai
Hi Kai, On 29/05/19 16:33, Kai 'wusel' Siering wrote:
The IXPs I've experienced explicitely prohibit announcment (i. e. routing) of their space nor announce it theirselves; so why spend another whole /15 as private address space? Obviously, there is no need for global routabillity, where is the need for global uniqueness and why can't this be solved differently (everyone has to cope with IPv4 scarceness, why can't IXPs)? As the pool of unallocated IPv4 addresses depletes, new IXPs will need to adopt new strategies, just like their customers.
There are several downsides of using the same address space in multiple IXPs: - IXP participants will not be able to connect the same router to multiple IXPs. This is something that is done quite a lot, especially by smaller networks that connect via remote peering. - It becomes impossible to identify in traceroutes which IXP was crossed. This makes troubleshooting a lot more complicated. - The consequences of address space leaks are more severe. When a participant of a smaller IXP leaks the peering LAN prefix to the routing table this will cause instability at all IXPs that use a prefix that covers the same block. Kind regards, Martin
* Marco Schmidt
A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion.
I am positive to this policy proposal. A suggestion, though: use the /16 set aside in «5.2 Unforeseen circumstances» for expanding the IXP pool. The unforeseen circumstances reservation is 185.0.0.0/16 while the IXP pool is 185.1.0.0/16. They combine nicely into 185.0.0.0/15. This might be helpful for operators that might want to exempt known IXP ranges from uRPF filtering, for example. Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge. Tore
Hi, On Fri, May 31, 2019 at 09:08:30AM +0200, Tore Anderson wrote:
Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge.
We briefly touched this in the WG session last Wednesday. Doing it this way removes the discussion about "larger address block for routing reasons" *if* the IXP in question decides that they do want to announce their prefix. So, as written today, "if you don't know", you get a /24 which could be routed later. "If you are sure you're small and do not want this announced", you can ask for a /27.../25. Not advocating anything, just relaying what was the explanation given. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
* Gert Doering
On Fri, May 31, 2019 at 09:08:30AM +0200, Tore Anderson wrote:
Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge.
We briefly touched this in the WG session last Wednesday. Doing it this way removes the discussion about "larger address block for routing reasons" *if* the IXP in question decides that they do want to announce their prefix.
So, as written today, "if you don't know", you get a /24 which could be routed later. "If you are sure you're small and do not want this announced", you can ask for a /27.../25.
Not advocating anything, just relaying what was the explanation given.
Right. Looking at the DFZ, there is only a single advertisement coming out of the current IXP pool¹: https://stat.ripe.net/widget/routing-status#w.resource=185.1.0.0%2F16 Considering how extremely uncommon this configuration is, I'd prefer it to be the other way around, i.e., that a small IXP with a dozen members would need to explain why they need a /24 in order to get it, otherwise they'd get a /27 by default. If we give out /27s by default to such small IXPs each /24 in the pool can accommodate 8 IXPs. With the current (and proposed) policy we'd need a /21 to accommodate those same 8 IXPs (as I do not imagine any of them explicitly requesting something smaller than what's on offer by default). This seems wasteful. [1] I was told on IRC that the reason for the specific advertisement seen is to provide some kind of quasi-OOB Internet transit service to the IXP members. If that is correct it seems to me to possibly run afoul of the first bullet in section 6.1, but whatever. Tore
On 31. May 2019, at 09:41, Tore Anderson <tore@fud.no> wrote:
Considering how extremely uncommon this configuration is, I'd prefer it to be the other way around, i.e., that a small IXP with a dozen members would need to explain why they need a /24 in order to get it, otherwise they'd get a /27 by default.
when an IXP first applies for an allocation out of the pool it has zero customers. It only has a business plan and how many customers it *expects* to have. Which easily can be "tweaked". So to avoid that RIPE NCC checks business plans we should stick with /24 as default. best regards, Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 0 | Fax +49 69 4056 2716 | | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
Dear Wolfgang, all -- On 31/05/2019, 08:47, Wolfgang Tremmel <wolfgang.tremmel@de-cix.net> wrote:
when an IXP first applies for an allocation out of the pool it has zero customers.
I have applied for, or supported a number of assignments in a number of different registries on a number of occasions. One of the very few things that they all had in common is customers. It was always necessary to demonstrate to the registry that the IXP has demand and will support connections right away. This is a healthy qualification that a prospective IXP should have to demonstrate. That said we do agree that IXPs should by default receive the /24. Andy
Tore Anderson wrote on 31/05/2019 08:41:
Looking at the DFZ, there is only a single advertisement coming out of the current IXP pool¹:
https://stat.ripe.net/widget/routing-status#w.resource=185.1.0.0%2F16 The prefix in question is 185.1.69.0/24.
[1] I was told on IRC that the reason for the specific advertisement seen is to provide some kind of quasi-OOB Internet transit service to the IXP members. The prefix in question is 185.1.69.0/24 (INEX Cork). Putting my INEX CTO hat on for a moment, I can confirm that INEX does not provide a quasi-OOB Internet transit service for its members.
Nick
Hi,
On 31. May 2019, at 09:08, Tore Anderson <tore@fud.no> wrote:
Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge.
when opening a new exchange there are no customers connected yet, all you have is a business plan. So everything is kind of speculative and you can easily adjust your plan that you need a /24 - so why add additional workload to the NCC to review business plans? An honest IXP operator can request something smaller if he knows that the exchange will not grow beyond a small number of customers within the first 5 years or so. best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel@de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
* Wolfgang Tremmel
when opening a new exchange there are no customers connected yet, all you have is a business plan. So everything is kind of speculative and you can easily adjust your plan that you need a /24 - so why add additional workload to the NCC to review business plans?
Hi, Using this rationale, why stop at /24? Why not give /23s by default - that is the only way to ascertain that the NCC does not have to review business plans, after all? I don't see how /24 is special in this context. Also note that «stopping the NCC from reviewing business plans» is not a stated objective of this policy proposal. In any case, if the IXP manages to fill up its /x with members the policy allows for replacing it with with a /x+1.
An honest IXP operator can request something smaller if he knows that the exchange will not grow beyond a small number of customers within the first 5 years or so.
You are implying that small IXPs that do not need more than /{27..25} are being dishonest if they don't say so instead of taking the default /24 on offer. Note that there is nothing in the proposed policy that requires or even encourages them to do so, however. So why would they? Tore
participants (29)
-
Alexandr Popov -
Andy Davidson -
Aris Lambrianidis -
Carlos Friaças -
Chriztoffer Hansen -
Denis Fondras -
Dominik Nowacki -
Fredy Kuenzler -
Gert Doering -
Hansen, Christoffer -
Ian Dickinson -
Jan Ingvoldstad -
Jetten Raymond -
Jim Reid -
Job Snijders -
Kai 'wusel' Siering -
Marco Schmidt -
Martin Pels -
Matthias Wichtlhuber -
Nick Hilliard -
Nikolas Pediaditis -
Nurani Nimpuno -
Radu-Adrian FEURDEAN -
Randy Bush -
remco van mook -
Sander Steffann -
Sascha Luck [ml] -
Tore Anderson -
Wolfgang Tremmel