[Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)

[John MacAuley]

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