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

[Guy Roberts]

Jeroen,

This is a good point and I like the idea of dispensing with the guard time.  Judging by the discussions it is causing more confusion that it is solving. 

Since NSI is defining the protocol only, the use of a guard time could be implemented in the NSA on a local policy basis - in this case we can ignore it as a protocol issue.

Some reasons why it was proposed:

1. From my understanding of the discussion, a guard time was proposed to prevent race conditions between low and high priority traffic.  This is not necessary for v 1.0 since we only support advance reservation and near-immediate reservation, where the start time can be close to now.

2. Another justification for the guard time is to improve security.  A guard time would allow all of the segments to be provisioned at the same time, preventing misconnection. My feeling here is that this is futile as we cannot guarantee the time taken to perform provisioning - this can be several minutes on the Alcatel equipment and a few seconds on other equipment.

So on this basis, I suggest we leave any discussion of guard bands out of the architecture document, except as a passing reference to usage based on local NSA policy.  i.e the Requester NSA can set the start time to no sooner than now + guard time, this can then be validated at receipt by the Provider NSA.

Guy

-----Original Message-----
From: Jeroen van der Ham [mailto:vdham at uva.nl] 
Sent: 08 April 2010 08:28
To: Tomohiro Kudoh
Cc: nsi-wg at ogf.org
Subject: Re: [Nsi-wg] Immediate/Advance reservation (Re: NSI conf call minutes)

On 07/04/2010 15:02, Tomohiro Kudoh wrote:
> If a requester wants resources to be provisioned as soon as possible, it
> can set the start time parameter in a advance request to:
> (current time + guard time + a certain time required for message
> delivery).
> 
> In this way, immediate provisioning can be requested by an advance
> reservation request.

The procedure above seems overly complicated and if I really am pressed
for time, and I miscalculate the (current time + guard time + delivery
time) by a few seconds. Denying the request means that I have to do it
all over again, making me even more pressed for time.

Why not keep things simple and always interpret a start time in the past
as "now" ? (provided the end-time is in the future too)
Would there be any problems associated with that?

Jeroen.
_______________________________________________
nsi-wg mailing list
nsi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg