[155149] in North American Network Operators' Group
Re: Rate shaping in Active E FTTx networks
daemon@ATHENA.MIT.EDU (Mark Tinka)
Sun Jul 29 10:13:03 2012
To: nanog@nanog.org
From: Mark Tinka <mark.tinka@seacom.mu>
Date: Sun, 29 Jul 2012 16:12:03 +0200
Cc: Jason Lixfeld <jason@lixfeld.ca>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart1894243.0Ej0M5TyTi
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Thursday, July 26, 2012 09:45:14 PM Jason Lixfeld wrote:
> Is that a lot to ask for one box? The ridiculously deep
> buffers required in order to shape to PIR vs. police to
> it (because policing to a PIR is just plain ugly) and
> the requirements to perform any sort of preferential
> packet treatment above and beyond that seem like quite a
> lot to ask of one box. Am I wrong?
Having used middleware in the past to do bandwidth=20
management, this doesn't scale well when your network grows,=20
and when off-net traffic (including that between your own=20
customers) is coming in from several points in the backbone.
On smaller networks, having middleware is easy because your=20
exit points are finite and fairly static. When you grow and=20
start peering, taking on several large customers that want=20
to talk to each other across your network, middleware=20
becomes cumbersome to deploy, because then not only can't=20
you assume that 80% of your traffic is HTTP, but you also=20
can't assume that 80% of your traffic is toward your=20
upstreams. Moreover, adding redundancy (as in multiple links=20
between routers/switches) makes the situation worse, because=20
middleware might not be as inclined, and arbitration of=20
bandwidth management across multiple middleware devices to=20
avoid accidentally over-provisioning to customers gets=20
expensive and complex.
I've since migrated to performing bandwidth management in=20
the router gear itself. This is easy if you're using high-
end kit (think Juniper M/MX/T, Cisco ASR1000/9000), but=20
significantly less so on wireline Metro-E networks (where=20
your Active-E comes in). But not anymore - there have been=20
meaningful developments in this area, and for some I've had=20
the pleasure of deploying, e.g., Cisco's ME3600X/3800X.=20
There also alternatives like Juniper's MX80 (too big, I=20
think, but the smallest you can get from them now) and=20
Brocade's NetIron CES/CER2000 units. These allow you to not=20
only gain decent feature set in the Access, but also let you=20
extend IP (and MPLS) into the edge too for additional=20
simplicity.
Hope this helps.
Cheers
Mark.
--nextPart1894243.0Ej0M5TyTi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJQFUSzAAoJEGcZuYTeKm+GnPcQAJzbFpHPPxOlY+9NBoGzBWX9
K6Cdt3N2jTwLPDdoYlQvTQGtnGp8Do+XYznhhkUHllrEsLUtcYCRoRj1NiOUXrgK
qCWlu2DdNOGSJy/GLYmWY4euAkcn180qdc/oJ8bNgn8BrNlm18KHTx4CPd+ttscc
AC6z5xF0dpH4ErZ50lI5DjTXoFWb4xhoQxNsJyfwznoDK+pkGQqDLLSEqz6/d/d6
zR+J21gWXUk6xc4ktWwgOIcf6pIY8pMTsRHfyRIjgW1Q4bv8ruA8cGUiO2Q7naHG
gRDbhwQBhgrLFH77UlesdJdDdgj/REJSPuHGM8zeP0NFNj37bRPFe4Jrd38mXCjG
GTHozyK9Qsjyy86bdMU7VmdMeOIiYocv/slmM8aG6h0A+D2fygJSZw9XuuwXuBMe
evgqyMM5AmYhdcyWgQ3/pJxq83NCXdl46FH07Fezyqwhr6vBJ/0OGpzYiYg5HQ0j
VH+rKRLAmpgMMR29dLFnoU4GW10IArDToWQPzDa7xy434Lh2vG4prsq+vkBlUkgU
jYUiRYxh+8f8jEbUNr2P/g90wACVp5D+G+WxfEWybLcWBlKYcC3s/S31jkRsOtws
DknHowcA/NOdgi5VCXAbQXV8uOfC9Y06XLyHk+M65S5H9vUtxeA7FzIMoFWzCN5l
bMoN30WrqkTdtmNn7+oL
=w2yH
-----END PGP SIGNATURE-----
--nextPart1894243.0Ej0M5TyTi--