[lacnog] SLA

[Manuel Zambrano]

Enviado desde mi iPhone

El 27/07/2011, a las 07:21 p.m., Nicolas Antoniello <nantoniello en gmail.com> escribió:

> 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
> 
> 
> _______________________________________________
> 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/6c04cf21/attachment.html>