[lmap] Feedback on draft-ietf-lmap-information-model : part 2

[Benoit Claise <[e-mail]>]

Dear all,

Here is part 2.

Again, if some points were already discussed, don't hesitate to let me know.
See in-line.

Regards, Benoit


.3.3.  Configuration Information
> During registration or at any later point at which the MA contacts
>    the Controller (or vice-versa), the choice of Controller, details for
>    the timing of communication with the Controller or parameters for the
>    communication Task(s) can be changed (as captured by the Channels,
>    Schedules and Task Configurations objects).  For example the pre-
>    configured Controller (specified as a Channel or Channels) may be
>    replaced with a specific Controller that is more appropriate to the
>    MA device type, location or characteristics of the network (e.g.
>    access technology type or broadband product).  The initial
>    communication Schedule may be replaced with one more relevant to
>    routine communications between the MA and the Controller.
>
>    While some Control protocols and uses may only use a single Schedule,
>    other protocols and uses may uses several Schedules (and related data
>    transfer Tasks) to update the Configuration Information, transfer the
>    Instruction Information, transfer Capability and Status Information
>    and send other information to the Controller such as log or error
>    notifications.  Multiple Channels may be used to communicate with the
>    same Controller over multiple interfaces (e.g. to send logging
>    information over a different network).
>
>    In addition the MA will be given further items of information that
>    relate specifically to the MA rather than the measurements it is to
>    conduct or how to report results.  The assignment of an ID to the MA
>    is mandatory.  If the MA Agent ID was not optionally provided during
>    the pre-configuration then one must be provided by the Controller
>    during Configuration.  Optionally a Group ID may also be given which
>    identifies a group of interest to which that MA belongs.  For example
>    the group could represent an ISP, broadband product, technology,
>    market classification, geographic region, or a combination of
>    multiple such characteristics.  Where the Measurement Group ID is set
>    an additional flag (the Report MA ID flag) is required to control
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 9]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    whether the Measurement Agent ID is also to be reported.  The
>    reporting of a Group ID without the MA ID allows the MA to remain
>    anonymous, which may be particularly useful to prevent tracking of
>    mobile MA devices.
>
>    Optionally an MA can also be configured to stop executing any
>    Instruction Schedule if the Controller is unreachable.  This can be
>    used as a fail-safe to stop Measurement and other Tasks being
>    conducted when there is doubt that the Instruction Information is
>    still valid. 
That makes sense, but have you considered the following case: when the 
Reporter is not available? Should the MA store all the reports? Will it 
have enough memory/space? What if it can't store it (memory/space).
If I take IPFIX as a specific LMAP platform, it's key to push the flow 
records (read Measurement Reports) as soon as possible.
Maybe this case is discussed in the framework draft?

Note that this would be another easy suppression mechanism: stopping the 
Reporting Channel

> This is simply represented as a time window in
>    milliseconds since the last communication with the Controller after
>    which Instruction Schedules are to be suspended.  The appropriate
>    vaue of the time window will depend on the specified communication
>    Schedule with the Controller and the duration for which the system is
>    willing to tolerate continued operation with potentially stale
>    Instruction Information.
>
>    While pre-configuration is persistent upon device reset or power
>    cycle due to its very nature, the persistency of the addtional
>    configuration information may be control protocol dependent. Some
>    protocols may assume that reset devices will revert back to their
>    pre-configuration state, while other protocols may assume that all
>    configuration and instruction information is held in persistent
>    storage.
>
>    It should be noted that control shedules and tasks cannot be
>    suppressed as evidenced by the lack of suppression information in the
>    Configuration.  The control schedule must only reference tasks listed
>    as control tasks.  Any suppress-by-default flag against control tasks
>    will be ignored.
>
>    Detail of the additional and updated information model elements:
"additional and updated"?
>
>    // MA Configuration
>
>    object {
>        uuid                ma-agent-id;
>       [ma-task-obj         ma-control-tasks<0..*>;]
>        ma-channel-obj      ma-control-channels<1..*>;
>       [ma-schedule-obj    ma-control-schedules<0..*>];
>       [urn                 ma-device-id;]
>        credentials         ma-credentials;
>       [string              ma-group-id;]
>       [boolean             ma-report-ma-id-flag;]
>       [int                 ma-control-channel-failure-threshold;]
>    } ma-config-obj;
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 10]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
> 3.4.  Instruction Information
>
>    The Instruction information model has four sub-elements:
>
>    1.  Instruction Task Configurations
>
>    2.  Report Channels
>
>    3.  Instruction Schedules
>
>    4.  Suppression
>
>    The Instruction supports the exceution of all Tasks on the MA except
execution
> those that deal with communication with the Controller (specified in
>    (pre)configuration information).  The Tasks are configured in
>    Instruction Task Configurations and inlcuded by reference in
included.
> Instruction Schdules that specify when to execute them.  The results
Schedules
 From now, I will stop mentioned spelling mistakes. I advice you to run 
