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.
Jerry - thanks for your detailed comments. What specific generalizations do you suggest that be tackled for NSI 2.0 specification beyond the two parameters suggested?
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.
The key thing to think about here is when it is a modify and when it should be a new request.
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..?)Good question - this needs to be defined. I am assuming hitless implies "no end-user application detectable interruption in service" but is fine with temporary or permanent degradation.
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"?
the user should be able to use modify in whatever way they desire. The primitives should not specify the workflow. What I mean is, that if 3 parameter modification is what the NSI standards group accepts, then they should be able to specify all 3 in one modify request or 1 of the 3, with each subsequent modify request independent of each other. I do not believe that mandating a single parameter modification is the more generalized form.
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.