[Dundi] Caching

[Mark Spencer]

> 	I disagree that this becomes unmanageable in large networks. The
> whole of Internet route peering works this way (BGP) and it is entirely
> manageable.

Let me clarify, I believe doing so for *phone numbers* is unmanageable in 
large networks, sorry.

> 	Regardless, I was not suggesting that you flip the direction of
> route discovery (I realize now that I was overstating my case). I was
> suggesting that route authorities need a way to tell the peer group,
> "flush this cached route".

Right now I'm experimenting with the pre-cache stuff.  This should allow 
DUNDi to fill a push/pull role in which we can both pull answers as we 
currently do and push answers up, so that nodes with relatively few 
distinct routes (say, less than 1000) can push those routes up.  What is 
worth thinking about here is how to handle patterns...  If we introduce 
the ability to include Asterisk patterns (and the use of something like 
__NUMBER__ in the answer to substitute it in).

I'll start with an implementation that does not support patterns, then try 
to see if we can work out one which *does* support patterns.

> 	The alternative is for carriers run extremely low cache times (if
> you go with an originating entity model for TTLs) to avoid getting stuck,
> and the peer group largely loses the benefit of caching.

Using the precache you could supply an answer that said "NONE" 
essentially.  Since you are providing all answers for a number, you would 
essentially be removing your old cached valid answer and place a cached 
answer that was empty in its place.  This can't have to propagate across 
the entire network but within an enterprise, etc. could be useful.

Mark