[Nsi-wg] new state machine

[Tomohiro Kudoh]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSI-SM-Single-Diagram-Feb_15_2012.pdf
Type: application/octet-stream
Size: 132206 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120215/4a36a524/attachment-0001.obj>