the draft through a spell checker.
>    are communicated to other Tasks or over Report Channels.  Suppression
>    is used to temporarily stop the excution of new Tasks as specified by
>    the Instruction Schedules (and optionaly to stop ongoing Tasks).
>
>    A Task Configuration is used to configure the optional parameters of
>    a Task. 
Why "optional"? How are the non-optional parameters configured then?
Is there a difference between Task Configuration and Instruction Task 
Configurations?
> It also serves to instruct the MA about the Task including
>    the ability to resolve the Task to an executable and specifying the
>    schema for the Task parameters.
>
>    A Report Channel defines how to communicate with a single remote
>    system specified by a URL.  A Report Channel is used to send results
>    to single Collector but is no different in terms of the Information
>    Model to the Control Channel used to transfer information between the
>    MA and the Controller.  Several Report Channels can be defined to
>    enable results to be split or duplicated across different
>    destinations. 
The two sentences above are contradictory:
     to single Collector
     duplicated across different destinations.

> A single Channel can also be used by multiple
>    Schedules to transfer data at different cycles to the same Collector.
>    E.g. a single Collector may receive data at three different cycle
>    rates, one Schedule reporting hourly, another reporting daily and a
>    third specifying that results should be sent immediately for on-
>    demand measurement tasks.  Alternatively multiple Report Channels can
>    be used to send Measurement Task results to different Collectors.
>    The details of the Channel element is described later as it is common
>    to several objects.
>
>    Instruction Schedules specify which Tasks to execute according to a
>    given Timing (that can execute a single or repeated series of Tasks).
>    The Schedule also specifies how to deal with Task inputs and outputs
>    - e.g. sending selected outputs to other Tasks or specifying the
>    Report Channels that should be used to report results to Collectors.
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 11]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    Measurement Suppression information is used to over-ride the
>    Instruction Schedule and temporarily stop measurements or other Tasks
>    from running on the MA for a defined or indefinite period. While
>    conceptually measurements can be stopped by simply removing them from
>    the Measurement Schedule, splitting out separate information on
>    Measurement Suppression allows this information to be updated on the
>    MA on a different timing cycle or protocol implementation to the
>    Measurement Schedule.  It is also considered that it will be easier
>    for a human operator to implement a temporary explicit suppression
>    rather than having to move to a reduced Schedule and then roll-back
>    at a later time.
>
>    The explicit Suppression instruction message is able to simply
>    enable/disable all Instruction Tasks (that are enabled for default
>    suppression) as well as having fine control on which Tasks are
>    suppressed.  Suppression of both specified Task Configurations and
>    Measurement Schedules is supported.  Support for disabling specific
>    Task Configurations allows malfunctioning or mis-configured Tasks or
>    Task Configurations that have an impact on a particular part of the
>    network infrastructure (e.g., a particular Measurement Peer) to be
>    targetted.  Support for disabling specific Schedules allows for
>    particularly heavy cycles or sets of less essential Measurement Tasks
>    to be suppressed quickly and effectively.  Note that Suppression has
>    no effect on either Controller Tasks or Controller Schedules.
>
>    When no tasks or schedules are explicitly listed, all Instruction
Tasks or Schedules.
That's a generic comment on the draft. Be consistent with capitalization
> tasks will be suppressed (or not) as indicated by the suppress-by-
>    default flag in the Task Configuration.  If tasks or schedules are
>    listed explicitly then only these listed tasks or schedules will be
>    suppressed regardless of the suppress-by-default flag.  If both
>    individual tasks and individual schedules are listed then the union
>    of these options is considered - i.e. the listed shcedules plus the
>    listed tasks where present in other schedules.
>
>    Suppression stops new Tasks from executing.  In addtion, the
>    Suppression information also supports an additional Boolean that is
>    used to select whether on-going tasks are also to be terminated.
>
>    Unsuppression is achieved through either overwriting the Measurement
>    Suppression information (e.g. changing 'enabled' to False) or through
>    the use of an End time such that the Measurement Suppression will no
>    longer be in effect beyond this time.  The datetime format used for
>    all elements in the information model (e.g. the suppression start and
>    end dates) MUST conform to RFC 3339 [RFC3339] and ISO8601.
>
>    The goal when defining these four different elements is to allow each
>    part of the information model to change without affecting the other
>    three elements.  For example it is envisaged that the Report Channels
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 12]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    and the set of Task Configurations will be relatively static. The
>    Instruction Schedule, on the other hand, is likely to be more
>    dynamic, as the measurement panel and test frequency are changed for
>    various business goals.  Another example is that measurements can be
>    suppressed with a Suppression command without removing the existing
>    Instruction Schedules that would continue to apply after the
>    Suppression expires or is removed.  In terms of the Controller-MA
>    communication this can reduce the data overhead.  It also encourages
>    the re-use of the same standard Task Configurations and Reporting
>    Channels to help ensure consistency and reduce errors.
>
>    Definition of the information model elements:
>
> // Instruction to the MA to configure Tasks, Channels, Schedules and 
> Suppression
>
> object {
>     ma-task-obj         ma-instruction-tasks<0..*>;
>     ma-channel-obj      ma-report-channels<0..*>;
>     ma-schedule-obj     ma-instruction-schedules<0..*>;
>     ma-suppression-obj  ma-suppression;
> } ma-instruction-obj;
>
> // Suppression object to temporarily override new task execution in 
> Instructions and optionally stop currently running tasks
>
> object {
>     boolean             ma-suppression-enabled;
>    [boolean             ma-suppression-stop-ongoing-tasks;] // 
> default: false
>    [datetime            ma-suppression-start;] // default: immediate
>    [datetime            ma-suppression-end;]   // default: indefinite

> [string              ma-suppression-task-names<0..*>;]
>                         // default: all tasks if
>                         // ma-suppression-task-names is empty
>    [string ma-suppression-schedule-names<0..*>;]
>                         // default: all schedules if
>                         // ma-suppression-schedule-names is empty
> } ma-suppression-obj;
>
> 3.5.  Logging Information
 From what I can read in the framework, the logging information is 
