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

Re: multi6-functional-dec and re-homing



(cross-posting removed...)

john.loughney@nokia.com wrote:
Brian,

A short comment:


This would support a larger set of possible re-homing scenarios, and I
think it is compatible with the wordings of re-homing definition in
draft-ietf-multi6-architecture-03.txt.

I had a short off-list mail exchange with Marcelo and Jari and they
agreed, but recommended to solicit the list opinion as well.


I have no objections to the text leaving this possibility open,

ditto


but I have some more concerns about actually implementing this.

In a sense, it's to leave this door open that I've been arguing over on shim6 that we should separate the state machine (and by implication, its APIs) from the shim6 protocol.


This is really a shim6 discussion, but if that is what you mean by the charter text, then I think the charter needs to be clarified.
It sounds like you are talking about the re-homing events or triggers
where, which I think should be documented seperate. However, in
a classical state machine, you don't need to detail the events or
triggers which cause the state change, but just the transitions
between the states.


I would support a document (in shim6) that covers the different
re-homing events, etc.

The charter does need to be clarified... that's one reason we've asked for a BOF. You're correct of course, the state machine doesn't have to define the triggers, but it certainly defines the points at which they will be applied.

   Brian