[Nsi-wg] Modify concept
Inder Monga
imonga at es.net
Wed Apr 11 09:57:34 EDT 2012
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/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
> _______________________________________________
> 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 <http://bit.ly/bisCAd>
Visit our blog: ESnetUpdates Blog
<http://bit.ly/9lSTO3><http://bit.ly/d2Olql>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120411/7381feb8/attachment-0001.html>
More information about the nsi-wg
mailing list