[LACNIC/Politicas] Modificación a la Política de Publicación de Bloques IPv6

Gustavo Lozano glozano at nic.mx
Thu Apr 17 21:41:50 BRT 2008


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




More information about the Politicas mailing list