[lacnog] Preguntas sobre practicas de desagregación de anuncios en IXPs
Carlos M. Martinez
carlosm3011 en gmail.com
Vie Dic 16 15:37:40 BRST 2011
aggregate == sumarizar creo :-) (por lo menos en mis clases lo enseño
asíi :-) )
Me parece muy buena la iniciativa de crear algun documento sobre el uso
de comunidades y loc-pref y premiar a quienes lo implementen :-)
s2
Carlos
On 12/16/11 2:54 PM, Christian O'Flaherty wrote:
>
> Creo que lo mejor será premiar a los que comiencen a "aggregar" (cómo
> sería en español???)
> Una beca al lacnog o al próximo lacnic puede ser suficiente incentivo.
>
> Otro premio debe ir para los que empiecen a "ofrecer" comunidades para
> que sus clientes y peerings puedan hacer traffic engineering.
>
> Tal vez podemos proponer un standard regional para valores de
> comunidad recomendados...
>
> Christian
>
> On Friday, December 16, 2011, Arturo Servin wrote:
>
>
> De hecho es bastante penoso que seamos la región con el índice más
> alto de desagregación:
>
> LACNIC Deaggregation factor: 4.64
>
> Muy, pero muy alto del promedio:
>
> Deaggregation factor: 2.29
>
>
> On 16 Dec 2011, at 11:38, Carlos M. Martinez wrote:
>
>> Gracias Christian!
>>
>> Personalmente yo también soy de la idea de que tendríamos que
>> trabajar en bajar nuestros niveles de desagregación, ya que en
>> definitiva nos estamos dañando entre nosotros.
>>
>> Y de paso podríamos dejar de tener como región una presencia
>> importante aquí:
>>
>> >> http://www.cidr-report.org/as2.0/#Gains
>>
>> :-)
>>
>> ¿Que podemos hacer para ayudar a la comunidad?
>
>
> Quizá un wall of shame en cada LACNOG?
>
> =)
>
>
>
>>
>> Carlos
>>
>> On 12/16/11 11:22 AM, Christian O'Flaherty wrote:
>>> Hola Carlos,
>>>
>>> Van mis respuestas como ex-operador...
>>>
>>>
>>>
>>> Hemos notado algunas cosas que nos llevan a hacer la siguiente
>>> consulta: ¿Es común que quienes se conectan a puntos de
>>> intercambio de
>>> tráfico desagreguen sus anuncios?
>>>
>>>
>>> Definitivamente. Desagregar suele ser una solución rápida y
>>> simple (aunque no sea prolijo) cuando los proveedores superiores
>>> no dan herramientas para modificar el localpref usando comunidades.
>>>
>>>
>>> Estamos viendo una cantidad importante de bloques /25 de IPv4
>>> anunciados en nuestra región que no parecen ser detectados
>>> fuera de la
>>> misma, por eso sospechamos de que se utilicen en contextos
>>> locales
>>> (IXPs u otras formas de peering local).
>>>
>>>
>>> Algunos proveedores en la región dejan pasar cualquier tamaño de
>>> anuncio. Cuando eso pasa a los "grandes" se filtra por ser un
>>> bloque menor a /24. No ocurrirá solamente en los IXPs o
>>> peerings, tambien puede haber /25 en interconexiones de transit
>>> que el cliente desagrega porque tiene mas de un proveedor y no
>>> le dan comunidades para poder balancear correctamente.
>>>
>>>
>>> Es interesante notar que que muchos de esos /25s al dia de
>>> hoy serian
>>> marcados como INVALID por routers que hicieran validación de
>>> origen,
>>> ya que muchos de ellos estan cubiertos por ROAs que tienen
>>> maxLen de
>>> /24 o incluso menores.
>>>
>>>
>>> Creo que es una buena razón para comenzar con una campaña a
>>> favor del uso de comunidades en los proveedores regionales.
>>>
>>>
>>> La pregunta mas de fondo que nos hacemos es si hay practicas
>>> operativas de BGP en uso común al día de hoy que requieran
>>> consideraciones especiales en el contexto de RPKI.
>>>
>>>
>>> Prefiero que dejemos de desagregar en la región en lugar de
>>> modificar el proceso en RPKI incluyendo excepciones.
>>>
>>>
>>> Un ejemplo de esto podria ser: "necesito generar algunos
>>> /25s que solo
>>> sean validos para mis peers del IXP tal o cual, pero que
>>> para el resto
>>> del mundo no lo sean"
>>>
>>>
>>> Hay algún caso donde sea necesario desagregar y no se pueda
>>> resolver de otra forma?
>>>
>>> Christian
>>>
>>>
>>>
>>> --
>>> --
>>> =========================
>>> Carlos M. Martinez-Cagnazzo
>>> http://cagnazzo.name <http://cagnazzo.name/>
>>> =========================
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>
>>>
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>
>>
>> --
>>
>> --
>> Carlos M. Martinez
>> LACNIC R+D
>> http://www.labs.lacnic.net <http://www.labs.lacnic.net/>
>> _______________________________________________
>> LACNOG mailing list
>
>
>
> This body part will be downloaded on demand.
--
--
Carlos M. Martinez
LACNIC R+D
http://www.labs.lacnic.net
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20111216/66d4b4e6/attachment.html>
Más información sobre la lista de distribución LACNOG