[Nsi-wg] new/modified NSI requirements

Fri Apr 9 10:55:34 CDT 2010

Joan,

My feeling is that since the guard time will vary considerably depending on the service level and speed of the technology, and number of networks and other factors not yet considered, we would be best to allow implementers to choose any guard time that they wish.

Guy

-----Original Message-----
From: "Joan A. García-Espín" [mailto:joan.antoni.garcia at i2cat.net] 
Sent: 08 April 2010 12:05
To: John Vollbrecht
Cc: Guy Roberts; nsi-wg at ogf.org
Subject: Re: [Nsi-wg] new/modified NSI requirements

Hi all,

I agree with having the new requirements in general.

However, I've some concerns on whether we have to specify how the  
guard-time should be calculated. Some examples:
   - Chain deployment of the service plane: guard time for the  
provisioning should be at least the sum of local guard times. Could be  
computed at the reservation phase.
   - Tree deployment of the svc. plane: guard time should be at least  
the sum of NRM provisioning time + instantiation delay in the  
signaling (depends on the number of levels in the hierarchy in some  
cases).

Regards,
--
Joan A. García-Espín
CTX, i2CAT Foundation

El 07/04/2010, a las 21:09, John Vollbrecht escribió:

> Some comments below --
> On Apr 7, 2010, at 1:14 PM, Guy Roberts wrote:
>
>> Hello all,
>>
>> Following on from today's NSI discussions, the following new NSI  
>> requirements are proposed.  Could you please take a look and let me  
>> know if you are happy to accept these as agreed requirements?
>>
>> Guy
>>
>> ----------------
>>
>> Not UNI like:
>> R1.1.10 The NSI architecture must not force services requests to  
>> originate from any specific NSA. (i.e. this is different to MPLS  
>> UNI which only allows connections requests that terminate on the  
>> node associated with the UNI)
>>
>> Provisioning complete notification:
>> D2.1.12a The Notify function must support a notification to  
>> indicate that provisioning has been completed. (this is to allow  
>> local timer based initiation of provisioning to be notified to the  
>> Requester NSA)
> I don' t think the reason is just to allow local timer initiation.   
> I think the idea is to make notiification of provisioning completion  
> orthogonal to initiating provisioning.
>
>>
>> Provisioning initiation methods:
>> D2.2.6 Connection provisioning is initiated in two possible ways:   
>> 1: When a Requestor NSA signals to the Provider NSA. 2: Once a  
>> scheduled resource reaches the start time.  (I guess this implies  
>> the need for some way of indicating which type of initiation of  
>> provisioning should be used)
>>
>> Advanced reservation and near-immediate reservation method:
>> D2.2.13 A requester NSA will create advanced reservation type  
>> Connection requests by setting a start time and end time.
>>
>> D2.2.14 A requester NSA will be able to request near-immediate  
>> Connections by setting a start time soon after the current time,  
>> subject to guard time limits.
>> Note that the guard time concept is added here to allow validation  
>> of start times that are near-to-present-time.  This makes start  
>> times more deterministic and reduces race conditions and other  
>> problems during connection creation  -Guy Roberts 4/7/10 4:56 PM
>>
>> D2.2.15 A Provider NSA when scheduling a Connection request will  
>> perform a guard time test on the start time as follows: If the  
>> start time is less than current time + guard time then the  
>> connection request will be rejected.
> Is guardtime only a provisioning issue?  I thought there was  
> discussion that a reservation might have a similar problem because  
> of delays in reserving over a sequence of NSAs.  I am not sure this  
> is a real issue because when I get a response the connection is  
> reserved, and the only question is whether it is too late to be  
> useful.
>>
>> D2.2.16 The guard time will be agreed based on local policy and  
>> managed by the NSA.
>
> I have a question about guard time in general.  Does one start  
> provisioning at start-time minus guard time to guarantee that the  
> connection is established at the start time, or does one start  
> provisioning at start time and it is completed at start-time plus  
> guard time?  I had always assumed the latter, but this seems to  
> assume the former.
>
> Seems to me issue with this for scheduling is that if one has a  
> calendar and schedules a connection from t1 to t2 and another from  
> t2 to t3, to be precise one has to schedule t1 to (t2-guardtime)and   
> t2 to (t3-guardtime), assuming that calls start down when  
> provisioning starts.
>
> I think this implies that guardtime needs to be included in response  
> to a request for connection.
>
>
>>
>>
>> ------------------------------------------------------------------------------------------------------------------
>> Guy  Roberts,  Ph.D
>>
>> Network Engineering & Planning
>> DANTE - www.dante.net
>> Tel: +44 (0)1223 371 316
>> City House, 126-130 Hills Road
>> Cambridge, CB2 1PQ, UK
>> ------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg