On Wed, Dec 3, 2008 at 1:18 PM, Scott Brim <[EMAIL PROTECTED]> wrote: >> It need only expire the cached map entry for inactivity. Which it will >> tend to do over tens of minutes with no use > > Correct me if I'm wrong but it seems to me that whatever higher > stratum NTP servers are used will be (1) well used, and (2) in popular > prefixes. What servers do you use? My little MBP uses apple.com and > nist.gov. I doubt that they would be removed from the cache.
In Red Hat Linux, the default installation is: server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org pool.ntp.org consists of a large, random assortment of volunteers who have decided it would be cool to run a public NTP server. Two lookups over time get two more or less randomly chosen sets of IPs: nslookup 0.pool.ntp.org Server: 10.187.99.2 Address: 10.187.99.2#53 Non-authoritative answer: Name: 0.pool.ntp.org Address: 208.38.65.35 Name: 0.pool.ntp.org Address: 4.79.132.221 Name: 0.pool.ntp.org Address: 64.247.17.255 Name: 0.pool.ntp.org Address: 65.255.217.202 Name: 0.pool.ntp.org Address: 72.167.54.201 nslookup 0.pool.ntp.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: 0.pool.ntp.org Address: 65.111.164.223 Name: 0.pool.ntp.org Address: 65.255.217.202 Name: 0.pool.ntp.org Address: 69.31.43.10 Name: 0.pool.ntp.org Address: 72.167.54.201 Name: 0.pool.ntp.org Address: 75.144.70.35 Bear in mind that an individual ntp client in normal operations backs off to 17 minutes between packets and can be configured to go more than a -DAY- without sending a packet. > If a > site communicates with zillions of others, so there is a lot of churn > in the cache, it probably wants to reconsider its caching strategy in > the first place, but second, steps can be taken to make sure a map for > a particular prefix doesn't get squeezed out. (That doesn't mean it > doesn't get refreshed as TTL expiration approaches.) Here's a free solution: Don't remove entries from the cache unless you run out of memory. After the short, perhaps 30-second TTL expires, the next packet you send to that destination triggers a map refresh in order to statisfy http://bill.herrin.us/network/statechange.html . The results of the refresh will, if necessary, delete the old entry. While you wait for the results of the refresh, keep using the expired map. 99.9% of the time this will be the correct action. For the rest, its a normal, everyday black hole anomaly that clears in a few hundred milliseconds when the refresh comes in. The hitch is that lisp sits rather closer to the core than most of the pull-cache solutions that have been discussed. Are you sure you're going to have enough cache to keep 20 or 30 minutes worth of *all* the destination addresses that the site's folks have sent packets to? I think I'd want to see some metrics on how many unique destination addresses leave the biggest site that would be behind just one ITR. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