always sent to the Controller.
Is that always what we want? Maybe the operational category 2 and 3 
logging information (and potentially the configuration information in 
category 1) should be sent to a syslog server.
 From my quick IM read, this is a limitation. Is this what you want?

>
>    The MA may report on the success or failure of Configuration or
>    Instruction communications from the Controller.  In addition further
>    operational logs may be produced during the operation of the MA and
>    updates to capabilities may also be reported.  Reporting this
>    information is achieved simply and flexibly in exactly the same
>    manner as any other Task.  We make no distinction between a
>    Measurement Task conducting an active or passive network measurement
>    and one which solely retrieves static or dynamic information from the
>    MA such as capabilities or logging information.  One or more logging
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 13]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    tasks can be programmed or configured to capture subsets of the
>    Logging Information.  These logging tasks are then executed by
>    Schedules which also specify that the resultant data is to be
>    transferred over the Controller Channels.
>
>    The type of Logging Information will fall into three different
>    categories:
>
>    1.  Success/failure/warning messages in response to information
>        updates from the Controller.  Failure messages could be produced
>        due to some inability to receive or parse the Controller
>        communication, or if the MA is not able to act as instructed.
>        For example:
>
>        *  "Measurement Schedules updated OK"
>
>        *  "Unable to parse JSON"
>
>        *  "Missing mandatory element: Measurement Timing"
>
>        *  "'Start' does not conform to schema - expected datetime"
>
>        *  "Date specified is in the past"
>
>        *  "'Hour' must be in the range 1..24"
>
>        *  "Schedule A refers to non-existent Measurement Task
>           Configuration"
>
>        *  "Measurement Task Configuration X registry entry Y not found"
>
>        *  "Updated Measurement Task Configurations do not include M used
>           by Measurement Schedule N"
>
>    2.  Operational updates from the MA.  For example:
>
>        *  "Out of memory: cannot record result"
>
>        *  "Collector 'collector.example.com' not responding"
>
>        *  "Unexpected restart"
>
>        *  "Suppression timeout"
>
>        *  "Failed to execute Measurement Task Configuration H"
>
>    3.  Status updates from the MA.  For example:
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 14]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>        *  "Interface added: eth3 "
>
>        *  "Supported measurements updated"
>
>        *  "New IP address on eth0: xxx.xxx.xxx.xxx"
>
>    This Information Model document does not detail the precise format of
>    logging information since it is to a large extent protocol and MA
>    specific.  However, some common information can be identified.
>
>    MA Logging information model elements:
>
>    // Logging object
>
>    object {
>        uuid                ma-log-agent-id;
>        datetime            ma-log-event-time;
>        code                ma-log-code;
>        string              ma-log-description;
>    } ma-log-obj;
>
> 3.6.  Capability and Status Information
>
>    The MA will hold Capability Information that can be retrieved by a
>    Controller.  Capabilities include the interface details available to
>    Measurement Tasks and Channels as well as the set of Measurement
>    Tasks/Roles that are actually installed or available on the MA.
>    Status information includes the times that operations were last
>    performed such as contacting the Controller or producing Reports.
>
>    MA Status information model elements:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 15]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    // Main MA Status information object
>
>    object {
>        uuid                ma-agent-id;
>        urn                 ma-device-id;
>        string              ma-hardware;
>        string              ma-firmware;
>        string              ma-version;
>        ma-interface-obj    ma-interfaces<0..*>;
>
>        datetime            ma-last-measurement;
>        datetime            ma-last-report;
>        datetime            ma-last-instruction;
>        datetime            ma-last-configuration;
>
>        [ma-condition-obj    ma-conditions<0..*>;]
>
>        ma-task-capability-obj   ma-supported-tasks<0..*>;
>    } ma-status-obj;
>
>    // Additional status conditions
>
>    object {
>      string                ma-condition-code;
>      string                ma-condition-text;
>    } ma-condition-obj
>
>
>    // Interface information
>
>    object {
>        string              ma-interface-name;
>        string              ma-interface-type;
>       [int                 ma-interface-speed;]  // bps
>       [string              ma-link-layer-address;]
>       [ip-address          ma-interface-ip-addresses<0..*>];
>       [ip-address          ma-interface-gateways<0..*>;]
>       [ip-address          ma-interface-dns-servers<0..*>;]
>    } ma-interface-obj;
>
>    // Supported tasks/roles
>
>    object {
>        string              ma-task-name;
>        uri                 ma-task-registry;
>        string              ma-task-role;
>    } ma-task-capability-obj;
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 16]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
This is where I arrived.
I'll stop here and review the next draft version.

Regards, Benoit