RE: State machine / failure detection / rehoming support

[<[e-mail]>]

Brian,

I'm not wedded to my position, so if the bof feels strongly about this, we can
keep these as seperate deliverables, as long as the protocol RFC is a rather
complete specification.

John

> > I'd suggest considering some of the material in the "Multi6 Failure Detection" draft,
> > 
> http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt	
> be taken as a base for the deliverable: "failure & rehoming event description" / 
> "state machine."  However, I'd suggest that Section 5 which actually defines a
> state machine is would better fit a protocol state machine discription and be
> in the main protocol document.  Additionally, I'd much rather have the draft
> generalized into a failure & rehoming detection draft.  
> 
> Its reasonable to think that a host might have some watchdog associated with a 
> particular path, and when the path is available, the shim6 protocol might want
> to rehome to that particular path. A scenario is that there can be a failure
> on a particular path, so when the failure is detected, the shim6 switches to
> another path.  After the original path is repaired, the host might like to rehome
> to it.  This is something that SCTP does, for example.
> 
> Comments?

<hat chair=off>

I still disagree. As I said before, I am very concerned that we shouldn't
preclude later changes/enhancements (imagine introducing HIP identifiers,
for example) and that means the shim6 protocol needs to be clearly
separable from the shim6 state machine. So without disagreeing at all with
John's comments on state machines, triggers, etc - I'd like RFC-statemachine
to be separate from RFC-protocol.

     Brian
</hat>