[Nsi-wg] new state machine

[Henrik Thostrup Jensen]

Hi Tomohiro

Replies inline.

On Wed, 15 Feb 2012, Tomohiro Kudoh wrote:

>> 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.

Right. This makes sense (if there is an NRM involved or not is a secondary 
issue).

>> 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 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.

Yes. I tend to think that we need to seperate replies (one for control 
plane, one for data plane), as we more or less agreed upon yesterday (we 
just haven't quite figure out how yet).

The discussion can be had for release and terminate. Should this be 
returned once the release has been propagated all the way down and back up 
the tree, or once all the links has been teared down. E.g., a 
linkActivated, linkDeactivated, connectionTerminated (don't get to hung up 
on wording).

>> 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.

There where some blank lines here. Did you intend to write something?

If no one knows why we have a seperate cleaning and terminating state it 
might be time to reconsider it :-).

>> 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.

Well, I'm not quite sure what to think of these things myself :-/.

But the releaseFailed and terminateFailed primitives seem quite artificial 
for me.

>> 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.

You are right, good catch.

> 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.

The model you present on slide 3 has a problem similar to mine: If a 
release is send aroud start time, the state machine can either return 
reserved or scheduled. This causes a problem as the requester doesn't know 
if an arm or provision command should be send.

I think it is reasonably clear that the way we respond to 
provision/release and to some extent terminate is a bit artifical/clumsy.

I tried to come up with a new state machine, but I need to think a bit 
first.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet