Subject: [lmap] default value for the controller-timeout

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Feb 2016 13:08:54 +0100

Hi,

should the ma-config-controller-timeout (information model) have a
default value? The YANG model has this as an optional object. What
does it mean if lmap/agent/controller-timeout is not present? I think
I would prefer to have a default so that there is always a timeout.

What about a week (= 604800 seconds) as a default?

/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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 3 Feb 2016 08:57:56 -0500

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, February 03, 2016 7:09 AM
> To: [email-masked]
> Subject: [lmap] default value for the controller-timeout
> 
> Hi,
> 

[ACM] Good to supply a default, 1 week ok, not sure if timeout should be 
optional in the YANG model (even if the timeout object is omitted, a
timeout is enforced at the MA? 
How to instruct the MA not to use a timeout?)

Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Feb 2016 17:58:39 +0100

> How to instruct the MA not to use a timeout?)

While coding this up I stumbled over this. Right now, the text is not
very precise. I could go with setting the timeout to zero means no
timeout and the default is one week.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 4 Feb 2016 08:53:18 -0500

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Wednesday, February 03, 2016 11:59 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]
> Subject: Re: [lmap] default value for the controller-timeout
> 

[ACM] 
As an alternate, we could view the default simply as guidance.
If you include the ma-config-controller-timeout object, then
you must supply a value, and if you need guidance about this you 
specify the default value.

OTOH, if you don't want a timeout, you don't include the
ma-config-controller-timeout object at all.

AND, I don't feel strongly about this...
Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 15:15:20 +0100

> AND, I don't feel strongly about this...

Yes, but this means the default is actually to have no timeout since
the ma-config-controller-timeout is optional to have. It's a policy
question whether we want to have a timeout configured by default and
it takes effort to run without one or whether we are fine with no
timeout by default and we require effort to create one.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 4 Feb 2016 09:42:27 -0500

> Sent: Thursday, February 04, 2016 9:15 AM
> > > > [ACM] Good to supply a default, 1 week ok, not sure if timeout
> should
> > > be

[ACM] Right. The default condition of the MA is having no instructions
and having nothing scheduled, etc.  When we ask the MA to perform
measurements that send traffic, reports, etc., then we may need a timeout,
and all these functions require effort to create them.

Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 16:40:50 +0100

> and all these functions require effort to create them.

We are talking about loosing contact to the controller, which should
trigger an appropriate event. Relying on someone to configure this in
a meaningful way (= having no default) means we will see boxes that
simply will never react to lost contact to a controller. Yes, it is a
policy issue but I am somewhat concerned about boxes going crazy and
never detecting this and properly shutting down.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 4 Feb 2016 11:22:25 -0500

> Sent: Thursday, February 04, 2016 10:41 AM
> > > > > > > should the ma-config-controller-timeout (information model)
> have
> > > a
> > > > > > > default value? The YANG model has this as an optional
> object.
> > > What
> > > > > > > does it mean if lmap/agent/controller-timeout is not
> present? I
> > > > > think
> > > > > > optional in the YANG model (even if the timeout object is
> omitted,
> > > a
> > > > > While coding this up I stumbled over this. Right now, the text
> is
> > > not

[ACM] My concern as we started this discussion is about having 
an "embedded behavior" = default timeout in the MA.  
I'm using this term "embedded behavior" for lack of a better one,
since the MA would apparently need to be instantiated with this timeout.
The framework mentions the timeout configuration (end of 5.3.1):
http://tools.ietf.org/html/rfc7594#section-5.3.1

   The Controller may want an MA to run the same Measurement Task
   indefinitely (for example, "run the 'upload speed' Measurement Task
   once an hour until further notice").  To prevent the MA continuously
   generating traffic after a Controller has permanently failed (or
   communications with the Controller have failed), the MA can be
   configured with a time limit; if the MA doesn't hear from the
   Controller for this length of time, then it stops operating
   Measurement Tasks.

but doesn't mention an embedded default for this time limit.

After having read 
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
yesterday (which I know you've read, too)
the "embedded behavior" = default timeout in the MA
isn't part of "Applied Configuration" or "Derived State",
so it may not be possible to retrieve the timeout setting.

What is the down-side to making the 
ma-config-controller-timeout object Mandatory? 
Having to repeat the object with every Instruction?
But this would make the timeout part of the retrievable configuration,
and that's what I would like to see, if it's not a burden elsewhere.

Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Feb 2016 17:36:26 +0100

> and that's what I would like to see, if it's not a burden elsewhere.

Defaults have nothing to do with the opstate discussions. YANG has a
way to define defaults and NETCONF has mechanisms to requests whether
default values are reported or not.

The basic question remains but you are right that we could mandate
that a default is explicitly configured. The question is whether this
simplifies things or leads to better settings than a reasonable
default value. There are many timers around us that we never bother
about because they do have workable defaults. Anyway, the options are:

(a) We define a default (strawman 1 week) and unless someone specifies
    something different explicitly, this is what an implementation
    will use.

(b) We make the configuration of a timeout optional, which means the
    default is no timeout. 

(c) We make the configuration of a timeout value mandatory and we do
    not provide a default.

My preference is (a), I am concerned about (b) causing noise, and I
feel (c) just adds more configuration hassle and people may end up
picking (or more likely copying) their own arbitrary defaults.

So my preference is (a) then (c) and finally (b).

/js