Re: failure detection

[Paul Jakma <paul@clubi.ie>]

On Tue, 30 Aug 2005, Erik Nordmark wrote:

> The idea with *graceful* renumbering is that the admin knows in 
> advance (hours, days, weeks) that the network will be renumbered 
> and that there is some overlap when both prefixes work. The notions 
> of preferred/deprecated/invalid prefixes in RFC 2462 was designed 
> to handle this case.

> In this model communication (including external) continues to work for the 
> deprecated address up until that address becomes invalid.

> The takeaway point is that forcing a deprecated address, by 
> overloading with a notion of "failed", makes it impossible to tell 
> graceful renumbering apart from something which a multihoming 
> solution can repair.

Yes, agreed. A host wouldnt know the difference.

I'm wondering though, given the language in the RFC, why one would 
ever need to distinguish between a prefix no longer preferred due to 
failure and one no longer preferred due to renumbering? Eg, one way 
an administrator of a multihomed site (in lieue of shim6) might deal 
with a failure is to initiate graceful-renumbering ;).

The RFC provides a mechanism to indicate preference. Does it really 
matter for what reason a prefix no longer is preferred? It's a usage 
consistent with the mechanism, regardless of what that mechanism was 
specified for.

The intended use is outside of the mechanism, and not immediately 
important, surely? Nor is the reason for a renumbering that important 
either, surely?

Sorry to harp on about this, just a 'failed' bit has some problems - 
it requires that it wasn't the router<->host link which failed for 
one, and it seems to me that the high-level difference as to why a 
prefix should no longer be used is not that important.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Truth never comes into the world but like a bastard, to the ignominy
of him that brought her birth.
		-- Milton