[lacnog] SLA

[Carlos M. Martinez]

Idea para panel en LACNOG: Mejores practicas para establecer SLAs :-)

s2

Carlos

On 8/1/11 1:38 PM, Jorge Villa wrote:
> 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
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog