Hi Henrik, Thank you for your comments and state machine proposal. I've put my comment inline. On Wed, 15 Feb 2012 11:24:34 +0100 (CET) Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi Tomohiro
(long email, sorry).
On Thu, 9 Feb 2012, Tomohiro Kudoh wrote:
Here is a slide of a new state machine.
Thanks for making this.
I am bit puzzled by the introduction of the auto-provisioning state, but I can see it being useful in places where there is an NRM which can do auto-start, and auto-provisioning representing that we are interacting with the NRM to set this up. If this is what you meant, I think it makes sense.
The "Auto Provisioning" is required to wait confirm messages sent back from all the children.
It is still not possible to release an auto-provisioned connection (i.e., going back to reserved from auto-provision), which I think is needed. It will probably not be the most used feature, but since we have the ability to release a provisioned connection it should also be possible to stop an auto-provisioning from happening, which is currently not possible. If we introduce this and the auto-provisioning state, we will also need a state for when auto-provisioning is being cancelled.
OK. I added them.
Event when a connection have been auto-provisioned it should still, IMHO, go through the provision state as this is when the hardware brings up the connection - it is not something that can be skipped. This would cause provisionConfirmed to be emitted twice, which is not what we want. The new state machine is also slightly inconsistent wrt. provisionConfirmed - in auto provision it is emitted when going into auto-provision (i.e., long before the hardware is activated), and in the non-auto-provision it is emitted when the hardware is activated. Could we consider introducing a new primitive, e.g., autoProvisionConfirmed or linkActivated which was emitted when the hardware is brought up. I know this somewhat breaks the nice symmetry of the model.
This is a matter of whether to separate data plane errors from NSI base messages. At Baton Rouge, I have discussed with John and Chin, and we thought it is better to separate them. i.e. prof.cf/rel.cf just mean prov.rq/prov.cf have already been propagated to all the children. I think we need to discuss this matter first.
Finally: I have difficulty seperating the cleaning and terminating state, and they seem mostly equivalent for me, but I hadn't joined NSI at the time it was created, so can someone fill me in. I also not quite sure how to respond to a forcedEnd message.
I am not sure how we can handle prov.fl (and rel.fl) messages. Since they are not related to data plane, they are almost fatal. Going back to the previous state may not make sense. (In most cases, such .fl message will not be sent back, but time out will happen).
I think we have to realize that the current four primitives and associated responses doesn't cut it. These failures can be either fatal (as in: the connection is termianted), or non-fatal (as in: try again later and it might work). However this is not possible to express in the current provisionFailed / releaseFailed primitives. The protocol is designed such that the requester can expect the remote connection to be in a certain state when a one of these primitives are received, but that is not the case here. This is also the case with terminateFailed, which I don't think any of us really know how to handle :-).
A solution is to use the forcedEnd for fatal events, and have provisionFailed / releaseFailed indicate a move back to scheduled - however then there is no need for a releaseFailed.
OK. I think I agree with you.
I've attached a picture of the state machine as I envision it. There are probably still some things wrong with it, and it mostly as basis for future discussion :-).
Your state machine does not allow skew of prov.rq message delivery. If prov.rq is sent by an ultimate RA just before the start_time, some NSA will receive prov.rq before the start_time and some will do after the start_time. In the attached slide, slide 2 is a SM which supports release during auto provisioning, but does not transit to the provisioning state in auto-provision. Slide 3 is a SM which transits to the provisioned state by using non-symmetrical messages. (last two slides are the state machines in which release is not supported)
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Thanks, Tomohiro