Re: [Netconf] New draft: draft-mm-netconf-time-capability-00

[Andy Bierman <[e-mail]>]

On Thu, Jul 18, 2013 at 7:48 AM, Tal Mizrahi <[e-mail]> wrote:
> Hi Andy,
>
>> I like the solution in draft-kwatsen-conditional-enablement-00
>> better than this one because it covers more use-cases and
>> seems more tractable.
>
>
> The concept in our draft is to suggest a general solution, allowing servers
> to coordinate any type of operation, including commit, edit-config, or any
> future operations that may come up. We are also targeting a higher
> resolution than hours.
>

I think your solution has use-cases outside of configuration.

  - synchronized actions across multiple servers (e.g., <reset-foo>)
  - synchronized <get> across multiple servers


> Your points below are well taken.
>
> Thanks,
> Tal.
>
>

Andy

>
> Quoting Andy Bierman <[e-mail]>:
>
>> Hi,
>>
>> There are lots of operational problems with delayed operations.
>> I like the solution in draft-kwatsen-conditional-enablement-00
>> better than this one because it covers more use-cases and
>> seems more tractable.
>>
>> For example:
>>   * in order to stage time-triggered-config,
>>     the user and access control can be checked once at the time
>>     the request is made.
>>   * the normal RPC mechanism is used
>>     (1 request and 1 immediate reply)
>>   * the staged config can be viewed or deleted with standard
>>     protocol operations, using standard access control
>>     [Not clear what filters would need to be added.]
>>   * conditional-enablement easily handles periodic config to
>>     support maintenance windows, URL blocking, etc.
>>   * time-shift applies to config activation, which is much less
>>      complicated than delaying arbitrary protocol operations.
>>
>>
>> Andy
>>
>>
>> On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel
>> <[e-mail]> wrote:
>>>
>>> Hello,
>>> - The idea that scheduled time should be the required completion time for
>>> an
>>> operation is unfortunate. That assumes a device can estimate how long a
>>> complex configuration operation will take. That is already a a risky
>>> assumption. Even worse some operations might depend on external factors
>>> like
>>> traffic load, I/O related delays, interaction with external nodes. It is
>>> impossible to estimate these delays.
>>> - because of the above IMO nanosecond precision for timing is not
>>> realistic.
>>> The YANG time types are good enough. Anyway in many protocols we have
>>> timers
>>> on the scale of seconds, so coordinating configuration changes between
>>> nodes
>>> with milli/nanosecond precision does not look like a sensible goal.
>>>
>>> - there must be a way to check pending scheduled operations. This has
>>> some
>>> interesting access control issues as well. Can I see other peoples
>>> pending
>>> operations? Even if I can read them, what if I do not have rights to a
>>> managed object included in a pending operation? I should not be able to
>>> read
>>> it.
>>> - there must be a way to remove pending scheduled operations.
>>>
>>> - often a configuration session will consist of multiple operations:
>>> (lock,
>>> edit-config, unlock), (lock, discard-changes, edit-config, commit,
>>> unlock).
>>> If I can only schedule single operations does that mean I can not use
>>> lock?
>>> If I want to schedule commit, should I keep the running and the candidate
>>> configurations locked to ensure I commit, what I really want? What if my
>>> session is closed e.g. by a network timeout?
>>>
>>> - if a management user is removed/undefined will his pending operations
>>> also
>>> be removed, or will they stand there and fail at the scheduled execution
>>> time? The latter case will confuse people that do not know the user was
>>> removed.
>>>
>>> - generally timed operations work nicely if no one else configures the
>>> node
>>> while my changes are pending. What is the proposed method to ensure this?
>>>
>>> regards Balazs
>>>
>>> On 2013-07-08 16:27, Andy Bierman wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I do not support a general time-scheduled protocol operation mechanism
>>>> for
>>>> all NETCONF operations.  There is one interesting use-case mentioned:
>>>> synchronized <commit> (or <edit-config> on :writable-running) operations
>>>> across multiple servers.
>>>>
>>>> The proposal doesn't actually work within NETCONF because <rpc> requests
>>>> within a single session are serialized.  This solution seems to send 1
>>>> <rpc-reply>
>>>> when the operation is finally executed.  How does the client know the
>>>> operation
>>>> was scheduled successfully?  IMO, a better solution would be an
>>>> immediate
>>>> <rpc-reply> (scheduled OK) and the execution results sent in a
>>>> <notification>.
>>>>
>>>> How do clients monitor what operations are pending?
>>>>
>>>> What if the NACM rules change while the operation is pending?
>>>> Does access control get checked twice?  Clients should not be able
>>>> to schedule operations they are not permitted to execute.
>>>>
>>>> What if a session is lost or closed before its scheduled operation is
>>>> started?
>>>>
>>>> What if the server reboots while operations are pending?
>>>>
>>>> IMO, YANG date-and-time is better time parameter than 'seconds since
>>>> 1970'.
>>>> It is already supported by NETCONF servers.
>>>>
>>>> How does a client cancel an operation?
>>>> Can client A cancel operations for client B,
>>>> assuming client A is allowed to invoke <kill-session>?
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>> On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi <[e-mail]>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> We have submitted a new draft titled “Time Capability in NETCONF”.
>>>>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00
>>>>>
>>>>> Any comments will be welcome.
>>>>> Thanks,
>>>>> Tal Mizrahi.
>>>>>
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>
>>> --
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>> System Manager
>>> ECN: 831 7320                        Tel: [phone]
>>> Mobile: [phone]              email: [e-mail]
>>>
>
>