[Nsi-wg] Modify concept

Wed Apr 11 09:12:33 EDT 2012

Nice slides John-

I am supportive of a Modify capability... However, as proposed, the 
Modify seems a bit of a specialized hook for a specific issue at SARA.

Is it possible to generalize the primitive to be more broadly applicable 
to reservation parameters in general?   IMO, this would be way more 
useful and a better long term approach...even if the near term users 
only employ some limited aspects of the capability.

Questions:
1. Do we only support the *specific* parameters you identified to be 
"modified"?   Since the proposed Modify references service parameters, 
it will be affected by the Service Definitions, so we should coordinate 
the Modify primitive with the Service Definition parameters defined for 
those services.   We don't want the protocol itself to become 
service/technology specific.  (IMO - we can indicate in the Service 
Definition specification which parameters can be "modified" - this keeps 
the Modify primitive itself general.)
1a.  Why not allow other parameters ... say start time?  Or why not the 
Authorization/security credentials (policy) associated with the 
reservation?  (Indeed, upgrading the auth credentials may be necessary 
to modify the reservation.)  Is there a general principle that we can 
use to limit the scope/complexity just for V2?  (e.g. "the modify does 
not change exisitng NSI Network path"?  not recommending this, just 
asking..?)

2. What do you mean by "hitless" modification?   What if the 
modification of some segment is possible, but it changes the "as built" 
committed performance of the existing connection?  I.e. the path or path 
characteristics of the existing circuit must be modified to support 
it...say latency increases (or decreases), or a different transit 
network is required, or the burst characteristics must be adjusted...  
Does hitless mean No data lost? or an undetectable change to sensed 
performance by the end systems?  Should we *require* a "hitless" 
modification for any modify request?   While nice, is this really 
necessary?  If a Modify request *reduces* capacity...is this "hitless"?

3.   Have you considered how the resulting state machine can detect race 
conditions where a modify request/confirm sequence overlaps with 
autostart or provisioning sequences in the service tree?   For 
instance:  a connection autostarts while being modified, or while 
awaiting a modify commit... or an end time is specified in a modify 
request but that end time passes before the modify commit request is 
received?  Does this generate an error to the modify request itself?  or 
does this simply auto-terminate the connection as result of a modify 
commit?  What termination time is logged- the modified end time or the 
current end time?   I think you noted that a ModifyCommitReject can 
cause some confusion - this needs to be worked out and be predictable.

4. What additional states are shown to a Query primitive?   Any states 
that may potentially exist for seconds or longer should IMO be explicit 
in a Query status.   But since the Modified resources are not committed 
yet, should it be seen as the authoritative state of the existing 
reservation?  I.e. should we provide both the current and proposed 
parameters as part of a Query status for a "Modifying" state?

5.  Assuming a simple modify is possible...how is it provisioned?   Is 
an explicit provision request necessary?  Or is the provisioning 
transparently included as part of the modifyCommitRequest when the 
existing reservation is already in service?  (see above also regarding 
auto/manual start time races)

6. Is it possible (or preferable) to modify only one parameter at a time 
- getting commitments on each parameter *THEN* committing all 
modifications at once?   I think allowing this batch mode commit of 
multiple changes provides a more powerful and deterministic process from 
the RA perspective.   Probably simplifies the PA handling as well.  
Maybe single parameter modification should be required?

I understand the practicality and basic use case for wanting to modify 
the end time or capacity of a connection, and I am supportive.  My 
comments are not meant to stymie the Modify capability - just that 
despite the seeming simplicity of the basic use case, the implications 
to the protocol are broader and in the global distributed context should 
be thoroughly considered.

Thanks!
Jerry

On 4/10/12 11:29 PM, John MacAuley wrote:
> My slides. for discussion.
>
>
>
>
> On 2012-04-10, at 1:24 PM, Guy Roberts wrote:
>
>> Hi all,
>> The following is dial-in information for Wednesday's NSI call, time:  
>> 7:00 PDT  10:00 EDT, 15:00 BST,  16:00 CEST,  23:00 JST
>> 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. 
>> International participants dial: Toll Number: 303-248-0285  Or 
>> International Toll-Free Number:http://www.readytalk.com/intl3. Enter 
>> 7-digit access code  8937606, followed by "#"
>> Agenda:
>> ·Chin to present state machine proposal
>> ·John to present modify request
>> ·NSI v2.0 action points
>> ·Contributions to NSI v2.0 text for protocol spec.
>> Guy
>> _____________________________________________________________________
>>       **       Guy Roberts, PhD     Network Engineering & Planning
>>     *    *                          Tel:    +44 (0)1223 371300
>>    *      *    City House           Direct: +44 (0)1223 371316
>>    *           126-130 Hills Road   Fax:    +44 (0)1223 371371
>>   *            Cambridge
>>   *            CB2 1PQ              E-mail:guy.roberts at dante.net 
>> <mailto:guy.roberts at dante.org.uk>
>>   D A N T E    United Kingdom       WWW: http://www.dante.net
>> _____________________________________________________________________
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120411/a177dd84/attachment.html>