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

[Jorge Villa]

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. 

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/