[Dundi] Caching

[Landon McDowell]

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

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

	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.

	I fully recognize that this introduces a new host of problems. DOS
attack becomes a much greater problem, for example. But dampening is going
to have to be addressed sooner or later anyway.

	Lastly, please allow me to clarify. I was not suggesting that
DUNDi needs to become BGP for telephone numbers. TRIP clearly already does
that. I was suggesting that I would like to see it become a bit more like
a routing protocol.

			Regards,
			Landon McDowell


On Sat, 23 Oct 2004, Mark Spencer wrote:

> This becomes totally unmanagable with a large system because essentially
> every node must know the routes for all numbers as they come and go.
> Definitely a bad idea.  However, we recently added a "PRECACHE" function
> to DUNDI so that, for example, smaller nodes could "PRECACHE" answers up
> to a more master node.
>
> If this works, then we could setup a "best practices" policy that
> nodes with less than a thousand (or whatever the magic number is)
> routes would simply "PRECACHE" their answers up to one or two other nodes,
> rather than actually be queried the whole time.
>
> What do people think about this?
>
> If that's what you think, you need to look at TRIP.  DUNDi is not, nor
> should it be, what TRIP is.  This is about "asking" not about advertising.
>
> Mark
> _______________________________________________
> Dundi mailing list
> Dundi at lists.digium.com
> http://lists.digium.com/mailman/listinfo/dundi
>
>