[LACNIC/Politicas] Segunda adjudicaci=?ISO-8859-1?B?8w==?=n IPv6

[Roque Gagliano]

Jordi,

La política que estoy planteando es independiente de la política de
reservas. El beneficio de tener un bloque reservado mayor es evitar la
renumeración. Pero por más que esten las direcciones "esperándote" puede
ser que no las tengas en el momento de la planificación de los
servicios.

Creo que para lo que yo estoy planteando sí se necesita una política.

slds
r.

On Tue, 2006-11-21 at 20:45 +0100, JORDI PALET MARTINEZ wrote:
> Hola Roque,
> 
> Comprendido.
> 
> Yo hace tiempo que hable con Ricardo, aunque no directamente de un ejemplo
> equivalente, pero si de como se hacian las reservas y de si hacia falta una
> politica para establecer ese mecanismo y permitir el crecimiento tras una
> primera asignacion.
> 
> Si no mal recuerdo me dijo que creia que era mejor que dado que esto era
> pura operativa, continuara en sus manos.
> 
> Asi que quizas es mejor hacer una recomendación (que bien podria ser
> politica si fuera el caso, pero creo que no es preciso), de como asignar
> esas reservas (vease el mi correo del otro dia que mencionaba reservar un
> nuemero de bits mayor que el actual, etc.).
> 
> Recuerdo haber visto un par de documentos aunque no necesariamente al
> respecto de esto, pero que podrian ser usados para esta operativa dentro de
> LACNIC:
> 
> http://www.ripe.net/docs/ipv6-sparse.html
> http://www.arin.net/meetings/minutes/ARIN_XV/PDF/mon/mei-wang.pdf
> 
> Saludos,
> Jordi
> 
> 
> 
> 
> > De: Roque Gagliano <rgaglian at antel.net.uy>
> > Organización: ANTELDATA
> > Responder a: <rgaglian at antel.net.uy>
> > Fecha: Tue, 21 Nov 2006 15:14:21 -0300
> > Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> > <politicas at lacnic.net>
> > Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
> > 
> > Jordi, te contesto entre líneas.
> > 
> > On Mon, 2006-11-20 at 09:44 +0100, JORDI PALET MARTINEZ wrote:
> >> Hola Roque,
> >> 
> >> Me pregunto hasta que punto es realmente necesaria esta politica en funcion
> >> de como LACNIC esta asignando los bloques, haciendo reservas que permiten
> >> obtener un bloque mas grande que incluya el bloque anterior, y por tanto
> >> evitando la renumeracion.
> >> 
> > El hecho de que se haga la reserva es una tema administrativo de LACNIC.
> > Justamente atendiendo a esta posibilidad la devolución del bloque
> > adicional puede no requerirse.
> > 
> >> Por otro lado, si de lo que se trata es de facilitar entornos de pruebas
> >> (cosa que creo que hoy ya no es necesaria), siempre existen otras formas,
> >> como los prefijos experimentales (aplicables solo en algunas casos), o la
> >> cesion de bloques mas pequeños de forma temporal por parte del upstream
> >> provider, etc.
> >> 
> > 
> > Muchos proveedores acceden primero a un bloque /32 que pueden justificar
> > sin "pensar" mucho en sus planes a largo plazo, a eso lo llamo "ambiente
> > de pruebas". Cuando haces los planes a largo plazo y te enfrentas a
> > necesitar más direcciones. Básicamente me refiero al paso desde la etapa
> > 1 a la etapa 2 de lo establecido por el RFC 4029.
> > 
> > 
> >> Por ultimo, las facilidades existentes en LACNIC para recibir el prefijo sin
> >> coste, y la facilidad de justificar el tamaño del prefijo desde el primer
> >> momento (ejemplo, tengo N millones de clientes y a cada uno le voy a asignar
> >> un /48, luego asigneme un bloque de al menos Nx/48x180%), tambien me parecen
> >> suficientes.
> >> 
> > 
> > Esta claro que si se hubiera hecho una justificación inicial se podría
> > haber obtenido un bloque mayor. Por eso lo que planteo es que LACNIC
> > pueda estudiar la segunda asignación como si fuera una asignación
> > inicial. 
> > 
> > 
> >> En cualquier caso, quizas Ricardo nos puede aclarar como se determina el
> >> bloque que se reserva con cada entrega, especialmente por si hay posibilidad
> >> "operativa" de que al contar la region con un /12 esta reserva se incremente
> >> aun mas (facilitando mas el crecimiento y la agregacion) ?
> >> 
> >> Saludos,
> >> Jordi
> >> 
> >> 
> >> 
> >> 
> >>> De: Roque Gagliano <rgaglian at antel.net.uy>
> >>> Organización: ANTELDATA
> >>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> >>> Fecha: Wed, 15 Nov 2006 09:58:13 -0300
> >>> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> >>> Asunto: [LACNIC/Politicas] Segunda adjudicación IPv6
> >>> 
> >>> Hola,
> >> 
> >> Quisiera plantear el siguiente cambio para la política de
> >>> asignaciones
> >> sucesivas de IPv6 en la
> >>> región:
> >> 
> >> --------------------------------
> >> 5.2 Adjudicación subsiguiente
> >> 
> >> Las
> >>> organizaciones que ya tengan una adjudicación IPv6 pueden
> >>> recibir
> >> adjudicaciones subsiguientes de acuerdo a las siguientes
> >>> políticas.
> >> 
> >> Segunda adjudicación
> >> 
> >> En el caso de una organización cuente con
> >>> una única adjudicación IPv6,
> >> se realizará por única vez un análisis
> >>> diferencial. 
> >> 
> >> Si una organización en estas condiciones está dispuesta a
> >>> devolver a
> >> LACNIC en un plazo de 6 meses el bloque inicial adjudicado, se
> >>> estudiará
> >> la nueva adjudicación como si se tratara de una adjudicación inicial
> >>> con
> >> los criterios descriptos en la sección 5.1. De esta forma, y sólo en
> >> este
> >>> caso, no valen los criterios descriptos en 5.2.1 (criterio) , 5.2.2
> >> (HD ratio)
> >>> y 5.2.3 (tamaño).
> >> 
> >> --------------------------------
> >> 
> >> Justificación:
> >> 
> >> Esta
> >>> política se plantea para facilitar la transición entre la etapa
> >> piloto y el
> >>> desarrollo extendido de IPv6,evitando la renumeración de la
> >> red.
> >> 
> >> Al menos en
> >>> nuestro caso, el pedido inicial de un bloque IPv6 fue para
> >> ser utilizado en un
> >>> ambiente de prueba, conocer protocolos y
> >> herramientas, pero es insuficiente
> >>> para las necesidades reales de la
> >> empresa.
> >> 
> >> En este momento estamos haciendo
> >>> un plan más ambicioso, pero nos
> >> encontramos que ante la necesidad de más
> >>> direcciones no llenamos en este
> >> momento los criterios de 5.2.1 a
> >>> 5.2.3.
> >> 
> >> 
> >> --------------------------------
> >> 
> >> ___________________________________
> >>> ____________
> >> Politicas mailing
> >>> list
> >> Politicas at lacnic.net
> >> http://www.lacnic.net/mailman/listinfo/politicas
> >> 
> >> 
> >> 
> >> 
> >> 
> >> **********************************************
> >> The IPv6 Portal: http://www.ipv6tf.org
> >> 
> >> Bye 6Bone. Hi, IPv6 !
> >> http://www.ipv6day.org
> >> 
> >> This electronic message contains information which may be privileged or
> >> confidential. The information is intended to be for the use of the
> >> individual(s) named above. If you are not the intended recipient be aware
> >> that any disclosure, copying, distribution or use of the contents of this
> >> information, including attached files, is prohibited.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Politicas mailing list
> >> Politicas at lacnic.net
> >> http://www.lacnic.net/mailman/listinfo/politicas
> > 
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Bye 6Bone. Hi, IPv6 !
> http://www.ipv6day.org
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas