At the risk of continuing this bad flashback...
A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with 4 GB of route memory default size. Juniper's T320 and T640 come with 2 GB of main memory default size. That should take them to some higher number of routes.
No, sorry, that's route processor memory and has nothing to do with the forwarding table. Actual forwarding in a distributed architecture has to be distributed to the line card. Further, given modern forwarding rates, typical PC DRAM (50-70ns) is vastly inadequate. Instead, higher speed SRAM (2-8ns) is a necessity. The cost differential between these two technologies is quite large. And we won't even open the subject about what that memory is *really* getting used for.
On the other hand a large DFZ routing table would simply dampen its growth by itself. If it gets to costly to multihome because of the hardware requirements only few would be able to so. Ergo we have a negative feedback system here keeping itself in check. Case solved and closed.
The costs for multihoming are borne by everyone *else* in the network who has to carry the extra prefixes. Further, market pressures force carriers to advertise customer prefixes regardless of the costs to the remainder of the network. Case not solved. Multihoming can never be just a small portion of the growth of the DFZ table, as multihoming so far appears to be a fixed percentage of the sites on the net. Thus, even if we solve all of the single-homed sites through good aggregation, if we do not solve the multi-homed sites properly, their numbers will continue along the same growth curve, only time shifted, and will eventually dwarf the current routing table. Before we continue this thread, folks might want to reread the CIDR archives from a decade ago. We are still having the exact same argument, with the exact same conclusions and the exact same results. Yes, the scale has changed slightly, but we are nowhere closer to a true solution. Tony