members-discuss

Download

members-discuss@ripe.net

February 2017

1 discussions

Re: [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
by Muntasir.Ali＠newham.gov.uk 26 Apr '17

26 Apr '17

Hi, As a non-profit LIR with a /16 Legacy IPv4 address space, and only Legacy space within IPv4, we would be opposed to any charging models based on size of IP allocations, especially those which include Legacy space within consideration of calculating what is charged. This is considering that many (not all) of the proposed "solutions" may make it more expensive or infeasible for us to retain membership were they implemented as described. Our main motivation of joining up was for IPv6 address space allocation, so that we can move to enabling IPv6 services on our networks. If it turns out more expensive to retain membership simply because of our Legacy address space, were RIPE to adopt a model based on size of IP address space, then for us, it would make more sense to set up a new business and register that as a brand new LIR without any IPv4 space, and just ask for an IPv6 allocation. If the charging model is based purely on IPv4 space, then in theory if we have no IPv4 registered, we don't get charged anything? We don't need the "free" /22 currently offered to new members. Even though we are currently eligible for the extra /22 on top of our Legacy space, we have chosen not to take up the offer, since we know the /22 would be better served allocated to another RIPE member; hording it makes no sense for us nor for the wider community. Not that I expect it to work that way anyway (creating an LIR with IPv6 allocation and no IPv4 allocation), that's simply not maintainable for RIPE if quite a large number of organisations were to do this, and it may push up costs for the members which do have IPv4 allocations. Which highlights another point - I've noticed there's been no mention or consideration of size of IPv6 allocations when it comes to charging models based on IP allocation. I presume the general membership don't consider this an issue at present due to the vast size of IPv6 address space? What happens for LIRs with only IPv6 space? Why aren't we considering the usage of other resources as well, such as AS number allocations? Also regarding the state of Legacy resources, I raised a ticket to enquire what would happen were we to stop membership. Quoting from the response: [quote] ...so the legacy space is not part of the Internet Registry system. You didn't get it from the RIPE NCC so if you close your LIR you keep it. The IPv6 allocation [...] you did get from the RIPE NCC so if you close your LIR it comes back to us. Your LIR also quailifies [sic] for a /22 of IPv4 and if you closed your LIR after receiving that it would also be returned to us. [/quote] This would imply that actually, RIPE cannot reasonably charge based on size of any Legacy space, because the space doesn't belong to RIPE, and we keep it if we left. By extension, if any charging model based on size of IPv4 allocation includes the Legacy space allocation, then it will make sense for any LIR with legacy space to create a second LIR, separate their legacy and non-legacy space by transferring one to the second LIR, then dropping membership for the LIR with the Legacy space. The remaining LIR with non-legacy space would then be charged less than if it retained all the space. Now this isn't really fair for the LIRs without Legacy space, but from a cost perspective, this would be the logical thing to do for LIRs with Legacy space, especially if they have a large amount of it. So for any proposal to charge based on IPv4 allocation which includes Legacy space, which for above reasons I don't think RIPE can do anyway, I would posture this would not give a fair or desired outcome in the long run, especially for the LIRs without Legacy space. But then, any proposals to charge based on IPv4 allocation which excludes Legacy space, are also arguably not fair either, because those with Legacy space would effectively get a disproportionately cheaper service for what they use, if we decide service charge is to be based on IPv4 usage. So I do not think _any_ proposal to charge based on IPv4 space can give a fair, reasonable, or desired outcome. > > > > Anyway, I believe that implementing a charge that is based on the > > size of the IPv4 resource allocation is fair and it would line up > > with RIPE NCC's goal of safeguarding the resources. Whether > > implementing a cost like the proposed €250/year per /24 or a fee > > based on categories such as the other RIRs are imposing, the model needs to be changed. > > I disagree. I'd rather the costs were distributed based on the costs of providing service to LIRs, which the current charging scheme seems to do quite well, subject to closing loopholes when someone tries to game the system. > > I agree with this. The cost model should be based on the cost of providing the actual service, not the size of address space any organisation may have. Because RIPE need to recover the costs of running their service, it would be fairer and more sensible to charge based on how much service is used, not on resource allocated. Of course this brings questions on what defines "service". Number of tickets raised? Number of objects of the various types in the database for that particular LIR? Frequency of database changes? Usage of tools like RIPE Atlas, other APIs? etc. This is assuming we don't keep the current flat rate scheme or use something similar, which as previously mentioned, appears to work quite well subject to closing loopholes being used for abuse. Regards, Muntasir Ali, Specialist ICT Analyst, ICT oneSource Newham Dockside , 1000 Dockside Road , London E16 2QU DDI: 020 3373 7337, Int: 37337 oneSource - working on behalf of Havering and Newham councils www.onesource.co.uk Follow us on Twitter: @oneSourceUK Please consider the environment before printing this email. ________________________________ NOTE: This communication is sent for and on behalf of the London Borough of Newham. However the views expressed within it are not necessarily the views or policies of the Council. The unauthorised use, disclosure, copying or alteration of this communication and any attachments is forbidden. This communication and any attachments are intended for the addressee only and may be confidential. If this has come to you in error you should immediately permanently destroy it. You should take no action based on it or copy or show it to anyone and telephone the Council immediately with any issues on 020 8430 2000 or any other number provided in the communication. Please note that electronic communication is not considered a secure medium for sending information and therefore maybe at risk. We advise that you understand and accept this lack of security when using this form of communication with us. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free and should run current anti-virus software. Please note that email may be monitored and checked to safeguard the council network from viruses, hoax messages or abuse of the Council's systems. Action may be taken against any malicious and deliberate attempts to infect the council network. The information contained in this email maybe subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure the confidentiality of this email and your reply cannot be guaranteed.

36 84