[LACNIC/Politicas] Consulta

Fri Dec 3 14:19:28 BRST 2010

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