[lacnog] SLA

[Nicolas Antoniello]

Estimados,

Simplemente algunos comentarios más sobre los SLA: en lo personal creo que
lo único técnicamente razonable para un SLA en conectividad son aquellos
acuerdos que incluyen UNICAMENTE puntos o secciones de la red que son
controladas por las partes que participan en el SLA.
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).

A menudo he visto SLA que incluyen cosas como RTT (a puntos fuera de la red
de ambos participantes del SLA), tiempos de reparación de fallas que no
siempre son atribuibles a alguno de los participantes de SLA, etc...

En resumen, tengamos cuidado cuando hacemos un SLA, de no incluir cosas que
no controlamos.

... Porsupuesto que OTRO tema es que alguna de las partes "asuma"
comercialmente el riesgo e igualmente realice un SLA sobre cosas que estén
fuera de su control... en lo personal no soy muy amigo de esto último.


Como consejo, tampoco es recomendable poner indicadores en el SLA que no
sean medibles o para los cuales no se disponga de herramientas
razonablemente confiables para la medida.

Sobre los que menciona Christian:

>>Ancho de banda efectivo, Caudal (Throughput),
Es fácilmente medible.

>>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).

>>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.

>>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).

>>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.

Saludos,
Nicolas



2011/7/27 Edwin Salazar <esalazar en nextel.net.pe>

> y que les parece Round Trip Delay?
>
> edwin.-
>
>
>
> "alvaro.sanchez en adinet.com.uy" <alvaro.sanchez en adinet.com.uy> wrote:
>
> >Hola Christian.
> >En nuestra área geográfica me parece importante asegurar algún
> >parámetro más, como (in)disponibilidad de enlaces, y atención y
> >tratamiento de fallos. Últimamente he notado una tendencia descendente
> >en la calidad de los operadores.
> >Saludos,
> >Alvaro.
> >
> >>----Mensaje original----
> >>De: christian.oflaherty en gmail.com
> >>Fecha: 27/07/2011 17:39
> >>Para: "Latin America and Caribbean Region Network Operators Group"
> ><lacnog en lacnic.net>
> >>Asunto: Re: [lacnog] SLA
> >>
> >>Gracias Roque.
> >>Los SLA en esos links basicamente incluyen Packet Loss, Delay y en el
> >>caso de Sprint tambien Jitter.
> >>Creo que el Jitter es innecesario para una puerta de Internet de gran
> >>capacidad.
> >>
> >>Nos queda entonces Delay, Packet Loss y habría que incluir tambien
> >>disponibilidad.
> >>
> >>Sin embargo, con el objetivo de asegurar un buen servicio, comienzan
> >a
> >>incorporar otros parámetros. La propuesta que se está considerando
> >>incluye cosas como:
> >>
> >>Ancho de banda efectivo, Caudal (Throughput),
> >>Disponibilidad del Servicio o Enlace,
> >>Indisponibilidad del Servicio operado mediante infraestructuras con
> >>redes propias,
> >>Tasa de error de bits,
> >>Tiempo Promedio de Establecimiento de la Conexión,
> >>Atención y tratamiento de las quejas,
> >>Atención y Reparación de Fallas,
> >>Nivel de congestión de la red.
> >>
> >>Alguno los considera útiles para incluirlos en un contrato?
> >>
> >>Christian
> >>
> >>
> >>
> >>2011/7/27 Roque Gagliano <rgaglian en gmail.com>:
> >>> Christian,
> >>>
> >>> Fijate aquí algunos ejemplos:
> >>> https://www.sprint.net/sla_performance.php
> >>> http://www.verizonbusiness.com/terms/latam/co/sla/
> >>>
> >>> slds
> >>> r.
> >>>
> >>> 2011/7/26 Christian O'Flaherty <christian.oflaherty en gmail.com>:
> >>>> Estimados,
> >>>>
> >>>> Me pidieron una recomendación de un SLA para exigir a un carrier
> >en
> >>>> Centro América.
> >>>> Como no soy muy amigo de los SLA mi respuesta fue algo bien simple
> >(3
> >>>> o cuatro parámetros).
> >>>> Sin embargo desean algo mas formal con parámetros muy estrictos.
> >>>>
> >>>> Qué valores e indicadores creen que se le debe exigir a un carrier
> >por
> >>>> el servicio de Transit para grandes velocidades?
> >>>>
> >>>> Christian
> >>>> _______________________________________________
> >>>> LACNOG mailing list
> >>>> LACNOG en lacnic.net
> >>>> https://mail.lacnic.net/mailman/listinfo/lacnog
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>> At least I did something
> >>> Don Draper - Mad Men
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> >_______________________________________________
> >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
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20110727/c2646a90/attachment.html>