Hi John, Sorry for not getting back sooner. I was thinking about this and I'm not really sure that we need a two-phase reservation if we have an implicit auto-start. However I think I understand your concerns, depending on how much (or little) in advance the reservation is made prior to the setup of the circuit, there can be some NSAs in different states (e.g. "Reserved", "Provisioned", "Activated"). A status query that walks the tree might return "inconsistent" results. For failure scenarios, clean up can also be a bit more involved. However I think we can handle the convergence issue by ensuring operations are idempotent, and the use of "notify" (or unsolicited PA->RA messages) to aggregate the overall status of the reservation. Having said that, if we want to implement the modify function as you mentioned (i.e. two-phase modify), then we should consider making the reservation function consistent as well. just my 2 cents. Other opinions? Thanks. - Chin On 4/11/12 10:26 AM, John MacAuley wrote:

Auto-start as the only supported mechanism for initiating a schedule is fine by me as I believe most people will use this mode, however, if we do this we no longer have a simulated two-phase commit for reservation. At the moment I can reserve but require a provision before anything goes into the network. I can verify all the reservation segments come back before issuing the provision. If we remove the requirement for provision, then we need to seriously look at introducing the two-phase reservation back into the picture.

My initial $0.02.

John.

On 2012-04-10, at 1:11 PM, Chin Guok wrote:

...

Hi all,

Thanks to Tomohiro and Henrick, here's the latest revision of the NSI state machine based on the discussion at Oxford.

Comments welcomed!

- Chin <OGF34-CS-StateMachine-v8.1.pdf><OGF34-CS-StateMachine-v8.1.pptx>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg