[lacnog] [LAC-TF] Publicación del bloque asignado por LACNIC

[Juan Alejo Peirano]

Ivan como estas?

Creo que el estudio que hace referencia Arturo es el siguiente

https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-ipv6-48-filtering

Espero que te sea de utilidad.

Saludos!

Juan Alejo

El 31 de octubre de 2014, 15:31, Nicolas Antoniello <nantoniello en gmail.com>
escribió:

> +1
>
> Saludos,
> Nico
>
> El sábado, 1 de noviembre de 2014, Arturo Servin <arturo.servin en gmail.com>
> escribió:
>
> Ivan, Nico.
>>
>> Yo no dije que el "no-export" sea el santo grial sino que es tu amiga(o).
>>
>> No resuelve muchos casos pero ayuda para otros donde el load balance es
>> con un solo proveedor y no quieres que se te fugue la ruta desagregada. He
>> visto casos de estos (me los han platicado de forma personal los que los
>> han hecho) y donde no se conocía no-export.
>>
>> Slds
>> as
>> On Oct 31, 2014 1:21 AM, "Ivan Chapero" <info en ivanchapero.com.ar> wrote:
>>
>>> Arturo,
>>>
>>> planteo un escenario donde el multihoming es bastante asimétrico ( por
>>> ej una relación 2:1 en contratación de BW a cada carrier/upstream) y el ISP
>>> de las categorías mas pequeñas.
>>>
>>> En estos casos de un pequeño ISP, aún con un rango asignado de los mas
>>> chicos /22 --- /20, podía moverse con cierta soltura para el diseño del
>>> load-balance BGP del inbound-traffic sobre IPv4 y los anuncios máximo /24.
>>>
>>> Este esquema llevado a IPv6, si se esta tomando como política max /32,
>>> el pequeño ISP queda atado de manos en cuanto a técnicas de load-balance de
>>> alcance global. El no-export tendrá alcance muy acotado en la influencia
>>> del tráfico entrante, y en ocasiones si el carrier no tiene generadores de
>>> contenidos dentro del ASN el inbound-traffic para el prefijo más especifico
>>> marcado y anunciado con esa comunidad es casi nulo (tipicamente escoria
>>> P2P).
>>>
>>> En un caso como este, no me parece que pedir un /32 para anunciar a cada
>>> carrier de upstream se la solución. Menos considerando que estamos hablando
>>> de las categorías mas chicas de ISPs.
>>>
>>> Me gustaría saber si hay alguna revisión o nueva tendencia en cuanto a
>>> que llamar máximo prefijo IPv6 aceptable en la tabla global. Mis viejos
>>> docs hablan de /32 y me llevan a la encrucijada mencionada en el ejemplo.
>>>
>>> Abrazo.
>>>
>>> PD: excelente la experiencia Webcasting del evento este año.
>>>
>>> El 29 de octubre de 2014, 16:08, Arturo Servin <arturo.servin en gmail.com>
>>> escribió:
>>>
>>>>
>>>> Como dice Carlos, "No-export" es tu amigo.
>>>>
>>>> Creo que educación en como usar esta comunidad tendría más impacto que
>>>> una política.
>>>>
>>>> Slds
>>>> as
>>>>
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Ivan ChaperoÁrea Técnica y Soporte*
>>> Fijo: 03464-470280 (interno 535) | Móvil:  03464-155-20282  | Skype ID:
>>> ivanchapero
>>> --
>>> GoDATA Banda Ancha - CABLETEL S.A. | Av. 9 de Julio 1163 - 2183 -
>>> Arequito - Santa Fe - Argentina
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20141031/d215c628/attachment.html>