[lmap] review: draft-ietf-lmap-information-model-03

["Bajpai, Vaibhav" <[e-mail]>]

LMAP,

> On 23 Jan 2015, at 17:33, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> we have updated the YANG data model in order to align it with the
> latest update of the information model. A couple of questions came up
> during the process, which we will post in a separate message. We also
> added an instance document in XML and the same rendered in JSON. Both
> have been validated against the YANG data model using the pyang
> toolchain.

Below is our review of the information model -03:



Capability and Status Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  >      datetime            ma-last-task;
  >      datetime            ma-last-report;
  >      datetime            ma-last-instruction;
  >      datetime            ma-last-configuration;

The semantics of ma-last-* is unclear. 'Last' means last executed or last
succeessfuly completed? Additionally, how does the LMAP implementation know
whether task X is a measurement task, a reporting task, et al.? If not how
would the implementation fill in the datetime fields.

In the YANG data model [1], we have added 'last-execution' (to all known
tasks) and it records the last invocation of the task (but it should really be
a pair 'last-invocation' and 'last-completion'. But the point here is to
report this for each tasks instead of a grouping of tasks by function.



Condition Codes
~~~~~~~~~~~~~~~

  >    [ma-condition-obj    ma-conditions<0..*>;]

  >    object {
  >      string                ma-condition-code;
  >      string                ma-condition-text;
  >    } ma-condition-obj

This is a list of condition codes.  Each condition code in this list needs to
associate to a task.  How do we make the association?

In the YANG data model [1], we have added 'last-failed-execution' (to all
known tasks) and it records the last failed execution together with a status
code and a status message. This makes sure that a subsequent successful
execution is not removing the error code and message. We also believe that (at
least in the data model) we need to define a set of suitable status codes in
order to be interoperable.



Reporting
~~~~~~~~~

  >  object {
  >      string              ma-report-task-name;
  >     [uri                 ma-report-task-registry-entry;]
  >     [name-value-pair     ma-report-scheduled-task-options<0..*>];
  >     [string              ma-report-task-cycle-id;]
  >      string              ma-report-task-column-labels<0..*>;
  >      ma-result-row-obj   ma-report-task-rows<0..*>;
  >  } ma-report-task-obj;

How about introducing a configuration version number?  This will remove remove
the need to send entire task configuration as part of the report, since only
config version numbers would need to be matched.



Schedules
~~~~~~~~~

  >  object {
  >     string                         ma-schedule-task-name;
  >    [name-value-pair                ma-schedule-task-options<0..*>];
  >    [ma-sched-downstream-tasks-obj  ma-schedule-destination-tasks<0..*>;]
  >  } ma-sched-task-obj;


  a) Task options are now part of both schedule and task configurations
  (Thanks!). However, it's unclear whether schedule options are prepended or
  appended to the task options. We think schedule options should be appended to
  the task options because schedules are more frequently updated than task
  configurations.

  In the YANG data model [1], we have specified that options are appended.


  b) Task and downstream relationship is not clear. Is it:

    $ a | b (a streaming data to b)     (or)
    $ a ; b (b running after a is completed)

    In case of the latter, does the destination task wait for the upstream
    task to be completed? For example, with an upstream task sending results
    to a reporter, is the reporter blocking until there is data from the
    upstream task? The behavior is not currently defined in the document.

    The behavior of ^ relationship is unclear, when for example a periodic
    scheduled task forwards data to an immediate schedule report (or an
    immediate forwards to another immediate). In such cases, what would
    immediate mean if a task consumes data from another task?



  c) Let's not introduce a new 'name-value-pair' type. Instead it would be
  better to refer to an options object which has a name and a value elements.


  >   object {
  >      [string    ma-schedule-task-destination-schedule-name];
  >      [string    ma-schedule-task-destination-task-configuration-name];
  >      [int       ma-schedule-task-output-selection<0..*>;]  // default: all
  >   } ma-sched-destination-tasks-obj;

The notion of an upstream task being able to direct outputs with different
file descriptions to different destination tasks (which themselves are
referred to by a schedule name) was challenging to grasp from the ^ snippet.
Perhaps more description on this would be nice.

  >   Measurement Task
  >     Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task"
  >     Output 2 ----/

In the ^ example, how do we decide the the order of directing results into the
hourly reporting task?




References
~~~~~~~~~~

  >  [I-D.ietf-lmap-framework]
  >             Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
  >             Aitken, P., and A. Akhter, "A framework for large-scale
  >             measurement platforms (LMAP)", draft-ietf-lmap-
  >             framework-03 (work in progress), January 2014.

Needs an update.

  >  [I-D.bagnulo-ippm-new-registry]
  >             Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
  >             A. Morton, "A registry for commonly used metrics", draft-
  >             bagnulo-ippm-new-registry-01 (work in progress), July
  >             2013.

Needs an update.




JSON Data Model Example
~~~~~~~~~~~~~~~~~~~~~~~

As part of the YANG data model definition [1], we now provide both a XML and
a JSON encoded example for reference. The example is validated against the
YANG data model definition. Can we remove the JSON example from this document?

[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02



Editorial Comments:
~~~~~~~~~~~~~~~~~~~

A lot of new spelling errors were spotted when examining the diff.


[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02


Best, Vaibhav

=====================================================
Vaibhav Bajpai

Research I, Room 91
Computer Networks and Distributed Systems (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com
=====================================================