Re: [LACNIC/Politicas] Segunda adjudicación IPv6

Wed Nov 22 15:36:35 BRST 2006

Roque, Jordi,

Me parece que no deberíamos meternos en estas 
complicaciones. Aunque sería deseable preveer el 
futuro, no somos los primeros que lo quisiéramos 
hacer con precisión y dudo mucho que seamos los primeros que lo logremos.

Definir una regla para preveer/predecir el 
crecimiento de los clientes de IPv6 raya más en 
temas esotéricos que ingenieriles... Un oráculo, 
la baraja o las estrellas tendrán la misma efectividad en sus pronósticos.

Existen demasiados factores no determinísticos 
que afectan estas predicciones: Aspectos 
macroeconómicos, alianzas comerciales, 
disruptores tecnológicos, cambios políticos (o no 
cambios políticos)... o el simple hecho de que 
despidan al responsable de la Red puede afectar 
de manera muy seria el crecimiento de un ISP... a favor o en contra.

Confiemos en que el staff de LACNIC utilice sus 
propios criterios, sentido común y experiencia 
para estos asuntos. Sabemos que el grado de 
eficiencia no será perfecto pero suficiente como para estar tranquilos.

Saludos,

Oscar

At 03:32 PM 11/21/2006, JORDI PALET MARTINEZ wrote:
>Sino entiendo mal el problema, creo que la solucion menos optima es utilizar
>politicas para resolver problemas tecnicos (Traffic Engineering), salvo que
>realmente sea un caso extremo y entendamos que todos pagamos las
>consecuencias.
>
>Nos hemos mal acostumbrado con IPv4 a hacer muchas de estas cosas, y el
>resultado es la desagregacion que hemos creado y el incontenible crecimiento
>de las tablas de routing.
>
>Las ultimos previsiones hablan de que en 5-7 años necesitaras en tu red
>routers que sean capaces de gestionar 850.000-1.000.000 de rutas. Imaginas
>su coste ? Aun cuando los ISPs mas grandes lo puedan pagar, porque otros
>ISPs, posiblemente mas pequeños, tienen que pagar ese coste por la forma de
>hacer TE de los mas grandes ? Es eso justo y conveniente ?
>
>En el ejemplo que tu indicas, aunque ahora hubiera pedido un /32 y al hacer
>el lanzamiento masivo necesite (hoy) un /28, no deberia de ser problema
>justificarlo y LACNIC modificaria el prefijo asignado para pasar de ese /32
>al /28. Le seguirian quedando suficientes bits en la reserva para el
>crecimiento futuro, por mucho que creciera en la mayoria de los casos ...
>
>Si lo que se desea ahora es anunciar, digamos del /28 varios /32
>desagregados en lugar de un solo /28 agregado, por motivos de TE, creo que
>se podria hacer sin necesidad de desagregacion si se llega a acuerdos con
>los diversos upstreams. Otra cosa es que ellos no quieran colaborar al 100%
>...
>
>Que se pueda hacer con IPv4 no quiere decir que se deba, dado que se esta
>haciendo por medio de desagregacion y eso lo vamos a pagar muy caro en pocos
>años. Es un tema que esta en continuo debate especialmente desde hace unos
>meses en diversos foros, especialmente IETF. Nosotros tambien tenemos un
>proyecto nuevo, RiNG (Routing in Next Generation - http://www.ist-ring.eu)
>que esta intentando buscar una solucion a todo esto.
>
>Pudieramos estar hablando de un proceso de transicion que resultara
>posiblemente mucho mas complejo y caro que la de IPv4 a IPv6 ... Salvo que
>demos con una varita magica :-)
>
>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 19:06:03 -0200
> > Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> > <politicas at lacnic.net>
> > Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
> >
> > Jordi,
> >
> > El problema yo lo veo más por el lado de la ingeniería de tráfico que
> > por el lado del consumo de /48s.
> >
> > Te doy un caso concreto. Ese mismo ISP que puede asignar 50K clientes
> > con el bloque que tiene asignado sólo tiene 4 por ahora pues no hizo un
> > lanzamiento masivo. Ahora, si presentara el pedido inicial en este
> > momento lograría más de un /32, digamos un /28. Esto le permitiría tener
> > políticas de enrutamiento diferentes para diferentes servicios (por
> > ejemplo enrutar servicios residenciales en ciertos enlaces y servicios
> > empresariales en otros, controlar peering de voz y de 3G,etc.) todas
> > cosas que hoy se pueden hacer en IPv4, pero que no se pueden hacer con
> > un único /32. También te da la posibilidad de ir jugando con tus
> > publicaciones a medida que el tráfico ipv6 vaya creciendo.
> >
> >
> > slds
> > r.
> >
> > On Tue, 2006-11-21 at 21:52 +0100, JORDI PALET MARTINEZ wrote:
> >> No lo entiendo. Creo que si la reserva es suficientemente grande, se te
> >> puede "alargar" el prefijo aun cuando al 
> hacer la primera peticion no hayas
> >> calculado nada y no debiera de ser un problema. Ten en cuenta que hay
> >> asignado un /12 !
> >>
> >> Ejemplo, el ISP a pide hoy un /32 y no pide a LACNIC ninguna reserva (cosa
> >> que no debiera de hacer por defecto sin estudiar al menos un poco su red y
> >> expectativas de crecimiento).
> >>
> >> Si ese /32 le permite, digamos que unos 50.000 clientes con un /48 en el
> >> peor de los casos (con una red muy mal estructurada !), aunque este ISP de
> >> repente creciera hasta 8.000.000 de clientes 
> (160 veces su tamaño actual !),
> >> si se ha hecho una reserva de unos 7 bits mas, son mas que suficientes !
> >>
> >> Y si no he hecho mal las cuentas, podria 
> haber unos cuantos miles (8589) de
> >> ISPs de este tamaña en la region con un solo 
> /12 (y si se requiere otro, se
> >> puede pedir a IANA). Dudo que la membresia pudiera crecer hasta 8500 ISPs,
> >> aunque seguro que Raul se pondria muy contento si asi fuera ;--)
> >>
> >> Igual incluso la reserva de 7 bits es pequeña y hay que reservar 12 :-)
> >>
> >> De todos modos yo haria esa reserva como "bits" adicionales respecto de la
> >> peticion inicial. Como indicaba ayer, no es un desperdicio, solo es una
> >> reserva.
> >>
> >> En cualquier caso no me opongo a la politica, sino que creo que hay que
> >> razonar primero si es necesaria o es una cuestion que puede resolverse
> >> operativamente y ademas maximizar de forma automatica la agregacion, etc.,
> >> por mucho que haya falta de prevision a la hora de hacer la primera
> >> peticion.
> >>
> >> 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 18:32:35 -0200
> >>> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> >>> <politicas at lacnic.net>
> >>> Asunto: Re: [LACNIC/Politicas] Segunda adjudicación IPv6
> >>>
> >>> 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
> >>>
> >>
> >>
> >>
> >>
> >> **********************************************
> >> 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