Network SLA

Zartash Uzmi zartash at
Mon Feb 23 08:19:31 UTC 2009

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

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?


On Fri, Feb 20, 2009 at 1:16 AM, Stefan <netfortius at> 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

More information about the NANOG mailing list