[arin-ppml] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process
Garry Dolley wrote:
> On Fri, Jun 05, 2009 at 11:06:32AM -0700, Ted Mittelstaedt wrote:
>> Today I can walk into the discount store and by a brand new PC with 2GB of
>> ram for under $350. Yet, Cisco and Juniper are still including as
>> standard ram amounts, miserable, paltry amounts far smaller than that.
Rib and fib are obviously different if related problems, the rib into
the fib generation is itself not a trivial exercise now or in the future.
> Yes, but when we talk about # of routes supported in BGP on Cisco
> hardware, we want those routes to be hardware accelerated. This
> requires TCAM, not RAM.
Actually it doesn't require TCAM, TCAM is one realization as to how to
implement it. Plenty of platforms don't in fact implement it that way,
to pick one example at random Juniper mx switches which use somewhat
exotic and rather fast ddram...
This thing to note is that vendors and their customers are mindful of
table growth and so far it has be bounded within what's possible with
the approaches we currently have or have come up with. This was true
when we were at 10k routes, and it's still true at 300k.
> This link was recently posted and is quite good:
> You can see why TCAM is much more expensive than RAM.
> I can easily do millions of routes on my OpenBSD software router,
Actually it's possbile but it turns out to not be either easy or that
usable. the ability to stick 7-10 million paths in your rib doesn't mean
that quagga or xorp or your choice of routing daemon will stuff them in
the kernel routing table in a timely fashion, and each v4 fib entry in
your kernel is 128 bytes so the size of that data structure and the fact
that it's in a hash table rather than a trie is an issue.
> but the performance of this router is not sufficient for the core of
> my network. I need a hardware router.
ietf raws report
nanog 39 fib bof