Subject: [lmap] Comments on draft-ietf-lmap-information-model-01

From: KEN KO <[email-masked]>
Date: Tue, 8 Jul 2014 21:30:18 +0000

I went through the latest draft of the information model in some detail to better understand how the relevant material in the framework was being developed. I think it is coming along nicely. Here are my comments:

Ken

*****Technical comments:

p.10, MA Configuration object: Shouldn't "ma-schedule-obj    ma-control-schedules<0..*>" be mandatory? Also, typo (remove 's' from mas-schedule-obj).

p.12, 2nd full para.: Suggest changing to "When no tasks or schedules are explicitly listed, all Instruction 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 the listed tasks or schedules will be suppressed regardless of the suppress-by-default flag." Note that we still need to define exactly what is suppressed when BOTH tasks and schedules are listed. I suggest that this combination be disallowed since it seems to add complexity but not a lot of additional value.

p.15 in ma-status-obj: Shouldn't we have a code field and a free text field in this structure to report status conditions?

p.16 in ma-interface-obj: If ma-interface-speed is an integer, suggest that it be specified in bps rather than Mbps. You never know when the extra resolution might be useful.

p.16 in ma-task-capability-obj: The Controller really needs to know about roles, not just registry entries (which to my understanding still correspond to Measurement Methods). It seems that this can be addressed in several ways:
- Make the registry entries correspond to roles. This seems counterintuitive as roles should be grouped under a common Method umbrella and the registry seems like the proper place to do that.
- Make the Role something more specific than just another parameter. Give it its own field in the registry, in Measurement Task configurations, and in this ma-task-capability-obj structure. I think we should consider this approach.

p.17, first full para.: "The result data rows may optionally include an indication of the cross-traffic." This should be generalized to any environmental metrics that may have bearing on the results. Relevant environmental metrics will be Measurement Method-specific, and I think that in some cases the testing of environmental metrics will be defined in their own Measurement Tasks whose outputs are then forwarded to other Measurement Tasks.

p.18 in ma-result-row-obj: Regarding the above comment, ma-report-result-cross-traffic should be replaced with something more generic. It and other environmental values should probably just be columns within ma-report-result-values.

p.19: Filters need a lot more description. This section leaves the reader bewildered as to how they are used.

p.22 in ma-task-obj: Does this need to specify an optional ma-interface-obj?

*****Editorial comments:

Section 2: Delete redundant right angle bracket.

Item 6 on p.5:  "Information transmitted from the MA to /the Collector/one or more Collectors/ including ..."

Top of p.7: "The objects shown in brackets ..." The diagram has no brackets. Parentheses?

p.7, 2nd para: "It should be clear that the /general capability/top level behavior/ of an MA is simply to execute Schedules. Every /other action of an MA is implemented /action referenced by a Schedule is defined/ as a Task."

p.7, 2nd para: "While in terms of the Information Model, all Tasks have the same /information/structure/, it can help ..."

p.7, under Measurement Tasks: Replace A (Active) and B (Passive) with: "Measurement Tasks measure some aspect of network performance or traffic." In general, scrub the IM for references to Active and Passive Measurements and remove the distinction unless it is serving a specific purpose.

p.8, 2nd para.: "Multiple channels may be given to the Controller (such as over different interfaces or network protocols)." If this means what I think (I may be wrong), suggest instead "While multiple channels may be provided in the pre-configuration information they must all be associated with a single Controller (e.g., over different interfaces or network protocols)."

p.9, 2nd para. in 3.2: "Multiple Channels may be used to communicate with the Controller over multiple interfaces (e.g. to send logging information over a different network)." Again, note that all Channels associated with a Controller must point to the same Controller.

Section 3.2 refers to the MA UUID as optional and Section 3.3 refers to it as mandatory. It would help to clarify in Section 3.2 that the MA UUID is optional only as a pre-configuration parameter and that it will be required upon registration with a Controller.

Sections 3.2 and 3.3 - Note somewhere that the suppression flag field in the ma-control-task objects must be ignored.

p.11, 4th para.: "Instruction Schedules specify which Tasks to execute according to a /simngle// given Timing ..."

Section 3.6, 1st para.: "...as well as the set of /Measurement Tasks/Measurement Method roles/ that are actually installed ..." Throughput section 3.6 and globally use Measurement Method roles depending on context.

Section 3.7: Reading this I thought the destinations for specific results would be configured in Task configurations. Later on, I see that this isn't so - result forwarding is defined in Schedules. This should probably be clarified in this section as well to avoid confusing readers who don't dig into the schedules section.

Section 3.9, 2nd para.: "Each Channel contains the details of the //remote/ endpoint ..."

Section 3.10, 2nd para.: A Registry entry does not identify a Measurement Task - it identifies a Measurement Method. A Task is a single instantiation of the Method (or more precisely, of a role specified within the Method). Also see above note regarding whether roles should be identifiable apart from other parameters for capabilities reporting purposes.

p.22 in ma-task-obj: Change /ma-task-registry/ma-task-registry-entry/.

