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@dante.net <mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg