Subject: [lmap] suppression and disables due to controller lost

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 2015 18:51:54 +0200

Hi,

it seems we have meanwhile two not really consistent mechanisms to
disable tasks. The first one originated from the suppression
discussions. The second one from the desire to ensure that MAs stop
sending measurement traffic if they lost contact to a controller.  In
both cases, we finally disable something but the way this is done is
not fully consistent. Furthermore, we have built in limitations and
a lack of flexibility.

Right now, an instruction has exactly one suppression object and this
object can do immediate suppression or it can do suppression during a
certain time period. Since there is only one suppression object, you
can only suppress during one time period, you can't provision multiple
time periods during which want to suppress.  There are multiple ways
to express which tasks / schedules are affected by suppression (and
this is actually quite complex since tasks also have attributes
whether they belong to the default set of tasks that may be
suppressed). For the case when we loose connectivity to a controller,
we have a separate meachanism to select the tasks and actions that are
affected by this.

What I propose is to revise all this into a single mechanism. The core
of the proposal is to bind 'disablement' to an event and to allow
multiple ma-suppression-objs. The ma-suppression-obj would become
something like this:

  object {
    string        ma-suppression-name;
    ma-event-obj  ma-suppression-event;
   [boolean       ma-suppression-stop-running;]
   [string        ma-suppression-task-names<0..*>;]
   [string        ma-suppression-schedule-names<0..*>;]
 } ma-suppression-obj;

We already have extensible event sources and adding an event that
models 'controller-connectivity-lost' is quite straight-forward.  We
would have to change ma-task-suppress-by-default from a boolean to
something that indicates for which events a task suppresses by default
and the default value for this would be a wildcard 'ALL'.

This change means that we have one mechanism to deal with suppression
and lost contact to a controller. It allows all the flexibility we
have available already to define time based suppression schedules. It
allows to provision multiple suppressions, e.g. for new year evening
and say superbowl time (which you can't do right now - there is only
one suppression object). And it allows future extensions; for example,
you might have suppressions configured that kick in when a device
starts to use 5G connectivity instead of wifi.

There are probably some details that still need to be worked out but
it seems to me that unifying the way how we handle suppression and
reaction to loss of connectivity to a controller is making the model
cleaner and at the same time more extensible and powerful.

/js (sorry for the length)

-- 
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/>