[116285] in North American Network Operators' Group
Re: Ahoy, SLA boffins!
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Jul 29 10:34:12 2009
Date: Wed, 29 Jul 2009 10:33:14 -0400
From: Leo Bicknell <bicknell@ufp.org>
To: nanog <nanog@nanog.org>
Mail-Followup-To: nanog <nanog@nanog.org>
In-Reply-To: <8070E7E5-07BF-424E-9A2F-FC736BA26E66@pch.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I think the desired goal here is to separate the access SLA from
the backbone SLA. That is, consider a simple picture:
Network Cloud------Provider Edge Router-----Local Loop-----Customer Router
Network availability is the % of the time the customer router and
provider edge router can communicate, and is designed to measure
if the local loop is up. For instance, let's say the provider edge
router looses all its uplinks to the Network Cloud, your local loop
is up and functioing but you have 100% packet loss to all destinations.
The "packet loss" SLA kicks in on a per-destination basis. Everything
is up and working, but the provider has a full circuit and is
dropping 20% of the packets on that link. You catch it, you get a
credit.
I think the technical reason why these are separate has to do with
the expectations. If my local loop is dropping 0.5% of the packets
due to errors, it is broken and must be fixed. If some random
destination on the Internet is dropping 0.5% of the packets well,
that's a normal day in the life of the network. Plus, if your local
loop takes errors then you get a credit. However, if there's a
full link in the backbone but none of your packets take it, and
thus you are unaffected, you don't.
Now, having said all that, and having been one of the people who've
attempted to communicate sane, rational, technical ideas to marketing
and legal the chance that anything sane made it in the actual contract
is, well, nil.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iQIVAwUBSnBdqLN3O8aJIdTMAQLOVhAAumFKADbkFcXPeUyKJP7Fo7k/NJrb8oz+
j3hpGb2W7rQeovPhPWumI6/WhEYaXL4B9ALFQW4wa0ICUcM6B5VNbTw9e2JxY+jr
ZOUo5eCQf59Ck+TQM2/Ed7O41OML2jdsJe2dIRdrHGdQlEUKHCbBaTrK17UdBqr6
DlMd5gdFogBGxG0IkJNtItfG1JbSNY8+QZ/Voq76ASP2BQMLEYgFrErq+G+d7YC0
BR/ypr1vK/f+BWo6BY1lYX2E2syDfgI8NfflIDEnBx1ftrtPKkni0m8fdXY1ZO2t
NXa/+tIViv6/wgbkeIhl4lh8PTBh+TUbiyKg5/tRNHLOrTXzOQGOW3i2YPDdpdcn
PpPWEJmbSgApXpv/BxBHAvMsmDHK6x3OORjzxEUENt2FnSRmZdbkLigp7O9XetpG
HAM43z5nDQwIgvsi4BRnczW4tyvYFoWapnBwEAqyGIEfc3LGTElJD8KKgl0W+ihc
mCjND0lXFBhciXGrPIvP9GWemXpGCsogYmU65I78psuhZe0gTinnOXBDKaOWrr/3
rVmk5gDtUhaPixJEZfkmdQfYn/0TtD5rHiCKoNb+3BYjYuceKgUA+WgoBGkL46Oe
RMQSD7vyYv0/VAFEk2dhQ0t7liZ9k9ZLB8WbX8cRpK3O4C7YI3qcY2tzC+RV4p+1
ZuunZmubqiw=
=jKNs
-----END PGP SIGNATURE-----
--3MwIy2ne0vdjdPXF--
