Subject: Re: [rrg] NERD

From: [email-masked] (Noel Chiappa)
Date: Wed, 18 Nov 2009 00:32:14 -0500 (EST)

> From: Dino Farinacci <[email-masked]>

    > Is there a hybrid that we can use?
    > ...
    > Have an ITR, when it boots up, ask its map-resolver for all mappings it
    > might 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, as
the ITR would have to download a fair amount of data (i.e. it's not a
single-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).

    > 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 to
pre-load the ITR's cache.

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 if
you want to explore it in detail, let's move the discussion there.

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 18 Nov 2009 15:40:33 -0800

> 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.

> pre-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.

> you 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-masked]
> http://www.irtf.org/mailman/listinfo/rrg