[LACNIC/Politicas] [SPAM]Re: Consulta

Sat Dec 4 21:33:21 BRST 2010

Rodolfo:

Solo una aclaración. No siempre se hacen asignaciones iniciales de /32. En LACNIC ya se han hecho asignaciones mayores. En cada caso habría que hacer el ejercicio con el prefijo real que el ISP dado califica para obtener. 

Saludos, 

Just a clarification. Not all the initial allocations are /32. We have already allocated bigger blocks. The exercise that you propose should be done with the prefix that the given ISP could be allocated. 

Regards,

Raúl

El 03/12/2010, a las 14:19, Ralvarez escribió:

> Estimados, estoy siguiendo atentamente la discusión. 
> Les paso un par de números concretos para el ejercicio.
> Trabajo en un operador que ofrece Internet por CM y me estaba planteando que
> asignación hacer a un cliente un /48 o /56?
> 
> 1-Si voy con un /48 y supongo que no tengo regiones (en la realidad si
> tengo) 
> Con 16 bits restantantes me dan 64k clientes, hoy en dia ya tengo CMTS con
> casi 30K de clientes (con la implementacion de DOCSIS3 pronto superaremos
> eso numero), con lo cual con solo 2 o 4 CMTS consumi el /32 de asignación
> inicial que hace LACNIC.
> 
> 2-Ahora si voy con /56, tomo 16 bits para 64k de clientes y me quedan
> disponibles 8bits para 256 regiones a su vez si cuento subregiones me daría
> 64 regiones con 64 subregiones.
> 
> Çon la primera opción al cabo de implementar ipv6 en 4 CMTS ya debo pedir
> nueva asignación a LACNIC, y aquí es cuando entra en juego esta política
> Con la segunda opción alcanzo a cubrir las IP para clientes, pero pierdo en
> flexibilidad si necesito subdividir en mas 64 regiones/subregiones. 
> 
> Saludos
> Rodolfo Alvarez
> 
> -----Mensaje original-----
> De: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] En
> nombre de Carlos G Mendioroz
> Enviado el: viernes, 03 de diciembre de 2010 12:16
> Para: Lista para discusion de politicas de la comunidad de LACNIC
> Asunto: Re: [LACNIC/Politicas] Consulta
> 
> Hmmm, todo esto empezó por un comentario de un operador que hacía el
> siguiente argumento:
> 
> Tengo un cliente, le doy un /56 (creo que por ahora es lo que se estima
> razonable) pero por si crece debo mantener algunos /56 reservados.
> Supongamos que la reserva es /48 (generoso) lo que me restringe a 16 bits
> para clientes y regiones. Supongamos que tengo 8 bits para regiones, solo me
> deja 8 bits para clientes, lo que es poco.
> Asi que empieza la historia semejante a VLSM.
> 
> Ahora, aún sin regiones, 16 bits dan 64k clientes. Hoy.
> Tu dices que no hay ningún ISP que tenga ese número de clientes ?
> Creo que no es filosófica...
> 
> Lo que comenta Christian es muy al punto, y también está relacionado: se
> necesita (creo) tener en cuenta la complejidad de la red más que un simple
> porcentaje de uso de objetos.
> 
> -tron
> 
> Sebastian Bellagamba @ 3/12/2010 11:46 -0300 dixit:
>> Es por eso que me declare "conservacionista". Yo me imagino a Kahn y Cerf
> definiendo el tamaño de IPv4 y diciendo algo asi que como 32 bits son 4300
> millones le podemos dar una direccion IP a cada ser humano (de ese momento)
> asi que sobra. La historia siguio conque a cada hijo de vecino que pasaba
> por la puerta le daban un /8. Si no hubiera sido por el CIDR, no nos
> hubieran durado tanto las direcciones, mas aun no hubieramos llegado
> siquiera de desarrollar IPv6 como continuacion....
>> 
>> Las cuentas que dan lo de los granos de arena del Sahara estan 
>> sesgadas de optimismo: hemos transformado v6 de un protocolo 128 bits 
>> a uno de 64, partiendolo en dos de entrada. Estamos realizando 
>> asignaciones iniciales por demas generosas: para ponerlo en claro: 
>> cada LIR que cumple los requisitos se lleva un equivalente en v6 al 
>> total del espacio IPv4 (32 bits), y cada una de esas /64 tiene 2^64 
>> hosts para asignar... La asignacion recomendada por parte de los LIRs 
>> es de un /48 (16 bits a cada cliente no LAN, mas sus correspondientes 
>> 64 bits para hosts!). Solo se recomienda asignar un /64 ante la 
>> certeza de que es una unica LAN (un cliente residencial, supongo), 
>> pero de nuevo ese /64 tiene los otros 64 bits para jugar... Cuando ese 
>> cliente eventualmente crezca, cumple ciertas condiciones y pasa por 
>> LACNIC, que minimamente le entrega su /32 correspondiente. Yo por eso 
>> pongo "conservacionista" encomillado, porque no me parece que estemos 
>> siendo tacaños; y esto esta bien, porq
> ue todos creo que concordamos que esto conlleva a la innovacion. 
>> 
>> Ahora bien, desde el punto de vista economico, cualquier recurso finito,
> no renovable, es un recurso escaso. Y debe manejarse acordemente. Como
> comunidad ya hicimos lio una vez. No lo repitamos. Ademas, pregunto, con el
> nivel de asignaciones descrito arriba, creemos realmente que necesitamos
> mas?
>> 
>> Porque me parece que hay que tener en cuenta un punto importante: cuando
> entra en juego esta politica? Al momento de pedir una nueva asignacion, no
> la original. Y creo que todavia falta un tiempo para que ese momento
> llegue....
>> 
>> Por eso me parece que ahora la discusion en solo filosofica. SIn 
>> dudas, cuando llegue el momento de que el primer LIR venga a pedir una 
>> reasignacion vamos a contar con mas datos empiricos, ahora si 
>> tecnicos. Y, como siempre, podremos, con mas fundamentos, reabrir esta 
>> discusion y de ser preciso plantear modificaciones a esta politica (a 
>> lo que yo pondre argumentos "conservacionistas seguramente :-))
>> 
>> Saludos!
>> 
>> On 03/12/2010, at 11:47 AM:, Carlos G Mendioroz wrote:
>> 
>>> Sebastian,
>>> creo haber sido responsable de iniciar esta instancia de discusión, y 
>>> mi silencio parcial se debe a que quiero entender un par de
> presentaciones "pesadas" antes de seguir, pero disiento con tu comentario:
>>> 
>>> ...esta es una discusion mas bien "filosofica" sobre el manejo  
>>> responsable de un recurso escaso que una cuestion tecnica.
>>> 
>>> Creo que llamar "recurso escaso" a los prefijos de IPv6 es notable.
>>> Como dije al pasar, tenemos para ponerle prefijo a todos los granos de
> arena del Sahara, o a millones de cosas por habitante del mundo.
>>> 
>>> Por otro lado, la superprtección de la "eficiencia" de asignación 
>>> tiene impacto directo en la posibilidad de sumarizar, y evitar 
>>> fragmentación del espacio, ambos temas bien técnicos.
>>> 
>>> -tron
>>> 
>>> 
>>> Sebastian Bellagamba @ 3/12/2010 10:02 -0300 dixit:
>>>> Buena memoria, Jorge!
>>>> Efectivamente, yo propuse este cambio de politica. Pero cabe una
> aclaracion importante: lo que se discutio (y se aprobo) fue cambiar el valor
> del HD Ratio para IPv6 de 0.8 a 0.94, no el concepto de HD Ratio en si
> mismo. Les adjunto la presentacion que hice en LACNIC IX, Guatemala, para
> referencia.
>>>> Yendo al punto, me parece a mi que estamos discutiendo diferentes cosas
> a la vez:
>>>> - Por un lado, el concepto de HD Ratio. En mi opinion, es valedero por
> sus caracteristicas no-lineales.
>>>> - Por otro lado, si aceptamos el HD Ratio, esta el tema del valor que
> tomamos. Yo propuse el cambio del valor por dos motivos: uno, por lo
> expuesto en el RFC4692 (http://tools.ietf.org/html/rfc4692). Segundo, porque
> me alineo con el lado de los "conservacionistas" en terminos del manejo de
> la distribucion del espacio de direcciones, siendo este segundo punto el que
> para mi prepondero al momento de presentar la politica.
>>>> Como veo yo la discusion de ahora y los pasos a seguir?: el proceso 
>>>> de desarrollo de politicas de LACNIC esta siempre abierto. Si alguien no
> esta de acuerdo o cree poder mejorar las politicas vigentes, solo tiene que
> presentar una nueva propuesta. Creo que esto seria muy interesante y
> productivo, aunque voy aclarando que desde mi perspectiva esta es una
> discusion mas bien "filosofica" sobre el manejo responsable de un recurso
> escaso que una cuestion tecnica Saludos!!
>>>> SB
>>>> On 03/12/2010, at 2:53 AM:, Jorge Amodio wrote:
>>>>> 2010/12/2 Christian O'Flaherty <christian.oflaherty at gmail.com>:
>>>>>> Hola Francisco,
>>>>>> 
>>>>>> La discusión es por el cambio de HD ratio en IPv6 (cambio de .80 a 
>>>>>> .94) No era la de utilizar HD ratio en IPv4
>>>>>> 
>>>>>> Christian
>>>>> Christian,
>>>>> 
>>>>> si mal no recuerdo quien propuso la discusion del cambio de radio 
>>>>> para
>>>>> IPv6 fue Sebastian Bellagamba, alla por el 2006, y si mal no 
>>>>> recuerdo quedo inmersa en una serie de propuestas que se se 
>>>>> aprobaron en el 2007.
>>>>> 
>>>>> Saludos
>>>>> Jorge
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>> 
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>> --
>>> Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina 
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> --
> Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas

Raul Echeberria
raul at lacnic.net

Twitter: http://twitter.com/raulecheberria