[lacnog] SLA

Christian O'Flaherty christian.oflaherty en gmail.com
Jue Jul 28 09:47:27 BRT 2011


Hola,

2011/7/27 Nicolas Antoniello <nantoniello 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.

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

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

> Sobre los que menciona Christian:

Aclaro nuevamente que no son parámetros que yo proponga... mas bien
todo lo contrario :-)

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

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

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

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

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

Christian

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



Más información sobre la lista de distribución LACNOG