[Nsi-wg] Reserved State Machine

[Tomohiro Kudoh]

Hi Henrik and all,

I don't think the RSM Henrik has proposed is clearer. It is semantically
same as the original RSM, and message sequences between revisions (i.e.
new reservation request can be only received when the previous state
machine is in committed or aborted state) is not clear. Just adding some
explanation words to the original RSM would be better.

But I might be biased since I was involved in the design of the original
state machine.  Peoples, please give you comments.

Tomohiro



On Thu, 25 Apr 2013 13:09:30 +0200 (CEST)
Henrik Thostrup Jensen <htj at nordu.net> wrote:

> Hi
> 
> I think some of the confusion around the Reservation State Machine (RSM) 
> comes from that a connection can have multiple revisions and that each 
> revision can actually go through the states. This makes it very tricky to 
> have a state machine that works across multiple revisions.
> 
> A better approach might be to have an RSM per revision. I have attached a 
> PDF of how I think such a state machine could look. Reserve_Aborted is now 
> a stable state, indicating that the revision has failed. A new revision 
> can be started from all stable states.
> 
> This makes it very clear where each revision is in its lifecycle.
> 
> There could be a state after Reserve_Committed to indicate that the 
> reservation has been superseeded by a new revision, but since we probably 
> wouldn't expose that, I don't think it is strictly needed.
> 
> The Provision State Machine (PSM) and Lifecycle State Machine (LSM) should 
> be per connection.
> 
> 
> On a side note: I think having 2PC will create more problems than it 
> solves, as getting that to work in a multi-domain environment is going to 
> be very tricky.
> 
> 
>      Best regards, Henrik
> 
>   Henrik Thostrup Jensen <htj at nordu.net>
>   Software Developer, NORDUnet