Hi,
Le 07-mars-08 à 06:28, Victor Grishchenko a écrit :
On 07/03/2008, Michael Meisel <[EMAIL PROTECTED]> wrote:
Enforcing a maximum on new destinations per source address is much
more
easily and effectively done at TRs, which, in APT, are meant to
be at PE
routers of transit providers. The load at each TR should be
manageable,
and the excess traffic never reaches the default mapper.
I also did some worm-related troubleshooting and my intuition tells me
that something will surely explode in such an architecture. Just a
feeling, probably because you'll have to keep too much state per
packet or because end hosts will get another leverage over the routers
in terms of operations per packet...
200.000 entries in a routing table is a lot
200.000 packets is not much
200.000*40 bytes = 8Mb is just nothing
Finally, I cannot find why EID-to-RLOC cache is significantly smaller
(preferably, in terms of big-O) than the EID-to-RLOC database. Is
there any study of that issue?
You can get a look to:
http://inl.info.ucl.ac.be/publications/cost-caching-locatorid-mappings
There you can find the size of a cache.
The size of the database, assuming granularity of prefixes annonced
by BGP, is just the size of a BGP table.
Cheers
Luigi
--
Victor
--
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
Luigi Iannone
[EMAIL PROTECTED]
