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

[Nicolas Antoniello]

Hola Gustavo,

La respuesta a las preguntas que haces, es justamente uno de los motivos por los cuales 
entiendo necesaria la modificación.

Con lo que no estoy de acuerdo es con esperar a que la comunidad se sienta "segura" para 
modificar algo que (incluso tu estas de acuerdo) debería reflejar únicamente lo que es: 
una política de asignación inicial de direcciones.

Lo que trato de exponer (y no se si esta quedando claro el punto que quiero tratar) lo 
mencionare nuevamente: No se trata de una política para proteger las tablas de ruteo, sino 
de una política de asignación de direcciones IP. Me explico?
No digo que no importe el tema del crecimiento de los prefijos en la "tabla global", pero 
el mezclar imponer un requerimiento técnico con una política de asignaciones es como 
imponer que para que te den la libreta de conducir, vos le pongas a tu coche un limitador 
de velocidad a la máxima aceptada en tu país... se entiende?

El problema del crecimiento de los prefijos, no creo que sea algo que los RIR deban 
regular, porque no es el ámbito de análisis de ese tema, y por tanto, no debería ser parte 
de una política, que de hecho, si miramos actualmente existen violaciones a la misma 
(incluso ahora, cuando el grado de desagregación es muy reducido).

¿Opiniones?

Saludos,
Nicolas.


Gustavo Lozano wrote:
> 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
> 
>