Hi Tomohiro - these are good points -- On Oct 6, 2010, at 11:28 AM, Tomohiro Kudoh wrote:
Hi all
I would like to point out several things.
1. Automatic cannot be used for on-demand (or immediate) reservation for tree. When you want to provision an inter-domain connection through multiple networks (domains), some networks will provision requested intra-domain connections even if some networks denies the request. My understanding has been that on-demand actually had to do a reservation and then immediate provision. I think this is implied here as well. So, the problem is that a) a reservation can be made and then backed out if a parent NSA is not successful in getting making all parallel reservations; and b) if provisioning is automatic then the reserved segments will be provisioned and then the reservation backed out - presumbably requiring the provisioning to be backed out.
So, for on-demand, the requester must confirm all participating NSAs agree to provide intra-network connections first, and then let all NSAs to provision. So, explicit (manual) provisioning must be used for on-demand. This makes sense to me.
For automatic, the start time should be sufficiently in future. (2PC solves this problem, but we decided to not to use 2PC for ver. 1) Defining "sufficiently in the future" is the problem here. Presumably this means far enough in the future that the reservation can be backed out in necessary by the parent before the NRM starts automatic provisioning
2. Service start time from user's point of view is very difficult to define. For example, for Ethernet connection, there may be L2 switches in networks and/or at the edge. ARP exchange may take some time, and if STP (Spanning Tree Protocol, here) is working, it will take longer time before user can actually exchange packets. This is true, and the "available time" on the network initiates the ability for the user to start trying to use the connection and things like ARP and STP to setup. A question for me is whether the user should wait till it gets a ack (or notify) from the provider to start trying the connection.
3. For some applications, application might not want a connection in service before/after certain time for security reasons. This is a good point. I wonder if this is something the network can provide or if the user should do this (make itself available) at specific times that match network available time in a predictable way
John
Tomohiro _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg