...

...

Full route table size is not a problem. You can burn a hard disk as you mentioned to store it. The issue is getting data in and out of the processor, i.e. number of pins. Core flows are not ameneable to caching. This approach will fail the first time you see a new packet and need to swap from hard disk. Not that it would be very economical, but what are the technical implications of using a solid state device (such as the Quantum's RUSHMORE NTE series) instead of a normal hard drive? Interesting question... even though it's significantly faster than an hard drive, it does have some inherent bottlenecks such as a maximum number of operations per second which might be a little stifling on a backbone core router :) Still, I've never actually tried *that*, so don't know for sure.

There's also latency in other areas - that leads me to think that regular memory is still faster. Finally, it would be attached to the host system through a bus (SCSI, whatever) that's a lot slower than the internal memory bus.

These kinds of devices tend to be a better fit for systems that doesn't have extreme time limitations on processing data such as for mail spool files, etc.

reality check: if you had 100TB of on-ASIC SRAM you would still be screwed. you can't afford the PER-PACKET LATENCY of telco number style portability REFERRAL. once again: ip is a connectionless protocol. each packet is potentially a new route. telcos don't mind a second or two in call setup, because it is CALL SETUP, not 42 times a second. [ credit scott bradner for making this quite clear even to me in some ietf bar ] randy