[lacnog] SLA

Lun Ago 15 17:26:43 BRT 2011

Hola todos,
  Recordando este tema de los SLA,m me encuentro trabajando en un
proyecto sobre disponibilidad de servicio y conseguí este: "In Search
of Five 9s – Calculating Availability of Complex Systems".., muy
bueno.

Les dejo el link: http://www.edgeblog.net/2007/in-search-of-five-9s/

Saludos,

Alejandro,

2011/8/1 Carlos M. Martinez <carlosmarcelomartinez en gmail.com>:
> 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
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>