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. 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. 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. 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. 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 :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet