[LACNIC/Politicas] Consulta

Fri Dec 3 17:55:25 BRST 2010

Solo como aclaracion, por las dudas: el HD Ratio no aplica a la asignacion original. En IPv6, el /32 es la asignacion minima. Seguro que Fibertel, en el caso de Rodolfo, pudo/puede obtener una asignacion inicial de un bloque con prefijo menor a un /32 dado el tamaño de su operacion. Entiendo yo que esa asignacion seria acoirde a la topologia que Fibertel precisa para operar de acuerdo a las mejores practicas. Lo que si requiere el HD Ratio (y por eso es importante que la politcia sea clara al momento de la asignacion original) es que cuando vuelvas por mas direcciones puedas justificar el uso eficiente de aquellas ya asignadas.

PAra seguir con los terminos filosoficos :-): la causa de la necesidad de generar politicas de asignacion de bloques de direcciones IP es la tension que existe entre conservacion del recurso y agregacion. Si estas dos cosas no fueran contradictorias, no necesitariamos politicas, y las buenas politicas son aquellas que consiguen un buen equilibrio entre estos dos terminos.

Saludos!!!

On 03/12/2010, at 2:19 PM:, Ralvarez wrote:

> 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