[lacnog] SLA

Lun Ago 1 13:38:17 BRT 2011

Christian, como estas?

El SLA define a que se compromete el proveedor con el cliente en cuanto a 
calidad de servicio; y es tambien una forma de limitar la reventa de ancho 
de banda que hacen muchos ISP, pues obligas a mantener una determinada 
estabilidad en la operacion. A mi me parece que en cualquier caso, la 
medicion de trafico debe llegar minimo al upstream provider; pues este le 
debe garantizar determinada calidad a mi proveedor, para que este a su vez, 
pueda definir un acuerdo de servicio con sus clientes. Bajo esta optica, 
consideraremos que hay tres segmentos de medicion: trafico de ultima milla 
cliente-ISP, la propia infraestrtuctura del ISP, y un tercer tramo que seria 
del ISP al upstream provider.

Escoger uno o varios puntos de referencia para hacer mediciones, dependera 
del alcance del SLA. Si se escoge medir como referencia un root server u 
otro punto fuera de la infraestructura del ISP, estaremos pasando la culpa 
de lo que sucede fuera del ISP a la medicion en caso de haber problemas, 
pero de igual manera estaremos valorando la calidad de la operacion del ISP. 
En este tema, la idea seria tener un conjunto de mediciones sincronizadas, 
de manera tal que se pueda correlacionar el trafico de ultima milla, con el 
trafico a puntos determinados de la infraestructura del ISP y trafico hasta 
la entrada al upstream provider, con el trafico al punto final escogido 
(digamos un root server). De esta forma, podria demostrarse que con 
independencia del trafico en la ultima milla, el trafico en la 
infraestructura del ISP debe mantenerse con retardos entre un rango de 
valores especificados en el SLA y de igual manera, el trafico al upstream 
provider. Claro, que la gracia de este tipo de mediciones seria no solo a 
nivel de traceroute o ping, sino a nivel de protocolos de aplicacion, porque 
en ocasiones los ISP privilegian determinado trafico (ej: http), pero 
retardan otros (ej: p2p), y mantienen libres 100% el ping y traceroute.

La cantidad de opciones a medir puede ser infinita, pero lo que si me parece 
es que el SLA es bastante personalizado por cada cliente, pero en cualquier 
caso, el ISP tiene que abrir su red a los clientes con los que firma un SLA, 
de manera que estos puedan ver las estadisticas de su trafico en tiempo real 
(saber que significan los datos a partir de tener una idea de la red del 
ISP); y de igual manera, el cliente debera montar sus herramientas de 
monitoreo, de forma que se puedan contrastar las mediciones del cliente y el 
ISP, tal como habitualmente se hace con el trafico de ultima milla.

Bueno, pues muy interesante e importante este tema, asi que seguimos el 
debate.

Saludos,
Jorge
----- Original Message ----- 
From: "Christian O'Flaherty" <christian.oflaherty en gmail.com>
To: "Latin America and Caribbean Region Network Operators Group" 
<lacnog en lacnic.net>
Sent: Monday, August 01, 2011 11:16 AM
Subject: Re: [lacnog] SLA

> Hola,
>
>> -- No estoy tan seguro de eso... creo que sería mejor tener "test points"
>> dentro de las redes de los participantes del SLA. A menos que quieras
>> trasladar los potenciales problemas de terceros, al proveedor.
>
> El objetivo al tener alguna medición fuera de la red del proveedor, es
> medir que tan bien conectado está. Habría que buscar una forma que no
> perjudique al proveedor.
>
> Tal vez se pueden incluir mediciones contra puntos de Intercambio de 
> tráfico.
> La otra es que algunos puntos de Intercambio de tráfico midan a los 
> carriers.
>
>>> Qué pasa si queremos medir la redundancia del proveedor en sus
>>> interconexiones? Si contratamos un puerto a un carrier nacional (por
>>> ejemplo un monopolio) y este carrier solo tiene un puerto de "Transit"
>>> con otro proveedor superior. Cuando le falla su proveedor, aunque el
>>> problema no sea atribuible a él, era algo evitable que con buena
>>> planificación. Sería bueno captar eso en el SLA.
>>>
>>
>> -- Justamente, entonces estría trasladando la responsabilidad... es un 
>> tema
>> delicado pues también podemos decir que sucede si el proveedor tampoco 
>> tiene
>> varias opciones de conectividad... etc, etc... Esto se empieza a parecer 
>> a
>> una "chain of trust". :)
>
> Esta recomendación es para medir a los grandes proveedores, los que
> venden a ISPs. Estos no pueden tener excusa.
> Cuando son proveedores de ISPs deben tener múltiples conexiones para
> redundancia.
>
>> -- Me refiero a monitorear (al cargar un enlace), que el mismo no sature
>> "antes" del ancho de banda pactado... en algunos casos (de operación 
>> reales)
>> ha sucedido que algunos proveedores cuando "limitan" el ancho de banda, 
>> por
>> la forma en que lo configuran, terminan limitando a un ancho de banda
>> efectivo menor al esperado... a eso me refería con lo de "fácil" de
>> controlar.
>
> Esto tambien debería captarse en el SLA y debe incluir a la última
> milla que es donde se hace la limitación de BW. La cláusula podría
> ser:
>
> . Debe ser posible conseguir una utilización plena del servicio
> contratado, utilizando una herramienta que permita transferir
> suficiente cantidad de datos hasta llegar al límite acordado.
>
>> Que sucede si alguien decide poner (si acaso ya no se hizo en algún lado) 
>> en
>> un SLA una cláusula que aplique multas al proveedor si este permite la
>> inyección de rutas en su AS que no estén delegadas a quien las origina?
>
> Podríamos tener una auditoría permanente de los proveedores de la
> región con una lista pública de los proveedores que están anunciando
> cosas indevidas. Algo parecido al "Weekly Routing Table Report" pero
> que incluya anuncios incorrectos y que AS los está anunciando.
>
> Christian
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
> Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana. 
> Cuba. http://www.congresouniversidad.cu
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
> 

Participe en Universidad 2012, del 13 al 17 de febrero de 2012. Habana. Cuba. http://www.congresouniversidad.cu
Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu