Tony, >Obviously you can optimize, but even a naïve implementation >has to have a bound on the number of reassemblies that it can >have in progress at any given time. Again a trivial >implementation is to provide a max sized buffer for each such >reassembly.
A Linux box is a far cry from a carrier-grade router, but Linux sets high/low water marks of 256K/192K for its cache of outstanding IPv4 reassemblies. It also provides a tunable parameter for how aggressively to purge stale reassemblies. With SEAL, I believe the tuning parameters for reassembly of IPv4-fragmented SEAL packets can and should be clamped down very tightly indeed even for high-end routers (i.e., even to the point of dropping all IPv4-fragmented SEAL packets) since SEAL will very quickly tune out all IPv4 fragmentation. Greater care must be taken with SEAL-layer reassembly, since SEAL-segmented packets need to be reassembled and forwarded with high assurance. However, SEAL-layer reassembly in itself is an indication that there are marginal links in the path that can be immediately identified and a trouble ticket called in to their owners. The interdomain routing community peer pressure alone would serve as ample motivation for upgrading obsolete network gear to new and relatively inexpensive equipment that supports jumbo-clean links. The eventual end state is a jumbo-clean interdomain core, with a transition timeframe that parallels the rollout of LISP itself. Fred [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
