Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

["Weil, Jason" <[e-mail]>]

I am not exactly clear what the difference is between disabled and
suppressed tasks or schedules. It would seem that suppression is a good
fit for the case of loss of connectivity from the way it is described in
the information model when the the ma-controller-lost-timeout counter
expires. Given this following note in 3.3 ("Note that Suppression has no
effect on either Controller Tasks or Controller Schedules.²) it would
clearly not impact future attempts to re-establish connectivity to the
Controller and start testing where it left off. This may also benefit an
operator by offering finer control over which tests should be suppressed
and which shouldn¹t in the event of loss of connectivity to the
controller. For example if may be of benefit for troubleshooting an issue
to have a certain subset of tests continue running and collecting data
even when connectivity to the controller is not available.

Jason

On 5/13/15, 8:37 AM, "Carey, Timothy (Timothy)"
<[e-mail]> wrote:

>Juergen,
>
>If you do not want to disable the scheduled tasks - I would actually say
>the Parent tasks not the schedules are disabled. The reason is because we
>are talking about wanted to disable Tasks that are not related to the
>communication between the MA and Controller or proper functioning of the
>MA.  The MA knows this as part of their TaskCapability reporting (which
>somehow got deleted in draft 05).
>
>As to the reporting of the status I would do the following:
>Add an OperationalStatus attribute with the following values to the
>action object (which was scheduled task): enabled, disabled-schedule,
>disabled-task, disabled-other.
>
>
>
>I would also add an OperationalStatus to:
>1) Schedule object with the following values: enabled,
>disabled-suppressed, disabled-other.
>2) Task object (I guess it could go in Task Status) with the following
>values: enabled, disabled-suppressed, disabled-ma, disabled-other.
>3) Measurement Agent object with the following values: enabled,
>degraded-controller-communication, degraded-other, disabled.
>
>We would always include a disabled-other to allow other conditions. For
>example in TR-069 we have the capability to administratively
>enable/disable the multi-instance objects by conventions - so if for some
>reason these were administratively disabled - we would set the
>OperationalStatus to disabled-other or just disabled for the MA.
>
>These status' would provide a clear operational status of the elements
>that can be disabled or degraded based on what is currently documented in
>the framework and information model. I would suspect as we implement
>protocols there might be other values we want to support - e.g., problems
>with the collector-MA communication...
>
>BR,
>Tim
>-----Original Message-----
>From: Juergen Schoenwaelder [mailto:[e-mail]]
>Sent: Tuesday, May 12, 2015 9:20 AM
>To: Carey, Timothy (Timothy)
>Cc: [e-mail]
>Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller
>timeout
>
>On Tue, May 12, 2015 at 01:04:49PM +0000, Carey, Timothy (Timothy) wrote:
>
>> So does that now mean we need to have a operational status now for a
>> scheduled task? I can see it now as attribute with values like:
>> enabled, disabled, suppressed and errored or possibly a conditions
>> object?
>
>I think there two questions here:
>
>a) If I loose connectivity, do I disable all schedules (and thus
>   implicitely all actions) or do I disable scheduled tasks? My idea
>   was to simply disable all schedules (and as such the schedules have
>   their state changed to disabled).
>
>   The suppression mechanism can suppress both a list of tasks and a
>   list of schedules and it is configurable what is being suppressed.
>
>   One option is that loss of connectivity simply causes suppression
>   to be activated. Another option is that loss of connectivity
>   supresses all tasks that are not essential for communication with a
>   controller and house keeping. Another option is that loss of
>   connectivity suppresses all schedules. We need to select one.
>
>b) Do we expose the internal state that is maintained? Right now, we
>   do not expose any operational state for schedules. But we do expose
>   operational state for tasks. If loss of connectivity means we
>   disable all tasks that are not essential for communication with a
>   controller and house keeping, than exposing that information would
>   be a rather minor change to the information and data model.
>
>   A task state would then be enabled (default), suppressed or
>   disabled. Error information is already covered in the last-failed
>   attributes of a task. (And this is useful in situations where tasks
>   fail occasionally so you can get information about the last failure
>   even though the task is working fine right now).
>
>/js
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   [phone]         <http://www.jacobs-university.de/>
>
>_______________________________________________
>lmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/lmap


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.