Re: virtual aggregation in IETF

* Joel Jaeggli · * Sun Jul 20 14:24:02 2008

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.

"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.
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.

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...
http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&range=Year&StartDate=&EndDate=&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear
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.
Are there any folks for whom this statement isn't working?
PF
-----Original Message-----
From: Joel Jaeggli [mailto:[email protected]]
Sent: Sunday, July 20, 2008 1:02 PM
To: Adrian Chadd
Cc: [email protected]
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