p.22 in ma-task-obj: Consider adding a specific parameter for ma-task-role. See above.

p.23: While I see that the comment just above ma-timing-obj says something about how to interpret/specify ma-timing-random-spread, I think it needs a more formal definition. Maybe adding to the first paragraph on the page: "The randomness parameter defines a uniform interval in msec over which the start of the task is delayed from the starting times specified by the timing object."

Section 3.11.1: while the default for ma-periodic-end may be indefinite, it may be worthwhile to note here the best practice to specify an end date that must be periodically refreshed, to prevent "zombie tasks" from continuing forever if an MA loses contact with its Controller. The same comment applies to the other versions of the timing object.

Section 3.12: /ma-calendar-days-of-week<0..*>;] // default: all/ma-calendar-days-of-week<0..*>;] // default: 1-7/

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 09:14:24 +0100

Ken, Thanks for the very thorough review - we'll pick these up on the next edit.

One question though - I didn't understand what you meant by "roles" in the discussion around the registry entries. Can you explain a bit more please?

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: 08 July 2014 22:30
To: [email-masked]
Subject: [lmap] Comments on draft-ietf-lmap-information-model-01

Ken

*****Technical comments:

*****Editorial comments:

---

From: KEN KO <[email-masked]>
Date: Wed, 9 Jul 2014 14:24:56 +0000

Sure. By the way, I'm basing this on my understanding of current terminology usage in both the lmap framework and BBF WT-304. Both of these drafts were updated as a result of discussions that took place from late May to mid-June, mostly on the lmap list.

Most of the Measurement Methods to be listed in the ippm active registry will involve the participation of more than one MA. Each Method is defined holistically - that is, in terms of the overall process involving as many MAs as necessary. Different MAs, however, can play different roles in the execution of the same Method - for example, one MA may act as an HTTP client and another as an HTTP server. The Method must identify these roles and the parameters applicable to each role in its definition.

An MA may have the executable code to participate in a Method in one role but not another - for instance, an MA within an RG may be able to act as an HTTP client but not as a server. The Controller needs to understand this distinction to include the correct Measurement Task configurations in any Instructions it sends. That is the source of my comment about including roles in the Capabilities sent to the Controller.

Cutting and pasting the applicable definitions from Terminologies in lmap-framework-07:

Capabilities: Information about the performance measurement capabilities of the MA, in particular the Measurement Method roles and measurement protocol roles that it can perform, and the device hosting the MA, for example its interface type and speed, but not dynamic information.

Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles.

Measurement Task: The action performed by a particular Measurement Agent that consists of the single assessment of a Metric through operation of a Measurement Method role at a particular time, with all of the role's Input Parameters set to specific values.

I hope this helps and wasn't too long winded.

Ken

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 09, 2014 4:14 AM
To: KEN KO; [email-masked]
Subject: RE: Comments on draft-ietf-lmap-information-model-01

Trevor.

Trevor Burbridge

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: 08 July 2014 22:30
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] Comments on draft-ietf-lmap-information-model-01

Ken

*****Technical comments:

*****Editorial comments:

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 16:16:43 +0100

OK - thanks. Yes that would necessitate some role information in the task configuration.

Trevor.

Trevor Burbridge

From: KEN KO [mailto:[email-masked]]
Sent: 09 July 2014 15:25
To: Burbridge,T,Trevor,TUB8 R; [email-masked]
Subject: RE: Comments on draft-ietf-lmap-information-model-01

Ken

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 09, 2014 4:14 AM
To: KEN KO; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ietf-lmap-information-model-01

Trevor.

Trevor Burbridge

Ken

*****Technical comments:

*****Editorial comments:

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 9 Jul 2014 11:17:27 -0400

Hi Ken,

One tweak below...

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Wednesday, July 09, 2014 10:25 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-01
...
Most of the Measurement Methods to be listed in the ippm active registry will involve the participation of more than one MA. Each Method is defined holistically - that is, in terms of the overall process involving as many MAs as necessary. Different MAs, however, can play different roles in the execution of the same Method - for example, one MA may act as an HTTP client and another as an HTTP server. The Method must identify these roles and the parameters applicable to each role in its definition.
The tweak is this:

The registry will be organized by Metrics.
Each Metric will have Parameters and a Method of Measurement.
As part of the Method of Measurement, roles will be identified and
defined as needed.

So, the Metric's Parameters apply more-or-less to different roles.
The method will use the Parameters when specifying process steps for
each role (e.g., The destination host will wait at least Tmax seconds
before recording that a packet is lost.). However, we won't distinguish
the primary Parameters for each role in the Parameter lists (fixed and run-time)
in the registry.

Al

---

From: KEN KO <[email-masked]>
Date: Wed, 9 Jul 2014 15:46:18 +0000

Thanks for the clarification, Al. That's much more precise than my description.

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Wednesday, July 09, 2014 11:17 AM
To: KEN KO; [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-lmap-information-model-01

Hi Ken,

One tweak below...

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Al