On Sat, 25 Sep 2004 14:33:42 +0100
Steven Whitehouse [off-list ref] wrote:

On Sat, Sep 25, 2004 at 11:09:33AM +0200, Harald Welte wrote:

quoted

On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote:

quoted

So let's discuss #4.  It is the first idea I had to combat the
"problem", but honestly right now I am beginning to think that
the real solution is to simply remove the INCOMPLETE checks
altogether.

Neighbours are a sub-cache of the routing cache.  Therefore when
a neigh entry has a singular refcount, no routing cache entry
points to it.  No routing cache entry, we're not sending packets
to that neighbour any time soon, so there is no reason (especially
during strong pressure) to hold onto such entries.

I am sure this is valid for IPv4 and IPv6.  How about other users of the
neighbour cache, do they share this assumption?  I have to admit that I
never looked throgh the ATM or 

I cannot see this being any problem for DECnet at all.... the entry you
most want to hold on to is the entry for the default router of which
there will be a max of one per interface. This applies only in end node
mode and we hold a ref count to it anyway, so that it should have the
same effect as the routing cache entry holding a ref,

And ATM clip is for ipv4's routing layer too so...