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

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 11 May 2015 19:08:47 +0000

Team,

I was reviewing draft-ietf-lmap-information-model-05 and had a question on the
ma-controller-lost-timeout:  A timer is started after each successful contact with a controller.  When the timer reaches the controller-lost-timeout, all schedules will be disabled.

We changed this from a threshold to a timeout but the data type is still an <int> and there are not units assigned to the timeout (e.g., milliseconds, seconds).

Also the description is vague - When we mean schedules disabled - so we mean administratively or operationally? In other words - does it take an explicit action from the controller to reenable the schedule or simply the next contact. Also is this the schedules that are disabled or scheduled tasks.

I would assume the timeout would be in seconds and we should change the data type to unsignedInt unless of course a negative number has some meaning?

Thanks,
Tim

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 12:07:24 +0200

> I would assume the timeout would be in seconds and we should change the data type to unsignedInt unless of course a negative number has some meaning?

I agree this is under-defined. We generally have only used 'int' and
we did not make a distinction between int and unsigned so I would
leave that alone (or we have to make changes in multiple places).

What about this rewrite:

   ma-controller-lost-timeout:  A timer is started after each successful
                             contact with a controller.  When the timer
                             reaches the controller-lost-timeout
                             (measured in seconds), all schedules will
                             be disabled, i.e., no new schedules will be
                             executed (and hence no new tasks started).
                             The disabled schedules will be reenabled
                             automatically once contact with a
                             controller has been established
                             successfully again.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 12 May 2015 11:58:34 +0000

Juergen,

So then we are saying that schedules (I think you mean scheduled tasks?) are operationally disabled and are reenabled with the controller is contacted.

We that would mean all scheduled tasks that are not related to controller communication - right? Since everything is a scheduled task now?

As to the int vs unsignedInt - I don't necessarily care except that one might ask what a meaning is for negative values unless you use lower threshold constraint of 0. Also you lose have the range of the timeout. What is the size of the int - 32 or 64-bit? My point is that if it is 32bit you its timeout would be limited to like 9+ hours (32767 seconds)

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 5:07 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

> I would assume the timeout would be in seconds and we should change the data type to unsignedInt unless of course a negative number has some meaning?

I agree this is under-defined. We generally have only used 'int' and we did not make a distinction between int and unsigned so I would leave that alone (or we have to make changes in multiple places).

What about this rewrite:

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 12 May 2015 12:33:27 +0000

Sorry - For the range I was thinking 16-bit range not 32-bit. 32-bit should be fine. My mistake.

I will say though that the interface speed may become a problem if you leave it as an int since the unit is bps.

-----Original Message-----
From: Carey, Timothy (Timothy) 
Sent: Tuesday, May 12, 2015 6:59 AM
To: 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: RE: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

Juergen,

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, May 12, 2015 5:07 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

What about this rewrite:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 14:42:09 +0200

> We that would mean all scheduled tasks that are not related to controller communication - right? Since everything is a scheduled task now?

Yes, if in your implementation the communication with the controller
runs as a scheduled task, you better do not disable it. I have added:

  Note that this will not affect the execution of actions that are
  essential to establish contact with the controller or that perform
  critical housekeeping functions
 
> As to the int vs unsignedInt - I don't necessarily care except that one might ask what a meaning is for negative values unless you use lower threshold constraint of 0. Also you lose have the range…

We address these questions in the YANG data model but I was hoping we
can leave out this level of detail in the information model. The YANG
model has this:

      leaf controller-lost-timeout {
        type uint32;
        units "seconds";
        description
	  "...";
      }

Note that 2^32-1 = 4294967295 seconds (which is approx. 136
years). You are calculating with 15 bits.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 14:44:12 +0200

> I will say though that the interface speed may become a problem if you leave it as an int since the unit is bps.

Why? Do you have interfaces that send fractional bits per second? The
IF-MIB has worked for decades with an INTEGER type for interface speeds.

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 12 May 2015 13:04:49 +0000

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?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 7:42 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

> We that would mean all scheduled tasks that are not related to controller communication - right? Since everything is a scheduled task now?

Yes, if in your implementation the communication with the controller runs as a scheduled task, you better do not disable it. I have added:

> As to the int vs unsignedInt - I don't necessarily care except that 
> one might ask what a meaning is for negative values unless you use 
> lower threshold constraint of 0. Also you lose have the range of the 
> timeout. What is the size of the int - 32 or 64-bit? My point is that 
> if it is 32bit you its timeout would be limited to like 9+ hours 
> (32767 seconds)
>

We address these questions in the YANG data model but I was hoping we can leave out this level of detail in the information model. The YANG model has this:

Note that 2^32-1 = 4294967295 seconds (which is approx. 136 years). You are calculating with 15 bits.

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 12 May 2015 13:11:31 +0000

No - but how would you represent a 10 Gig Ethernet interface with a 32-bit signed integer using bps as the unit?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 7:44 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

> I will say though that the interface speed may become a problem if you leave it as an int since the unit is bps.

