[LACNIC/Politicas] [Fwd: [sig-policy] IPv6 Policy Proposal - prop-030-v001

[marcelo bagnulo braun]

Hola Jorge,

El 14/08/2005, a las 16:01, Jorge Villa escribió:

> Hola a todos:
>
> Marcelo, yo creo que evidentemente es cuestion de bajo que punto de 
> vista se entiende el planteamiento, y por eso me sumo a la apreciacion 
> de Jordi al final de su correo, acerca de que la politica en escencia 
> lo que busca es una modificacion de la RFC 3177, producto de que un 
> bloque ::/48 como tamaño medio de asignacion a usuarios finales, puede 
> resultar sobredimensionado para muchas organizaciones, y por tanto un 
> ::/56 es un valor mas razonable en muchos casos, asi que de esta 
> manera tendriamos asignaciones de tamaño ::/48, ::/56 y ::/64, que eso 
> se manejaria de forma dinamica teniendo en cuenta las caracteristicas, 
> necesidades y planes de asignacion de cada cliente.
>

> Evidentemente si la planeacion de solicitud del LIR al RIR se elabora 
> solamente tomando bloques ::/48 exclusivamente, y el RIR asigna 
> bloques ::/32, y se asigna a clientes finales tal cual la RFC 3177, 
> entonces habra un gran desperdicio de direcciones en muchos casos. 
> Aqui entra a jugar la capacidad ingeniera de los LIRs en el diseño de 
> planes y politicas de asignacion de direcciones, porque el proceso de 
> asignacion implica consideraciones acerca de bloques para reserva a 
> los clientes que ya tienen bloques, preferiblemente de manera contigua 
> para garantizar el crecimiento de manera bastante transparente (y sin 
> costo adicional), y que no haya necesidad de estar usando NATv6. Por 
> ejemplo si asignas un ::/56 a una organizacion, como minimo reservarle 
> otro ::/56 para crecimiento, pero puede ser que por las 
> caracteristicas de la organizacion se prevea reservar tres ::/56 o 
> quizas siete o mas ::/56; en fin, que los 256 ::/56 que componen el 
> ::/48 perfectamente se pueden compartir entre varios clientes, segun 
> las estimaciones de posible crecimiento hechas para cada uno de ellos; 
> asi que la planeacion de esta distribucion, implicara un proceso de 
> interaccion-negociacion Cliente-LIR a tal efecto.
>


Creo que estamos de acuerddo en todos los puntos que mencionas, pero 
creo que la modificacion que Jordi planteaba iba dirigia a otro punto

segun entiendo Jordi planteaba dos cosas:

primero el mail de Jordi decia esto:

> 4. Amend the evaluation threshold calculation to be based on default 
> end
>    site assignment size of a /56. Further end-site assignmentn
>    should be provided to APNIC in order to use a different average 
> end-site
>    assignment size for HD-ratio calculation purposes
>
> Tal y como esta ahora supone que el LIR tiene que justificar al RIR lo 
> que
> el usuario quiere, y eso implicara un proceso administrativo que al 
> final
> hara imposible la justificacion a los usuarios.

en particular, lo que no veo muy claro es la dificultad que plantea 
Jordi ya que lo que creo que define la politica es exactmente lo que tu 
planteas ariba, que es el tamaño asumido por defecto en la asignaciones 
a los sitios finales. Creo que es razonable que a partir de esta 
politica, la asignacion por defecto sea un /56 y que si un LIR en 
particular desea usar un /48 como asignacion por defecto a un grupo de 
clientes debe justificarlo (por ejemplo simplemetne decir que certos 
tipos de acceso son para sitios grandes o algo por el estilo)

el otro punto de Jordi era la reserve de todo el /48 para cada sitio 
final, aunque se asigne un /56.
Esto es una reserva de 256 veces el tamaño asignado.

Yo estoy mas en la linea que planteas tu, de hacer reservas de 8 /56 y 
que los clientes compartan las resevas. Me parece que todo un /48 puede 
tal vez ser un pelin mucho.

Pues eso, que no veo que existan discrepancias entre nuestros puntos de 
vista.

Saludos, marcelo




> Saludos,
> Jorge Villa
>
> --- marcelo bagnulo braun <marcelo at it.uc3m.es> wrote:
>
>> Hola Jordi,
>>
>> no estoy muy seguro de que estemos interpretando la
>> propuesta de la
>> misma forma....
>>
>> El 11/08/2005, a las 15:32, JORDI PALET MARTINEZ
>> escribi—:
>>
>>> Hola a todos,
>>>
>>> Bajo mi punto de vista este punto requiere otra
>> redaccion:
>>>
>>> 4. Amend the evaluation threshold calculation to
>> be based on default
>>> end
>>>    site assignment size of a /56. Further end-site
>> assignmentn
>>>    should be provided to APNIC in order to use a
>> different average
>>> end-site
>>>    assignment size for HD-ratio calculation
>> purposes
>>>
>>
>> segun yo leo esto, esto quiere decir que cuando un
>> LIR va a solicitar
>> un bloque de direcciones al RIR, se asume que la
>> asignacion por defecto
>> es un /56 y que se dimensiona el bloque allocado a
>> RIR basado en esta
>> hipotesis. Me imagino que esto es asi, porque un /56
>> es con esta
>> propuesta el valor por defecto de asignacion.
>> si el LIR cree que un numero importante de sus
>> clientes seran "grandes"
>> y requeriran un /48 y quiere usar ese tama–o de
>> bloque para dimensionar
>> su solicitud, entonces el LIR debe justificarlo
>>
>> en breve, lo que se plantea en este punto es el
>> tama–o por defecto de
>> las asignaciones a los sitio que sera usado para
>> dimensionar el bloque
>> asignado al LIR, de acuerdo?
>>
>>> Tal y como esta ahora supone que el LIR tiene que
>> justificar al RIR lo
>>> que
>>> el usuario quiere,
>>
>> hmmm...
>>
>> nop creo que sea lo que "el usuario quiere" sino
>> cual es la composicion
>> del cojunto de usuarios esperados... es decir si
>> espera que sus
>> clientes sean sitios grandes (/48), sitios peque–os
>> (/56, que es el
>> valor por defecto)o sitios de uan sola subred (/64)
>>
>> en otras palabras, esto no es un requisito usuario
>> por usuario, sino
>> mas bien una caracterizacion de la base de clientes
>> esperados
>>
>>>  y eso implicara un proceso administrativo que al
>> final
>>> hara imposible la justificacion a los usuarios.
>>>
>>
>> À?
>> no veo esto... el ISP sabra a que publico planea dar
>> servicio y sabra
>> si espera que sus clientes sean sitios grandes o
>> chicos... No creo que
>> el usuario final este involucrado de ninguna forma
>> en esto...
>>
>>> Imaginemos que un usuario utiliza todo el
>> subneting que el /56 le
>>> permite.
>>
>> Este punto no es sobre un usuario en particular,
>> sino el perfil de la
>> base de usuarios usado para dimensionar el tama–o
>> del bloque pedido.
>> Digo, si un usuario quiere mas espacio, debera
>> dirigirse al LIR. El RIR
>> no tiene nada que ver en esto, creo yo
>>
>>> Este usuario no debe de tener ninguna carga
>> adicional, ni nigun
>>> sobreprecio,
>>
>> ok
>>
>>> y me atrevo a decir que ni siquiera necesitar
>> renumeracion para pasar
>>> al
>>> /48.
>>
>> bueno, esto habria que verlo un poco mas creo yo...
>> pero no me parece
>> mal en un principio. Digo, si la asignacion minima
>> es un /32, creo que
>> los lirs podran hacer esto por mucho tiempo....
>>
>>>  De otro modo, tendremos NATv6 y no habra servido
>> para nada la
>>> transicion a IPv6.
>>>
>>
>> creo que debemos dejar un poco de lado estos
>> argumentos... no creo que
>> un usuario que tiene un /56 vaya a correr a un NAT
>> por falta de
>> direcciones (si lo creyeramos no hariamos esta
>> politica)
>>
>>> Ademas, creo que esto es posible implementarlo. De
>> que forma: Si los
>>> ISPs
>>> reservan el /48 completo por si el usuario lo
>> requiere, y se les
>>> asigna solo
>>> la primera mitad,
>>
>> À? un /56 es mucho menos que la mitad de un /48...
>>
>> qqueres decir que debemos reservar un /55 y guardar
>> la otra mitad o que
>> debemos guradar todo el /48, es decir asignar un
>> 1/256 y guradar en
>> reserva los restandes 255/256 por si todos los
>> sitios tienen un
>> crecimiento de 256 veces lo esperado?
>>
>>>  el usuario que lo requiera lo puede pedir y lo
>> recibe, sin
>>> mas. Tengamos en cuenta que el usuario que lo
>> pida, es que realmente lo
>>> requiere, nadie lo pedira por capricho, entre
>> otras cosas porque el
>>> 99.9% de
>>> los usuarios siquiera conocen esta posibilidad (no
>> leen las politicas
>>> y aun
>>> leyendolas no lo entenderian).
>>>
>>> Con esto cumplimos el principio de "prevencion del
>> agotamiento" que se
>>> pretende con este cambio en la politica, si bien,
>> las asignaciones
>>> siguen
>>> haciendose a los LIRs.
>>>
>>> Ahora bien, si relamente se llegaran a agotar las
>> direcciones, y esto
>>> se
>>> podria poner tal cual en la redaccion, se podria
>> cambiar la politica de
>>> forma que los LIRs empiezen a utilizar los /56 que
>> han quedado
>>> reservados,
>>> para aquellos usuarios que no los han pedido. Es
>> decir, el LIR no
>>> tendria
>>> que hacer una nueva peticion, puesto que
>> dispondria posiblmente de
>>> casi el
>>> 99% del espacio que ha utilizado hasta ese
>> momento.
>>>
>>
>>> Creo que es un balance bueno entre lo que se
>> pretende con este cambio
>>> y lo
>>> que se pretendia con el origen del RFC3177 y las
>> politicas iniciales.
>>>
>>> Que os parece ?
>>>
>>
>> no pudo dar mi opinion aun, no me queda claro si lo
>> he entendido bien
>> aun
>>
>> saludos, marcelo
>>
>>> Espero vuestros comentarios un par de dias y lo
>> redacto en Ingles y
>>> envio a
>>> la lista global de discusion de politicas IPv6.
>>>
>>> Regards,
>>> Jordi
>>>
>
>
>
>
>
> Participe en el V Congreso Internacional de Educaci¢n Superior
> "Universidad 2006". La Habana , Cuba, del 13 al 17 de febrero del 2006
> http://www.universidad2006.cu/
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
>