Network SLA

Chris Meidinger cmeidinger at sendmail.com
Wed Mar 18 12:24:38 UTC 2009


On 18.03.2009, at 12:20, Saqib Ilyas wrote:

> I'm back! Thanks again to all those who replied. I am wondering how a
> service provider might assess availability or reliability figures  
> using
> active measurements. Granted that one could set up traffic generators
> between the two PoPs which will be connected to a customer's sites,  
> and then
> after a day of test traffic, I can look for downtimes and  
> restoration times.

This is an exact description of IPSLA. Of course you don't know  
whether a maximum bandwidth was in fact available, because you don't  
want to saturate the link.

> But a one day estimate is not a good estimate for what the service  
> provider
> is promising, which is usually "maximum of 10 hours downtime in an  
> year", is
> it not?

You need a year of measurement.

> Thanks and best regards
>
> On Fri, Mar 13, 2009 at 7:34 PM, Athanasios Douitsis <aduitsis at gmail.com 
> >wrote:
>
>> Anyone interested in setting up his own IP SLA probes by hand and  
>> then
>> collect the measurements into a database, can use a Perl tool we  
>> developed
>> at 2005:
>>
>> http://sourceforge.net/projects/saa-collector
>>
>> It's rather old (SAA got renamed into IPSLA in the meantime) and, in
>> retrospect, the code is a little rough around the edges, but it's
>> nevertheless usable.
>>
>> Regards,
>> Athanasios
>>
>>
>>
>>
>> On Wed, Mar 11, 2009 at 10:20 PM, Andreas, Rich <
>> Rich_Andreas at cable.comcast.com> wrote:
>>
>>> I have found that Cisco IPSLA is heavily used in the MSO/Service
>>> Provider Space.  Juniper has equivalent functionality via RPM.
>>>
>>> Rich
>>>
>>>
>>> -----Original Message-----
>>> From: Saqib Ilyas [mailto:msaqib at gmail.com]
>>> Sent: Saturday, March 07, 2009 6:12 AM
>>> To: nanog at nanog.org
>>> Subject: Re: Network SLA
>>>
>>> I must thank everyone who has answered my queries. Just a couple  
>>> more
>>> short questions.
>>> For instance, if one is using MRTG, and wants to check if we can  
>>> meet
>>> a 1 Mbps end-to-end throughput between a couple of customer sites, I
>>> believe you would need to use some traffic generator tools, because
>>> MRTG merely imports counters from routers and plots them. Is that
>>> correct?
>>> We've heard of the BRIX active measurement tool in replies to my
>>> earlier email. Also, I've found Cisco IP SLA that also sends traffic
>>> into the service provider network and measures performance. How many
>>> people really use IP SLA feature?
>>> Thanks and best regards
>>>
>>> On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi <zartash at gmail.com>  
>>> wrote:
>>>> As I gather, there is a mix of answers, ranging from "building the
>>> resources
>>>> according to requirements and HOPE for the best" to "use of  
>>>> arguably
>>>> sophisticated tools and perhaps sharing the results with the legal
>>>> department".
>>>>
>>>> I would be particularly interested in hearing the service  
>>>> providers'
>>>> viewpoint on the following situation.
>>>>
>>>> Consider a service provider with MPLS deployed within its own  
>>>> network.
>>>>
>>>> (A) When the SP enters into a relation with the customer, does  
>>>> the SP
>>>> establish new MPLS paths based on customer demands (this is perhaps
>>> similar
>>>> to "building" based on requirements as pointed out by David)? If  
>>>> yes,
>>>> between what sites/POPs? I assume the answer may be different
>>> depending upon
>>>> a single-site customer or a customer with multiple sites.
>>>>
>>>> (B) For entering into the relationship for providing X units of
>>> bandwidth
>>>> (to another site of same customer or to the Tier-1 backbone),  
>>>> does the
>>> SP
>>>> use any wisdom (in addition to MRTG and the likes)? If so, what
>>> scientific
>>>> parameters are kept in mind?
>>>>
>>>> (C) How does the customer figure out that a promise for X units of
>>> bandwidth
>>>> is maintained by the SP? I believe customers may install some
>>> measuring
>>>> tools but is that really the case in practice?
>>>>
>>>> Thanks,
>>>> Zartash
>>>>
>>>> On Fri, Feb 20, 2009 at 1:16 AM, Stefan <netfortius at gmail.com>  
>>>> wrote:
>>>>
>>>>> Saqib Ilyas wrote:
>>>>>
>>>>>> Greetings
>>>>>> I am curious to know about any tools/techniques that a service
>>> provider
>>>>>> uses
>>>>>> to assess an SLA before signing it. That is to say, how does an
>>>>>> administrator know if he/she can meet what he is promising. Is it
>>> based on
>>>>>> experience? Are there commonly used tools for this?
>>>>>> Thanks and best regards
>>>>>>
>>>>>>
>>>>> Not necessarily as a direct answer (I am pretty sure there'll be
>>> others on
>>>>> this list giving details in the area of specific tools and
>>> standards), but I
>>>>> think this may be a question (especially considering your end  
>>>>> result
>>>>> concern: *signing the SLA!) equally applicable to your legal
>>> department. In
>>>>> the environment we live, nowadays, the SLA could (should?!? ...
>>>>> unfortunately) be "refined" and (at the other end - i.e.  
>>>>> receiving)
>>>>> "interpreted" by the lawyers, with possibly equal effects (mostly
>>> financial
>>>>> and as overall impact on the business) as the tools we (the  
>>>>> technical
>>>>> people) would be using to measure latency, uptime, bandwidth,  
>>>>> jitter,
>>> etc...
>>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Muhammad Saqib Ilyas
>>> PhD Student, Computer Science and Engineering
>>> Lahore University of Management Sciences
>>>
>>>
>>>
>>>
>>
>
>
> -- 
> Muhammad Saqib Ilyas
> PhD Student, Computer Science and Engineering
> Lahore University of Management Sciences





More information about the NANOG mailing list