This seems to be a very passionate topic for discussion and reminds me of discussions back in my equipment vendor days. Whenever we would be working through provisioning issues we would always ask the question "Is there any chance we could cross-connect the Playboy channel to the Disney subscribers?" This was a real fear for some of our customers, but more recently it had turned into an issue of data security. With the type of end-user controlled dynamic provisioning we are discussing here there will be a window of opportunity for improperly connecting services for a short period of time. Within a a single NRM area of control it could make sure all resources have been released from use by a previous schedule before re-using them in a new schedule that is being instantiated, however, this is no longer true when a circuit is spanning multiple NRM domains. There is now a window of chance where a slow to tear-down service in one domain could be joined to a fast to create new service in another domain. Something to consider. This e-mail chain had been dealing with guard time for start-up, but we also need to be careful about connection tear-down as well. With DRAC we implemented a guard-time mechanism to help scheduling account for technologies that had longer setup and tear-down times. When computing reservations we would then work guards into both ends of the schedules to make sure we would have sufficient time to tear down a service before the resources could be reused in another reservation. John. On 10-04-14 8:23 AM, Joe Mambretti wrote:
I agree with your comments. These issues are design decisions. The protocol can be designed only as a request for resources, completely agnostic to any type of timing, including a time-to-live flag for the signal. Or it can be designed to include some type of "promised" service. Note that when you make a call, you have an high degree of expectation of completing the connection. However, sometimes, you receive a busy signal, a message indicating that "all circuits are busy" or the line is dropped. There are no absolutes in communications. One consideration with this protocol is that in general in the near term (next 3 years) these requests will be made for large scale resources that will be required for extended periods (hours, days, perhaps week). In these types of cases an initial delay in set up is generally expected and tolerated.
At 06:58 AM 4/14/2010, Jerry Sobieski wrote:
Well said Joe. Very good points, particularly about the similarities of advanced vs immediate. I agree completely.
But we do run into some real protocol issues since previous protocols did not deal with a time constraints. In order to support the time constraint we need to understand what the "promise" is to the user within the NSI: If the promise is to provide a connection with certain characteristics (one being start time to end time) we need to anticipate the timing issues associated with resource reservation and provisioning as we change states.
There are easy ways to punt the issue: For instance, we can state that provisioning begins at the start time. This is simple from the protocol and scheduling issues, but it means the user has no guarrantee of when the connection will actually be usable!... So I don't think in all fairness this is an appropriate way to handle it...we need to take Jeff's comments to heart: What does the user expect from these service interfaces? IMO, the start time should be the "In-Service start time", and if we need a "Provisioning start time" parameter someplace, then we figure out how to bound it authoritatively and do that.
Jerry
Joe Mambretti wrote:
I agree with these comments.
At 08:42 AM 4/13/2010, Radek Krzywania wrote:
Hi, Indeed, I forgot about NTP. But still my opinion is that we are unable to assure time precision at the level of seconds.
Yes, seconds in a metro area.
Minutes are far more probable.
However, certainly in the near term (e.g., the next two years). minutes are to be expected. Furthermore, in part because of this timing issue, as I have noted previously, the distinction between "Immediate" and "Advanced" is artificial. *All* requests are for future resources. There is no reason to treat a request for resources required "as soon as possible" from other requests. The only difference is timing, and all the timing is in the future. These issues of timing belong to an external scheduler - not to the protocol, except possibly in terms of a time-to-live flag for the signal.
Regarding race conditions, it's not the role of the protocol to prevent it.
I very much agree with this. There is a tendency in these types of initiatives to expand the scope of the standard. These tendencies should be resisted vigorously.