where was my white knight....
Leigh Porter
leigh.porter at ukbroadband.com
Tue Nov 8 22:15:03 UTC 2011
On 8 Nov 2011, at 21:37, "Leo Bicknell" <bicknell at ufp.org> wrote:
> In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote:
>> I think actually it wouldn't have caused more validation requests, the
>> routers have (in some form of the plan) a cache from their local
>> cache, they use this for origin validation... there's not a
>> requirement to refresh up the entire chain. (I think).
>
> I kinda think everyone is wrong here, but Chris is closer to accurate.
> :P
>
> When a router goes boom, the rest of the routers recalculate around
> it. Generally speaking all of the routers will have already had a
> route with the same origin, and thus have hopefully cached a lookup
> of the origin. However, that lookup might have been done
> days/weeks/months ago, in a stable network.
>
> While I'm not familar with the nitty gritty details here, caches
> expire for various reasons. The mere act of the route changing
> paths, if it moved to a device with a stale cache, would trigger a
> new lookup, right?
>
> Basically I would expect any routing change to generate a set of
> new lookups proportial to the cache expiration rules.
Which may very well fail because all the routing is hosed. I'm not all that familiar with the potential implementation issues, but I would think that network-local caches would be in order.
Even with local caches, I would expect a high incidence of change to trigger something sensible to mitigate this kind of craziness from happening. I am sure enough people have had incorrectly scaled RADIUS farms blow up when a load of DSLAMS vanish and come back again not to repeat such storms.
--
Leigh Porter
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
More information about the NANOG
mailing list