[Nsi-wg] Modify concept
John MacAuley
john.macauley at surfnet.nl
Wed Apr 11 17:56:38 EDT 2012
I think we covered these on the call, but to make sure those who were not there are aware. Thank you for the detailed questions.
1. I only put in endTime and bandwidth as examples of the SURFnet requirements and agree we need a generic mechanism similar to how we specify parameters in the reservation request. However, I want to make sure we do not support a modify operation that changes endpoints, or requires rerouting of the service. This would make the operation extremely complicated as it can change the NSA involved in the path. This should be handled by an entirely new reservation.
2. Hitless does need clarification. I think we should consider Inder's comment as the true definition. The point of the modify is to meet the new service requirements as seamlessly as possible, and with no visible impact to the end user. If we say a service must go down for 2 minutes to modify the path then why not just use a terminate and new reserve?
3. I have considered the overlap issue, but even if the timing is bad, I think we should be okay since each NSA will handle the modify in the context of their current state machine. The only one that concerns me is if a modify for a later start time comes down after the schedule has already started. Do we then release the resources and modify the schedule? A modify of endTime could result in the early termination of a schedule, but this is the desired behaviour.
4. When I thought this through I didn't think we needed any additional states displayed in the query. The query would return the current view of the reservation, and not any pending resources. This does mean that as the modifyCommit is propagating down the tree a recursive query could show inconsistent views of the same reservation, but it should only be transient in the success case. Of course, for error recovery we do what to see the inconsistent reservation legs. I am not sure if a "Modifying" state is of any use since the commit action itself should be instantaneous.
6. I think the supporting a set of reservation attributes to modify is the correct way to go, as the user can always send them down one at a time. Not sure if having a transaction based modify where i can queue up a bunch of individual changes to apply is worth the complexity at this time.
John.
On 2012-04-11, at 9:57 AM, Inder Monga wrote:
>
> Jerry and John,
> observations inline!
>
> Thanks for bring the discussion to the email list!
>
> inder
>
> Jerry Sobieski wrote:
>>
>> 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.
> 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?
>>
>> 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?
> The key thing to think about here is when it is a modify and when it should be a new request.
>> 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?
> 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.
>> 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?
> 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.
>>
>>
>> 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/intl 3. 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
>>>> D A N T E United Kingdom WWW: http://www.dante.net
>>>> _____________________________________________________________________
>>>>
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> 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
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
> --
> Inder Monga
> 510-486-6531
> http://www.es.net
> Follow us on Twitter: ESnetUpdates/Twitter
> Visit our blog: ESnetUpdates Blog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120411/58ed6b02/attachment-0001.html>
More information about the nsi-wg
mailing list