From: Dino Farinacci <[email protected]>Is there a hybrid that we can use? ...Have an ITR, when it boots up, ask its map-resolver for all mappings itmight have cached.Interesting idea... I'll have to think about it for a bit.Off the top of my head, one issue is that it would be moderately complex, asthe ITR would have to download a fair amount of data (i.e. it's not asingle-packet exchange, as most of the current system is). There's also the start-up transient issue... (but I guess that exists now for routing tables,although not on a warm start).
Well if you think a cached database will be long, how long will it take to download the entire NERD cache? And what if caches change all the time like they could if you use the mapping database for LISP-MN.
Does require the map-resolver to be a caching system.Actually, if the local mapping resolution server the ITR talks to (e.g. the 'Map-Resolver', in ALT) is caching, why not have the ITR demand- load? (I.e. the ITR will fill its local cache as it experiences cache misses.) That gives much faster response than going all the way over to the authoritative server for a given destination, and you don't have to have the extra mechanism topre-load the ITR's cache.
One reason to preload the ITR is so it wouldn't have to drop packets waiting for resolution. That is the main advantage of NERD.
There's a certain amount of detail (nothing earth-shaking - e.g. you have to be able to detect outdated cached mappings), but it's LISP-specific, so ifyou want to explore it in detail, let's move the discussion there.
And we have solutions for this, general solutions with are less scalable and specific solutions which are more scalable.
Dino
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
