[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: failure detection

Paul Jakma wrote:

There is some graceful renumbering going on. 


      Make sure that new
    communication avoid the deprecated address. But existing
    communication can continue to use the deprecated address until
    the valid lifetime expires.


Other than that first line, those are the semantics we want surely? Transport whose state is inexorably entwined with that prefix is hosed (eg TCP). Shim6 shouldn't be ;). (Nor transports using shim6, eg TCP on top of shim).

Note that for internal communication, TCP continues to work, as long as the prefix stays valid.

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.


But for existing
communication when there isn't an easy way to switch to another address, it isn't clear what to do. (In some cases it might make
sense to reset the ULP connection and recreating it, which will
make it get a non-failed source address, but in other cases it
would be better to wait for the failed address to start working
again.)


Ah, you're working on a "shim6 has intimate knowledge of ULP" model in mind. Yes, things will get tricky that way - which seems a good reason to /not/ do that.

No, I wasn't making any such assumptions. I was commenting on the general aspects of what be desirable and not; I was not commenting on what would be implemented in any particular software layer.
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.

   Erik