[106112] in North American Network Operators' Group
RE: virtual aggregation in IETF
daemon@ATHENA.MIT.EDU (Paul Francis)
Mon Jul 21 22:13:49 2008
Date: Mon, 21 Jul 2008 22:13:02 -0400
In-Reply-To: <48838271.80200@bogus.com>
From: Paul Francis <francis@cs.cornell.edu>
To: "Joel Jaeggli" <joelja@bogus.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
How's this for a summary of what you are saying:
Some ISPs can get away with software routers, most can't.
Of those that can't, planning ahead by vendors and ISPs has allowed most =
ISPs
to manage reasonably with well FIB growth.
Nevertheless, some protocol tools to help manage FIB growth would be =
welcome
by many.
PF
> -----Original Message-----
> From: Joel Jaeggli [mailto:joelja@bogus.com]
> Sent: Sunday, July 20, 2008 2:23 PM
> To: Paul Francis
> Cc: Adrian Chadd; nanog@nanog.org
> Subject: Re: virtual aggregation in IETF
>=20
> Paul Francis wrote:
> > So, if I get you right, you are saying that edge routers have fewer
> CPU
> > requirements, and so ISPs can get away with software routers and
> don't care
> > about FIB.
>=20
> "ISP's that can get away with software routers" Also multihomed edge
> networks, the costs associated with multihoming aren't evenly
> distributed. The entities most likely to get squeezed are in the =
middle
> of the echosystem.
>=20
> > At the same time, folks in the middle are saying that in any
> > event they need to buy high-end routers, and so can afford to buy
> enough
> > hardware FIB so they also don't care (much) about FIB growth.
>=20
> They care, but you weren't buying 2 million entry cam routers a year
> ago
> to deal with the growth of the DFZ. They bought them because they
> needed
> or would need a million or more internal routes fairly shortly, which
> says a lot about the complexity of a large isp. Assuming the dfz =
growth
> continues to fit the curve it's pretty easy to figure out when you =
need
> enough fib to support 500k dfz entries just as it was when we did the
> fib bof at nanog 39...
>=20
> http://www.cidr-report.org/cgi-
> bin/plota?file=3D%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp-
> =
active.txt&descr=3DActive+BGP+entries+%28FIB%29&ylabel=3DActive+BGP+entri=
es
> =
+%28FIB%29&range=3DYear&StartDate=3D&EndDate=3D&yrange=3DAuto&ymin=3D&yma=
x=3D&Width
> =3D1&Height=3D1&with=3DStep&color=3Dauto&logscale=3Dlinear
>=20
> That's not to say that fib compression is undesirable, that approach
> has
> real benefits extending the useful life of a given platform, but
> there's
> very little about the current situation that is unexpected, or
> intractable.
>=20
> > Are there any folks for whom this statement isn't working?
> >
> > PF
> >
> >> -----Original Message-----
> >> From: Joel Jaeggli [mailto:joelja@bogus.com]
> >> Sent: Sunday, July 20, 2008 1:02 PM
> >> To: Adrian Chadd
> >> Cc: nanog@nanog.org
> >> Subject: Re: virtual aggregation in IETF
> >>
> >> Adrian Chadd wrote:
> >>> On Sun, Jul 20, 2008, Joel Jaeggli wrote:
> >>>
> >>>> Not saying that they couldn't benefit from it, however on one =
hand
> >> we
> >>>> have a device with a 36Mbit cam on the other, one with 2GB of =
ram,
> >> which
> >>>> one fills up first?
> >>> Well, the actual data point you should look at is "160k odd FIB
> from
> >> a couple
> >>> years ago can fit in under 2 megabytes of memory."
> >>>
> >>> The random fetch time for dynamic RAM is pretty shocking compared
> to
> >> L2
> >>> cache access time, and you probably want to arrange your FIB to
> play
> >> well with
> >>> your cache.
> >>>
> >>> Its nice that the higher end CPUs have megabytes and megabytes of
> L2
> >> cache
> >>> but placing a high-end Xeon on each of your interface processors =
is
> >> probably
> >>> asking a lot. So there's still room for optimising for sensibly-
> >> specced
> >>> hardware.
> >> If you're putting it on a line card it's probably more like a RAZA
> XLR,
> >> more memory bandwith and less cpu relative to the say the intel =
arch
> >> approach.
> >>
> >> That said I think you're headed to high end again. It has been
> >> routinetly posited that fib growth hurts the people on the edge =
more
> >> than in the center. I don't buy that for the reason outlined in my
> >> original response. If my pps requirements are moderate my software
> >> router can carry a fib of effectively arbitrary size at a lower =
cost
> >> than carrying the same fib in cam.
> >>
> >>> Of course, -my- applied CPU-cache clue comes from the act of
> parsing
> >> HTTP requests/
> >>> replies, not from building FIBs. I'm just going off the papers =
I've
> >> read on the
> >>> subject. :)
> >>>
> >>>
> >>>
> >>> Adrian
> >>>
> >
