[LACNIC/Napla] Napla Digest, Vol 69, Issue 2

[Gael Hernandez]

Buenas a todos,

Queria compartir con la unos comentarios en relación a la interconexión de IXPs recogidos a través de la experiencia y observación del mercado de la interconexión de trafico. Los dejo entre lineas:

On 12 Feb 2014, at 16:23, Fabián Mejía <ing.fabianmejia at gmail.com> wrote:

> Hola
> 
> Unos comentarios entre líneas.
> Saludos,
> 
> Fabián Mejía
> El 2014-02-12 09:22, Eduardo Cerdas Moya escribió:
>> Ambos. Para una interconección más efectiva se requieren acá en Mesoamerica más, Mexico tiene planeado la creación de un IXP
>> 
> 
> Una limitante siempre es la cantidad de tráfico, en algunos casos sin CDNs hay muy poca cantidad de tráfico local para cursar en los IXP.  Es importante que las CDN participen del IXP.  

Aunque la cantidad de trafico local intercambiada sea pequeña, los ISPs participantes siempre obtendrán una ventaja comparativa al obtenerlo a través del IXP en lugar de a través de la conexión de transito. Por lo tanto, siempre es mejor tener un IXP que no tenerlo. El peering es simplemente una optimización económica del transito y es por ello, ademas, que los IXP deben de ser lo mas baratos posibles.

Un IXP con precios de acceso demasiado altos, ya sea de manera voluntaria o involuntaria, limita el numero de participantes lo cual limita la utilidad del IXP. Si el coste de acceso al IXP no decrece al ritmo que el coste del transito, el IXP puede estancarse y a largo plazo, convertiste en un fallo de mercado.

>> y  un IXP en  Costa Rica por su posición geográfica serviria de enlace con los de Sudamérica, además de servir para Centroamerica,  así como apoyo a los del caribe. Y estando interconectados  los IXP de LA tendriamos una region con conectividad más robuzta, con más rutas,  permitiendo que como región dependamos cada vez menos de un intercambio en EU.
>> 
> 
> Se hicieron pruebas de interconexión entre el IXP de Quito y el de Bogotá hace cierto tiempo, a través de un operador internacional conectado a ambos lugares,  entre otras cosas se encontró lo siguiente:
> 
> -  bajo tráfico.
> -  complicaciones técnicas por diferentes políticas de peering y de routing (IXP de capa 3 en un caso y capa 2 en el otro).
> -  complicaciones administrativas:  contacto indirecto no efectivo, solución de problemas con mucho retardo.
> 
> Al final el proyecto se dejó a un lado.  
> Esto no quiere decir que la interconexión de IXP sea mala, por el contrario en NAP.EC tuvimos interconectados los IXP de UO y GYE, solo menciono las experiencias que hemos tenido. 
> 

En cuanto a la interconexión de IXPs, nuestra conclusion es que no existen razones por las cuales los IXPs se deberían de interconectar. Dos IXPs interconectados cuestan mas que los mismos IXPs sin interconexión, por lo que el ratio coste/valor se degrada rápidamente. Ademas, como es una única interconexión compartida por todos los participantes, ese recurso se ve comprometido puesto que a corto plazo cada ISP quiere explotarlo al máximo pero a largo plazo esa estrategia acaba por agotar el recurso (o establecer un limite en el uso). Esta situación, compleja en naturaleza y en solución, es auto-impuesta por el IXP y debe ser gestionada también por el IXP.

Debido a todos estos aspectos problemáticos que han provocado fallos en el pasado, muchos ISPs evitan involucrarse en IXPs que consideran la interconexión como opción.


Gaël Hernandez
Research and Outreach Specialist
Mobile:  +44 746 354 1032

Packet Clearing House
http://www.pch.net/
Peering:  +1 415 247-7337 peering at pch.net
NOC:  +1 415 247-7337 noc at pch.net

>> Saludos.
>> 
>> 2014-02-10 22:04 GMT+01:00 Eduardo Cerdas Moya <cerdasmoya.eduardo.cr at ieee.org>:
>> > La integreción de los IXP en Latinoamerica tendría un impacto muy positivo
>> > para toda la región.
>> 
>> Esto quiere decir que se hagan más IXPs o que los IXPs se interconecten?
>> 
>> Slds
>> as
>> _______________________________________________
>> Napla mailing list
>> Napla at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/napla
>> 
>> 
>> _______________________________________________
>> Napla mailing list
>> Napla at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/napla
> 
> _______________________________________________
> Napla mailing list
> Napla at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/napla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/napla/attachments/20140213/efa7edc4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.lacnic.net/pipermail/napla/attachments/20140213/efa7edc4/attachment.sig>