[Nsi-wg] Issue 9 in ogf-nsi-project: The current statemachine does not confirm provisioning until start-time

ogf-nsi-project at googlecode.com ogf-nsi-project at googlecode.com
Wed Dec 14 09:33:49 EST 2011


Comment #5 on issue 9 by tkudoh... at gmail.com: The current statemachine does  
not confirm provisioning until start-time
http://code.google.com/p/ogf-nsi-project/issues/detail?id=9

Making prov.cf/fl to be immediately returned after prov.rq for auto
provsion case is not simple.

One of the advantage of current state machine is its ability to handle skew
of message delivery. That is, if a prov.cf is issued by an ultimate
requester just before the start time, some of the children may receive a
prov.rq after the start time because of the delay of message delivery.
In such a case, some of the children may go through the path of
auto-provision and some may go through that of manual. This is ok in
the current state machine, since all the children will transit to
provisioning state after a transient period, and there are no difference
in message exchange sequences. I believe this advantage should be kept
in the new state machine.

If cf/fl is immediately sent back after a request is made for
auto-provision cases, that cf/fl is not for actual provisioning but just
confirms receipt of the message. That means, we will need another cf/fl
to confirm actual provisioning. Since no request for provisioing is made
at the start time in the auto-start mode, that cf/fl will be sent from a
provider to a requester without preceeding request message. This will
break message symmetricity. In addition, to keep the above advantage,
both message cf/fl and provision cf/fl should be sent from a provider
even in a manual provisioning case. This is not beautiful. Also, it is
not clear what a requester should do if it receives a fail message for
provision request for auto-provision case. That means, some of the
children refuses receiving a message.

I think we need to discuss pros and cons of possble design changes at a
f2f meeting. So I propose to leave this for version 2.0.

This relates to issue #53 and #54.



More information about the nsi-wg mailing list