[LACNIC/Politicas] Re: Modificaci ó n a la Pol í t ica de Publicaci ó n de Bloques IPv6

Mon Apr 21 19:03:31 BRT 2008

Sin necesidad de entrar a la discusión técnica 
sobre la necesidad de desagregar o no, creo que 
no es necesario modificar la política, porque 
simplemente no representa un problema o riesgo 
para quien decida desagregar su asignación.

Si la comunidad decidiera que LACNIC tiene que 
realizar “enforcement” del punto que estamos 
discutiendo entonces tendrían que definirse 
conceptos (empezando por definir que abarca el 
sistema de rutas inter-dominio de Internet), 
adecuar políticas, crear mecanismos para 
monitorear y definir acciones en caso de no cumplir con el requerimiento.

En pocas palabras, si necesitas desagregar tu 
asignación de IPv6 lo puedes hacer si tus 
upstreams aceptan esos prefijos y seria difícil 
decir que estas violando la política porque la 
misma no tiene el detalle suficiente.

Creo que es adecuado conservar por el momento el 
texto actual porque captura el pensamiento de 
hacer algo para evitar el “problema” del crecimiento de prefijos en BGP.

En un futuro que existan soluciones para el 
“problema” de crecimiento de prefijos, 
multihoming e ingeniería de tráfico sin necesidad 
de anunciar más específicos podríamos revisar la 
conveniencia de quitar el texto de la política.

Gustavo

At 04:28 p.m. 21/04/2008, JORDI PALET MARTINEZ wrote:
>Coincido con Gustavo.
>
>No estoy de acuerdo con esta propuesta, y de hecho habra una presentacion en
>el proximo LACNIC que explica las alternativas para hacer traffic
>engineering sin desagregar.
>
>Creo que no hay motivacion para desagregar y que lo que hay que hacer es
>negociar correctamente con los upstreams, que para eso se les paga. No
>debemos repetir los errores de IPv4.
>
>De hecho, en otras regiones se esta produccione el fenomeno de que se
>asignan prefijos /48 para PI y no estan siendo enrutados y no son visibles,
>y que muchos upstreams se niegan a modificar sus filtros. Asi que considero
>que cualquier cosa que implique que se enrute algo menor de /32 es negativo
>para la region y no debe ser aceptado por la comunidad.
>
>Ademas, no creo que una propuesta de politica pueda decidir que se promueve
>algo similar en otras regiones. No lo veo acorde con el PDP que solo afecta
>a la propia region, como es logico.
>
>Saludos,
>Jordi
>
>
>
>
> > De: Gustavo Lozano <glozano at nic.mx>
> > Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> > Fecha: Thu, 17 Apr 2008 19:41:50 -0500
> > Para: <nantoniello at antel.net.uy>, LACNIC Policy mailling list
> > <politicas at lacnic.net>
> > Asunto: Re: [LACNIC/Politicas] Modificación a 
> la Política  de Publicación de
> > Bloques IPv6
> >
> > Nicolás,
> >
> > Antes de discutir tu propuesta me gustaría
> > obtener respuesta a las siguientes preguntas:
> >     * ¿Cuál es el o los looking glass oficial(es)
> > que utiliza LACNIC para validar este requerimiento?
> >     * ¿Qué sucede si en el o los looking glass
> > oficial(es) que usa LACNIC existe un prefijo
> > desagregado pero en otros looking glass no? Los
> > looking glass muestran una vista de la ³tabla
> > global de BGP² y la vista depende de los filtros implementados.
> >     * ¿Cuál es el ³castigo² por no cumplir con
> > este texto de la política? En cuanto tiempo se
> > realiza el ³castigo² o en otras palabras ¿cuanto
> > tiempo se le da al ISP para ser ³compliance² una
> > vez detectado una violación a este punto?
> >     * ¿Algún ISP de la región maneja un volumen
> > de trafico suficiente para requerir hacer ³traffic engineering² en IPv6?
> > Yo soy libre de filtrar lo que yo quiera en mis
> > ruteadores. Si tienes la necesidad de desagregar
> > tu asignación de IPv6, entonces tu tienes que
> > solicitarle a tus upstream que esos prefijos sean
> > aceptados y ellos pueden decidir hacerlo o no sin
> > importar lo que diga la política de LACNIC.
> >
> > El texto que propones ³Anunciar en el sistema de
> > rutas inter-dominio de Internet el bloque
> > asignado, con la mínima desagregación que le sea
> > posible² es igual a quitar el texto original
> > porque se convierte en una simple sugerencia.
> >
> > Estoy de acuerdo en quitar el requerimiento
> > ³Anunciar en el sistema de rutas inter-dominio de
> > Internet un único bloque, que agregue toda la
> > asignación de direcciones IPv6 recibida² pero
> > creo que no es el momento adecuado. Actualmente
> > existe la percepción en gran parte de la
> > comunidad de que existe un problema con el
> > crecimiento de los prefijos anunciados en el
> > ³sistema inter-dominio² o DFZ o como se le quiera
> > llamar. Desde mi punto de vista no debemos
> > modificar el texto hasta que la comunidad
> > operativa se sienta satisfecha con una solución o
> > un análisis que indique que el problema no existe
> > y simplemente se resuelve con el ciclo de renovaciones de hardware.
> >
> > Creo que tu propuesta deberíamos dejarla
> > congelada siguiendo una lógica parecida a la
> > determinación final del caso Bernstein vs USA.
> > http://en.wikipedia.org/wiki/Bernstein_v._United_States
> >
> > Gustavo
> >
> > At 09:36 a.m. 16/04/2008, you wrote:
> >> Estimados,
> >>
> >> De acuerdo a lo planteado en la reunión pasada
> >> en Margarita, y acorde a la decisión votada
> >> en la mencionada reunión de posponer para este
> >> año la votación de la propuesta, reenvío a
> >> la lista la propuesta, con algunas
> >> modificaciones al texto del año pasado, con la
> >> finalidad de escuchar su opinión.
> >>
> >> Referencia:
> >> LAC-2007-01. Modificación a la Política de Publicación de Bloques IPv6.
> >> Nicolás Antoniello.
> >> http://mail.lacnic.net/pipermail/politicas/2007-March/006897.html
> >>
> >>
> >> Propuesta:
> >> Se propone modificar el punto 5.1.1.c de la Política de IPv6
> >> 5.1 Adjudicación inicial
> >> 5.1.1 Criterio de adjudicación inicial
> >> c) Anunciar en el sistema de rutas inter-dominio
> >> de Internet un único bloque, que agregue
> >> toda la asignación de direcciones IPv6 recibida,
> >> en un plazo no mayor de 12 meses.
> >>
> >> El texto propuesto sería:
> >> c) Anunciar en el sistema de rutas inter-dominio
> >> de Internet el bloque asignado, con la
> >> mínima desagregación que le sea posible, en un plazo no mayor a 12 meses.
> >>
> >>
> >> Y promover el cambio de los equivalentes a nivel de todo los RIR.
> >>
> >>
> >> Motivación:
> >> El problema surge cuando un RIR asigna un
> >> prefijo /28 (por ejemplo) a un ISP que tiene
> >> enlaces a Internet con múltiples proveedores
> >> (multi-homing) usando publicaciones BGP.
> >> De acuerdo con la política de LACNIC (y de la de
> >> otros RIRs), el ISP debe publicar el /28
> >> a través de los tres enlaces sin posibilidad de
> >> desagregación. El problema con esta
> >> política es que al hacer esto el ISP pierde
> >> control sobre tráfico, limitando la capacidad
> >>   de distribuir el tráfico sobre los tres
> >> enlaces diferentes, aún cuando utilice técnicas
> >> de ingeniería de tráfico y/o manejo de comunidades BGP.
> >> Es posible que un prefijo /28 tenga una gran
> >> cantidad de tráfico entrante asociado, de
> >> modo que creo que la política debería permitir
> >> la desagregación (subnets) del prefijo.
> >> En términos generales, entiendo que una política
> >> de asignación de bloques de direcciones
> >> IP puede, en todo caso, recomendar o exhortar a
> >> quienes reciben dicha asignación a
> >> optimizar la forma en que el bloque es publicado
> >> a fin de reducir al mínimo posible el
> >> impacto en las "tablas de rutas" globales, pero
> >> en ningún caso, debería imponer una forma
> >> de publicación como requisito para una asignación.
> >> _______________________________________________
> >> 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
>
>
>
>
>**********************************************
>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
>https://mail.lacnic.net/mailman/listinfo/politicas