This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] About the /22 allocation limitation
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Dpto. Datos Television Costa Blanca
datos at tvt-datos.es
Fri Apr 11 12:37:15 CEST 2014
El 11/04/2014 11:23, Tore Anderson escribió: > * Dpto. Datos Television Costa Blanca > >> Isnt unequal right now? Are you saying is equal LIRs with thousands and >> thousands of IP address when there are LIRs with only a /22? Is equal >> that the LIRs with thousands can make lot of money from LIRs with only a >> /22? > Depends on how you look at it. It is unequal in the sense that everyone > doesn't have an equal amount. It is on the other hand equal in the sense > that everyone had an equal opportunity to apply for IP addresses at any > given time. In any case, it is what it is. There is no point crying over > spilt milk. > >> Its so hard to prove you need more IPs? > That's not the problem with your proposal, the problem is to conjure up > the IPv4 addresses required to fulfill the proven need of all the LIRs > in the region, existing and future. The addresses simply do not exist, > and no amount of policy proposals can change that. Lets think the reserved pool grows enought. Lets say reserved pool gets arround a /10. There should be a policy that says: [...] When the reserved pool reachs the number of "N" millions of IP [...] a LIR that prove they need the space, will recieve a /X space >> Thats could be a possibility, but again giving IP space to all the ones >> ask for it, in my honest opinion, will produce the same problem we have >> now. > But isn't this exactly what you are proposing to do - let everyone ask > for more IPv4 addresses according to whatever they need? > >> Im not saying to give more space to everyone. Please consider isnt the >> same LIRs with thousands and thousands of IP space and LIRs with only a >> /22 > So are you saying that only LIRs that are holding a /22 (or less) will > be allowed to request more space, under your proposed new policy? > > In other words, an LIR that holds, say, a /21, will not be eligible to > apply? Or one that held a /22, and then requested and received a /24 > from your new pool, will this LIR that now holds a /22 + a /24 be able > to request more, or not? Sorry, didnt mean that. Remember my english isnt really well, im doing my best to say what I want to say, but sometimes its hard. There should be a limit. Not all LIRs need space really. >> Without the possibility, even in the future, of giving more IP space to >> little new LIRs you are dooming them. > It's IPv4 that is doomed, and that goes equally for old LIRs as well as > new LIRs. I'm sure the community would enthusiastically give more IPv4 > space to little new LIRs if that space existed, but it doesn't, and so > it is impossible to give it. There is simply no good option available to us: No its not equals. You have mooooooore game with 1 millions address than 1 thousand address. > > 1) If you open up for requests that are bounded upwards only by > demonstrated need, then that pool will be gone pretty much > instantaneously, even if you limit its eligibility to new LIRs only. > Except for a few luck "lottery winners", nobody will benefit. > > 2) If you only change the upper limit slightly, say from a /22 to a /21, > then you haven't solved anything; the LIRs will still be unable to get > the amount of space they actually need. > > It sucks to not have enough IPv4 space. I'm in that situation, myself. > But there is unfortunately no way we can solve IPv4 depletion in this forum. In general terms, what I mean is. Lets give the chance not only to new LIRs but everyone to get more IP space, IF THEY REALLY PROVE the need. I didnt say anything about minimum or maximum allocation, and if I said something that mean that, sorry. I also said to change minimum allocation from /22 to something little, for not exhausting the reserved pool in "2 days" but seems to not be the right decision due to the routing table grow. Of course, Im always talking about the reserved pool, not about the last 185/8 pool. Im really new to LIR and to this mailing list. For that im writting here to read all of you, your experiences and your opinion, and then if possible, do something. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos at tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]