[Napla] Servicios en los NAPs

Michael De Leo (mdeleo) mdeleo at cisco.com
Tue Feb 21 14:37:04 BRT 2006


Yuri,
 
Si estan revisando hacer una actualizacion de la infrastructura del IXP el reducir los costos es importante. Creo que el modelo de recuperacion del costo es importante sin impactar a los integrantes de menor trafico. Uno de los problemas reales del IXP es hacer la actualizacion de la infrastrucutra pero ser "justo" en el costo por integrante por su trafico deseado.

Pero surgen preguntas basicas como: 
 
- Si se adquiere un switch de puertos 10/100/1000 Mbps el costo de un puerto realmente es igual si lo usas en 10 que en 1000 Mbps (idealmente). ¿Entonces no sera mas justo simplemente hacer el costo para cada integrante para cada puerto igual?
- Si todos deciden usar el puerto a 1000 Mbps y suponiendo (deseo que tengan este problema de exito) que se llena la capacidad del puerto, la eleccion del modelo del switch y su capacidad interna de conmutacion de paquetes cuesta mucho mas que el switch basico 10/100/1000. ¿Van a adquirir un equipo que resuelve el problema de hoy o al menos tiene crecimiento para los proximos 3 a~os sin tener que pedirle a los integrantes otro cargo para actualizacion?
-¿Como cobrar a los puertos vacios? ¿Que pasa cuando se llenan de nuevos integrantes?
 
De lado de la infrastructura hay muchas opciones, que de parte de Cisco y otros fabricantes. Los costos de mantenimiento y disponibilidad de sustiticion de partes debe ser considerados.
 
Suponiendo que el IXP es sin fines de lucro las decisiones de costos lo aprueban los miembros del IXP.Ellos pueden tambien sugerir cambios en arquitectura como tener IXPs redundantes o tener opciones de dos puertos de dos switches en el mismo sitio. Como menciona Bill, mucho depende de los demas costos de operacion para indicar si impacta el costo de un puerto a 10/100 o 10/100/1000 Mbps por la compra del equipo o los costos adicionales de administracion.
 
Mike
 
 

________________________________

	From: napla-bounces at lacnic.net [mailto:napla-bounces at lacnic.net] On Behalf Of Yuri Herrera B.
	Sent: Tuesday, February 21, 2006 6:52 AM
	To: napla at lacnic.net
	Subject: Re: [Napla] Servicios en los NAPs
	
	
	 
	Muchas gracias Bill.  
	 
	Lo que indicas tiene mucho sentido; un aumento del costo en función del tráfico en efecto haría que el ISP se sienta penalizado en vez de premiado por el valor que aporta al NAP y por otro lado, un aumento del precio en función de la capacidad del puerto inhibiría a algunos ISPs a hacer el upgrade, lo que en efecto puede perjudicar el servicio.
	 
	El escenario de precios iguales para todos es entonces positivo, pero siempre que estos precios estén bien calculados para poder, no sólo lograr una buena operación, sino tener también capacidad de inversión futura (para renovación de equipos por ejemplo). Esta forma de trabajo hace entonces también necesario definir una serie de políticas que garanticen el uso adecuado del recurso. Por ejemplo un ISP que trafica muy poca información, pero que ocupa un puerto de alta capacidad, generaría un costo innecesario. Por lo tanto, si bien la utilización de un puerto de mayor capacidad no tendría un precio extra, se debería de cumplir con el requisito de llegar a cierto nivel mínimo de tráfico para tener el derecho de acceder a dicho puerto; por otro lado, un ISP que no llegue al nivel de tráfico mínimo requerido para el tipo de puerto que ocupa (suponiendo que no hayan puertos más pequeños ya disponibles), podría tener que pagar un sobre precio.
	
	Saludos,
	
	Yuri
	 
	Moderador - Lista NAP.La
	
	********************************************************************************
	Yuri Herrera Burstein
	
	NAP.Perú
	Gerente General
	
	* www.nap.pe <http://www.nap.pe/> 
	*    yuri.herrera at nap.pe
	*   (511) 712-0901 / 712-0902 
	
	NAP.Perú ... Construyendo Juntos la Sociedad de la Información
	********************************************************************************
	 
	-----Mensaje original-----
	De: napla-bounces at lacnic.net [mailto:napla-bounces at lacnic.net] En nombre de Bill Woodcock
	Enviado el: Lunes, 20 de Febrero de 2006 03:51 p.m.
	Para: napla at lacnic.net
	Asunto: Re: [Napla] Servicios en los NAPs
	 
	      On Mon, 20 Feb 2006, Yuri Herrera B. wrote:
	    > ...estamos explorando alternativas de cobro por tipo de puerto (10, 
	    > 100, 1 G) o por tiempo o por trafico cursado.  ?Qui experiencias han 
	    > tenido en ese sentido?
	 
	Offering 10/100/gig ports either at different prices, or based upon 
	utilization, is common.  Charging based upon utilization is not.  You have 
	to remember that the value of your IX is dependent upon the volume of 
	traffic which crosses it, so penalizing participants for passing more 
	traffic is a reverse-incentive.  That is, you don't want to charge people 
	more money for doing what you want them to do (send more traffic), and 
	less money for doing what you _don't_ want them to do (use up a port but 
	send less traffic).  Therefore, what generally works best is to charge 
	everyone the same price, as low as possible, but to prioritize access to 
	higher-speed ports based upon need.  
	 
	Also, if you don't charge more money for a faster port, it lessens the 
	financial disincentive for participants to upgrade...  Again, the IX works 
	better if none of the participants have congested ports, so it's good for 
	the IX if participants all upgrade when necessary.  Thus, you don't want 
	it to be costly for them to do so.
	 
	Anyway, this is how large noncommercial exchanges like Seattle and Toronto 
	and Hong Kong do it.  
	 
	There are other exchanges, like LINX and AMS-IX, which are noncommercial, 
	but maintain very large/expensive staff, and thus they don't present as 
	compelling a value proposition as they would if they were able to keep 
	their costs under control.  That's why there are competing (less 
	expensive) exchanges in London and Amsterdam, but not in Seattle and 
	Toronto.
	 
	                                -Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/napla/attachments/20060221/2f4d5a90/attachment.html>


More information about the Napla mailing list