Why? Do you have interfaces that send fractional bits per second? The IF-MIB has worked for decades with an INTEGER type for interface speeds.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 16:06:48 +0200

On Tue, May 12, 2015 at 01:11:31PM +0000, Carey, Timothy (Timothy) wrote:

> No - but how would you represent a 10 Gig Ethernet interface with a
> 32-bit signed integer using bps as the unit?

The information model does not say anything about int precision. In
the YANG data model, we do not have this object since it is already
covered by the ietf-interfaces YANG model (RFC 7223). This model uses
a 64-bit number:

         leaf speed {
           type yang:gauge64;
           units "bits/second";
           description
               "An estimate of the interface's current bandwidth in bits
                per second.  For interfaces that do not vary in
                bandwidth or for those where no accurate estimation can
                be made, this node should contain the nominal bandwidth.
                For interfaces that have no concept of bandwidth, this
                node is not present.";
           reference
             "RFC 2863: The Interfaces Group MIB -
                        ifSpeed, ifHighSpeed";
         }

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 16:20:06 +0200

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 13 May 2015 12:37:01 +0000

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:[email-masked]] 
Sent: Tuesday, May 12, 2015 9:20 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

/js

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 13 May 2015 15:54:25 -0400

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)"
<[email-masked]> 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).
>
>Add an OperationalStatus attribute with the following values to the
>action object (which was scheduled task): enabled, disabled-schedule,
>disabled-task, 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
>_______________________________________________
>lmap mailing list
>[email-masked]
>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.

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 13 May 2015 20:21:47 +0000

Jason,

Suppression is an administrative action taken through an instruction by the controller. Loss of connectivity (disable schedule or task) is an autonomous operational action taken by the MA. The problem is reporting and recovery - How does a management system know, in order to troubleshoot or remediate the event, if the schedule or task (along with the resulting scheduled actions) have been disabled due to an administrative action like suppression or via an autonomous action like loss of connectivity. 

If we would choose to treat the result of the loss of connectivity as an autonomous suppression event - I am fine with that but we need the MA to be able to report that the task, schedule and resulting scheduled actions are autonomously suppressed (what I called disabled). Likewise we should report that the MA is degraded because it currently is being autonomously or administratively suppressed. The MA will at least need to reevaluate its conditions once one clears to figure out its new status.

Come to think of it - can a system other than the controller have access to the LMAP status information? I guess this all mute if the only system allowed access to the status information is the controller that the MA can't access with Loss of connectivity. In TR-069 this is possible since the controller can be different from the ACS and we can have other systems that can access the data. I'm guessing NETConf/RESTConf allows the same.

BR,
Tim
-----Original Message-----
From: Weil, Jason [mailto:[email-masked]] 
Sent: Wednesday, May 13, 2015 2:54 PM
To: Carey, Timothy (Timothy); Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

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)"
<[email-masked]> 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).
>
>enable/disable the multi-instance objects by conventions - so if for 
>some reason these were administratively disabled - we would set the 
>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
>From: Juergen Schoenwaelder 
>[mailto:[email-masked]]

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 13 May 2015 17:19:45 -0400

Thanks for the reminder Tim. The one-way arrow in the framework doc
confirms it. OK so the Logging objects cover any Failure cases such as an
MA re-booting or loss of connection to the controller and status of
scheduled tasks. So what is being disabled is the Instruction set
communicated by the Controller or some subset of it.

The MA will report its status through logging attributes when it
re-establishes communication with the controller.  But yes I do agree that
the MA seems to need attributes to communicate at least enough information
to the controller about its status in order for the controller to know if
it needs to send a new or updated Instruction set.

Jason

On 5/13/15, 4:21 PM, "Carey, Timothy (Timothy)"
<[email-masked]> wrote:

>Jason,
>
>Suppression is an administrative action taken through an instruction by
>the controller. Loss of connectivity (disable schedule or task) is an
>autonomous operational action taken by the MA. The problem is reporting
>and recovery - How does a management system know, in order to
>troubleshoot or remediate the event, if the schedule or task (along with
>the resulting scheduled actions) have been disabled due to an
>administrative action like suppression or via an autonomous action like
>loss of connectivity.
>
>If we would choose to treat the result of the loss of connectivity as an
>autonomous suppression event - I am fine with that but we need the MA to
>be able to report that the task, schedule and resulting scheduled actions
>are autonomously suppressed (what I called disabled). Likewise we should
>report that the MA is degraded because it currently is being autonomously
>or administratively suppressed. The MA will at least need to reevaluate
>its conditions once one clears to figure out its new status.
>
>Come to think of it - can a system other than the controller have access
>to the LMAP status information?

Won’t the only source of the logging information bet the last controller
configured on the MA?

>I guess this all mute if the only system allowed access to the status
>information is the controller that the MA can't access with Loss of
>connectivity. In TR-069 this is possible since the controller can be
>different from the ACS and we can have other systems that can access the
>data. I'm guessing NETConf/RESTConf allows the same.
>
>BR,
>Tim
>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.