Daniel Carosone <dan@geek.com.au> writes:

> On Wed, Mar 02, 2005 at 09:47:03PM -0500, Greg Troxel wrote:
> > To get b, we would have to do purgeif processing on address removal.
> 
> (At least your earlier version of) b sounds preferable to me, anyway.

I have no objection to doing purgeif processing at address removal
time.  My point was that not doing a full sweep at interface deletion
time (which I'm assuming happens at well less than once a second)
increases the likelihood of subtle bugs creeping back in.  If the
'careful invariant' rather than 'paranoid' version is done, I'd like
to see the full check done under #ifdef DIAGNOSTIC with a flag to make
it panic instead of fix things up.

> I might very well imagine a scenario where the interface is not
> getting detached, but when I delete addresses I immediately want
> cached routes cleared and groups removed.  Say, where I'm building
> something to do load balancing or failover with alias addresses, as
> one hypothetical scenario).

Groups should only be removed on the removal of the last address,
because they are joined on interfaces, not local addresses, despite
the typical API which chooses interface by address.   But your point
that these consistency guarantees should be maintained more carefully
is taken.

Cached routes really need fixing in their own right.  Their use is
only correct if checking a cache gets you the same answer that a full
lookup would have obtained.  I know this has been discussed before,
and I dimly remember a discussion where someone suggested a routing
table generation number, incremented on every change, storing that
with a cached route, and then checking that it's still current before
using the route (equivalent to invalidating caches on every change,
which is what I had been thinking for starters).  Interface deletion
should then increment this too, although normally it will anyway if
addresses are removed.

-- 
        Greg Troxel <gdt@ir.bbn.com>