[lacnog] SLA

[Nicolas Antoniello]

2011/7/28 Christian O'Flaherty <christian.oflaherty en gmail.com>

>  > Creo que está bien exigir en lo referente a perdida de paquetes en el
> enlace
> > entre los participantes del SLA, retardos y anchos de banda (siempre en
> los
> > tramos en los que participan los que acuerdan el SLA).
>
> Pero si se incluye perdida de paquetes en el enlace entre el proveedor
> y el cliente, y este enlace se congestiona porque el cliente no compra
> mas capacidad, habrá delay y perdida de paquetes en el enlace entre
> los participantes y no es responsabilidad del proveedor.
>
>
-- Cierto, pero asumo que ambas partes miden los indicadores del SLA... si
no, el cliente o el proveedor están "regalados" pues carecen de hechos o
datos que prueben lo acordado. Repito la necesidad de poner en los SLA cosas
medibles y para las que se disponga de herramientas adecudas.


> > A menudo he visto SLA que incluyen cosas como RTT (a puntos fuera de la
> red
>
> Incluir delay o disponibilidad contra algunos root servers podría
> medir el servicio de Internet fuera de la red sin perjudicar al
> proveedor? No?
>
>
-- 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.


> > de ambos participantes del SLA), tiempos de reparación de fallas que no
> > siempre son atribuibles a alguno de los participantes de SLA, etc...
>
> 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".  :)


>>>Ancho de banda efectivo, Caudal (Throughput),
> > Es fácilmente medible.
>
> Yo no lo veo tan facil... El throughput estará afectado por el otro
> tráfico durante la medición.
>
>
-- 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.


> >
> >>>Disponibilidad del Servicio o Enlace
> > Se calcula fácil también.
> >
> >>>Indisponibilidad del Servicio operado mediante infraestructuras con
> >>>redes propias
> > Asegurarse que se trate unicamente de REDES PROPIAS y no de terceros que
> NO
> > controlamos.
> >
> >>>Tasa de error de bits
> > Se mide (para el enlace entre los participantes del SLA o contra algún
> punto
> > de testing provisto por una de las partes... ojo con la elección del
> punto
> > de testing).
>
> Yo creo que esto es un parámetro válido solo para la última milla.
> Conviene mezclar en un mismo SLA la última milla con el puerto de Internet?
>
>
-- En mi opinión, como mencioné en un mail anterior, NO.


>  >
> >>>Tiempo Promedio de Establecimiento de la Conexión
> > Este no entiendo bien a que refiere... además de que estimo que si
> hablamos
> > de TCP, influyen factores externos al carrier como ser temas de
> > configuración de los clientes, etc... y no se hasta donde es un indicador
> > razonable.
>
> Tampoco lo entiendo y coincido con Manuel que una posibilidad
> razonable es que sea tiempo de Instalación en lugar de conexión. Pero
> en ese caso lo dejaría mas claro. Si el sentido original es el de
> conexión de TCP lo veo totalmente innecesario.
>
>
-- Coincido totalmente.


> >
> >>>Atención y tratamiento de las quejas
> > Se puede considerar en este caso los métodos de toma de reclamos y
> tiempos
> > medios de atención (me refiero a atención y NO a reparación).
> >
> >>>Atención y Reparación de Fallas
> > Este es más complicado... separando la atención (que la incluyo en el
> > anterior), en lo referente a REPARACIÓN, allí es donde puede ser muy
> difícil
> > garantizar un tiempo, dado que la falla no se conoce a priori (recomiendo
> > tener cuidado al fijar esto en el SLA).
>
> Pero algo habría que incluir. Por mas que sea un corte de fibra en un
> cable submarino hay que exigirle al proveedor un tiempo de reparación
> máximo o que pague penalidades.
>
>
-- Deacuerdo, pero es difícil establecerlo de antemano en un SLA, para todo
el abanico de posibles fallas, sin caer en que en muchos casos el tiempo
pactado va a ser excesivo y en otros va a ser muy reducido.


> >>>>Nivel de congestión de la red
> > Puede llegar a ser medible, pero no es muy sencillo de evaluar por un
> > externo a la red... si lo voy a incluir, debería tener muy clara las
> > herramientas a utilizar y como lo evalúo.
>
> Coincido...
> Esto puede quedar cubierto con delay y packet loss si el SLA está bien
> escrito.
> La otra posibilidad es pedir un nivel de ocupación máximo en los
> enlaces principales (ejemplo entre países o entre ciudades) y que el
> cliente pueda ver el reporte de utilización de cada uno.
>
> Cuándo contratan puertos de transit actualmente prestan atención a los
> SLA o es algo en desuso?
>

-- En general creo que SI se fijan parámetros de calidad de servicio y se
penaliza (multas, etc...) en los casos de incumplimiento... lo que también
creo es que hay una falta de utilización (o incluso mala utilización en
otros) de herramientas en algunos casos, que hacen que el SLA sea poco
aplicable.

Agrego un par de preguntas más a la lista:

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?
O si aplica algo similar a las respuestas de los servidores DNS
autoritativos que brinden información falsa (en caso que sean atacados) ?
O si permite que alguien dispare un "black hole" en un proveedor con bloques
que no son propios y no está autorizado a ello por quien los tiene
delegados?

... y la lista es medio interminable...

Creo que esto de los SLA hay que manejarlo con mucha discreción y equilibrio
por parte de todos pues a medida que la complejidad y funcionalidad de
Internet crece, crecen también las "amenazas" y la motivación para preverlo
(y prevenirlo) por parte de quién contrata conectividad a un proveedor.
Parece que cada vez menos, el contrato entre cliente y proveedor refiere
exclusivamente a temas de "conectividad", y aparecen muchos otros factores
iguales o más importantes que los tradicionales.

Nicolas
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20110729/95943eaa/attachment.html>