Subject: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12

From: Fredrik Kers <[email-masked]>
Date: Wed, 3 May 2017 11:50:34 +0200

Hi!
I'm looking at aligning a project with the LMAP data model (
https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and YANG
model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have some
questions and comments.

First, some comments on the information model.

1)
Normally a task in computer terms means a process or a "unit of execution"
as it is described on Wikipedia (
https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it means a
program/executable, or a function in more abstract terms. I was confused
for quite some time until I understood that a task in LMAP actually meant.
I would suggest using a more common terminology, but I understand that it
might be a bit too late to change the name of such a central concept.

2)
The information model describes the concept of Measurement Task, Reporting
Task, Control Task, etc. (
https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9),
and that Control Tasks can be used to configure the Schedules, Tasks etc.
on the MA. However it's not described what mechanism a Control Task uses to
configure the MA. The normal task input/output model only describes how
data flows between instances of tasks and schedules, but does not give any
way to communicate with the MA itself. How is this supposed to work?

3)
Related to this the Control Tasks, the information model in one place
states that "in terms of the Information Model, all Tasks have the same
structure", but in another place states that "Suppression has no effect on
either Controller Tasks or Controller Schedules".

So the question is, is a Control Task (and Schedule) handled differently by
the MA compared to other types of Tasks (and Schedules)?

And now some comments on the YANG model.

4)
In the YANG model, a task can be listed in three places;
/lmap/capabilities/tasks/task, /lmap/tasks/task and
/lmap/schedules/schedule/action/task. Let's see if I understand this
correctly...

* /lmap/capabilities/tasks/task lists the available tasks that the MA can
execute, which is not configurable from a controller but is configured
locally at the MA, for example in a config file or even at compile time.
* /lmap/tasks/task is the tasks that has been configured with some default
options and are available to be executed.
* /lmap/schedules/schedule/action/task pints at what task to start when an
action is fired, and provides additional options to it.

To me it's not clear why the middle step (/lmap/tasks/task) is required
since all the properties at that level (options and tags) can also be
configured in the action, except the functions list which seems weird to be
able to configure anyways (see next comment).

5)
In /lmap/tasks/task you can configure a list of functions for a task, which
might or might not be the same functions listed in
/lmap/capabilities/tasks/task. The purpose of this functions lists is not
crystal clear to me, but it seems wrong that you can configure functions
that are not included in the capabilities.

6)
To keep the structure of the YANG model consistent all lists should be
wrapped in a container, e.g. move /lmap/schedules/schedule/action to
/lmap/schedules/schedule/actions/action. Other lists that would be affected
are "function", "option", "result", "conflict", "table" and "row". Is there
a reason for the different structure of some lists?

Regards,
Fredrik

-- 

*Fredrik Kers* | CTO | linkedin.com/company/netrounds
<https://www.linkedin.com/company/netrounds>

<[email-masked]>

*Netrounds* | Storgatan 9 | 972 38 Luleå | Sweden | www.netrounds.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 May 2017 12:24:06 +0200

> model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have some

Note that the two documents have just been moved to the RFC editor
queue (after ~3 years of development within the WG). While comments
and questions are welcome, there likely won't be any technical changes
soon.
 
> might be a bit too late to change the name of such a central concept.

I do not think task necessarily means executable in LMAP. The term
task is used in order to stay away to some extend from implementation
specifics.

> way to communicate with the MA itself. How is this supposed to work?

It is (a) not required to implement things via control tasks and (b)
how control tasks do their work is and implementation detail.

> the MA compared to other types of Tasks (and Schedules)?

In this particular aspect, they may be handled differently. If you,
for example, implement an LMAP agent running behind a NAT, then there
needs to be something that calls home to the controller. This
something might be implemented as a control task or it might be
implemented as part of the LMAP agent itself. If this would be
implemented as a control task, then attempts to suppress call home
would likely be rejected (since this would essentially mean the LMAP
agent becomes disconnected and hence useless). There may be additional
control tasks, e.g., a control task that clears buffered data in case
an LMAP agent is running low on memory. Again, an implementation may
not support suppression of such a house keeping control task.
 
> action is fired, and provides additional options to it.

Correct.
 
> able to configure anyways (see next comment).

The 'middle step' is an optimization for situations when you have many
actions that want to share common task parameters.

> that are not included in the capabilities.

I assume an implementation would reject an attempt to configure a
function that does not apply. What is your proposal? To have this
spelled out more clearly in the YANG model? To have some sort of a
must constraint to express this? (I would have to think about how to
write this.)

> a reason for the different structure of some lists?

YANG generally does not have nodes representing lists and some people
believe such additional containers just add additional noise to the
data encodings with little value.

