[Nsi-wg] new state machine

[Henrik Thostrup Jensen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nsi-statemachine-htj-20120215.pdf
Type: application/pdf
Size: 8194 bytes
Desc: 
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120215/3c640a6e/attachment-0001.pdf>