The reason why we have the top-level containers is because people
found it useful to have some top-level structure (similar to the way
we have structured the information model into several aspects); so
these top-levels provide structure, they do not represent lists. For
example, /lmap/agent is just a container for scalars and
/lmap/capabilities is a container with scalars and a list.

/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: Fredrik Kers <[email-masked]>
Date: Wed, 3 May 2017 15:56:43 +0200

> and questions are welcome, there likely won't be any technical changes

I just saw that. Congratulations! I hope I don't ruin your day with all
these questions :)

> task is used in order to stay away to some extend from implementation

No, the information model does not mention how a Task should be
implemented, so it could be in any form. However, in the YANG model the
task is actually assumed to be an executable because of the "program" leaf
with the description "The (local) program to invoke in order to execute the
task."

Anyway, my comment was not about whether a Task is realized as an
executable or not but that the term "task" in LMAP doesn't mean what you
would expect. But I understand that it's too late to change this.

> how control tasks do their work is and implementation detail.

OK. Since the concept of Control Tasks is covered in the RFC, it would be
good to clarify that the communication interface between the Control Task
and the MA is outside of the scope of the RFC.

> not support suppression of such a house keeping control task.

I understand the reason one might want to prevent suppression of certain
Tasks, but stating that some Tasks should be treated differently without
additional information on how to identify those Tasks leaves the reader
wondering. If you think that it's up to the implementation to decide how to
identify the task, I think than it should be mentioned.

> actions that want to share common task parameters.

OK.

> must constraint to express this? (I would have to think about how to

Of course you could solve it at the implementation level, but as a user of
an interface based on the YANG model I would wonder what to configure in
/lmap/tasks/task/function and why.

The /lmap/tasks/task/program leaf, which will have the same issue, has a
"nacm:default-deny-write" statement, that I assume is to prevent
configuration of it. Could something similar be done?

An alternative is to remove the "program" and "function"
(registry-grouping) completely from the /lmap/tasks/task since they already
exist in the task in the capabilities which is referenced by name.

> /lmap/capabilities is a container with scalars and a list.

OK

Regards,
Fredrik

-- 
*Fredrik Kers* | CTO
*Netrounds* | Storgatan 7 | 972 38 Luleå | Sweden | www.netrounds.com

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 May 2017 16:47:32 +0200

> I just saw that. Congratulations! I hope I don't ruin your day with all

People reading the documents are always welcome!
 
> would expect. But I understand that it's too late to change this.

The question always is: Is there anything unclear impacting
implementations and interoperability?
 
> and the MA is outside of the scope of the RFC.

I would not disagree with such a statement but I do not find it
essential and well it is too late for the first version of the model.

> identify the task, I think than it should be mentioned.

A controller does not configure which tasks are control tasks. The MA
implementation knows them.

> /lmap/tasks/task/function and why.

The function ties into a registry. Until we have such a registry, this
remains somewhat vague.
 
> configuration of it. Could something similar be done?

The registry proponents would never configure a program; they would
identify a function via a registy entry and the system would have to
resolve how that maps to a program. Note that it is not mandatory to
have a program configured.

> exist in the task in the capabilities which is referenced by name.

An entry in the task list says which functions a task can provide. In
the configured task, you might subset that.

/js

---

From: Fredrik Kers <[email-masked]>
Date: Thu, 4 May 2017 10:32:39 +0200

On Wed, May 3, 2017 at 4:47 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it
> means
> > > a

No, the RFC is clear.

> the configured task, you might subset that.

So the purpose of the functions in /lmap/tasks/task is to configure what
functions (metrics) a task should produce? That makes sense. Would also
make sense if those functions could be configured at the action level, just
like like the options.

Another question. What is the purpose of
/schedules/schedule/action/parameters? Is it only to provide configuration
to the "task instance" that is not feasible to describe as an option?

Regards,
Fredrik

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 May 2017 14:52:14 +0200

> make sense if those functions could be configured at the action level, just

Maybe, maybe not. This may depend on what exactly registries provide.
Anyway, adding stuff to a YANG model is easy should the need arise.

> to the "task instance" that is not feasible to describe as an option?

Yes, kind of. Some people suggested such an extension mechanism would
be needed but we lack experience with it. So the parameters are more
or less a placeholder. Perhaps there should also have been on
/tasks/task/parameters. (But then it is even less clear how parameters
associated to a task and to an action are merged.)

/js

---

From: Fredrik Kers <[email-masked]>
Date: Thu, 4 May 2017 15:09:38 +0200

OK. Thank you for taking the time to answer my questions and comments.

Regards,
Fredrik