Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 2015 16:13:44 +0200

Tim,

we have removed the notion of multiple outputs and we have simplified
the model such that outputs can only be fed into another schedule (but
not into an action of a schedule). The new model is that measurement
tasks will tag results and if certain tags are not needed, you filter
the output based on the tags.

/js

On Mon, Jul 27, 2015 at 08:23:01PM +0000, Carey, Timothy (Timothy) wrote:
> Juergen,
> 
> I was looking at the definition of ma-action-destinations. I don't understand what we did here.
> 
> It used to be the case that a registry entry can define outputs that were pipelined to a scheduled action. Now I it looks like it is a schedule.
> 
> However previously we said:
> An empty list means that all outputs defined by the Action's task registry are invoked. - this is missing from you draft - what do we do with an empty list?
> 
> Likewise we actually defined the output number to a list of Schedules - I didn't see that modeled in the simple list of schedules.
> 
> BR,
> Tim

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 
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: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 25 Sep 2015 12:39:08 +0000

<Renamed the Subject>

Juergen,

"We have removed the notion of multiple outputs and we have simplified the model such that outputs can only be fed into another schedule (but not into an action of a schedule)."

Is Al Morton and the IPPM team ok with this modification?
The only reason I ask is that the IPPM registry draft for output categories has been unchanged since January. So are we constraining (simplifying) what was agreed to previously?

Remember a schedule can contain a List of Actions thus a List of Outputs.

If the IPPM team is fine with the simplification; I am OK as well. The easier the better in my view.

Juergen - So where is the "link" between the Scheduled Action's output and the downstream Schedule? I didn't see this relationship.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2015 9:14 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06

Tim,

we have removed the notion of multiple outputs and we have simplified the model such that outputs can only be fed into another schedule (but not into an action of a schedule). The new model is that measurement tasks will tag results and if certain tags are not needed, you filter the output based on the tags.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 26 Sep 2015 13:17:43 -0400

I'm grappling with the current meaning of "output" here.

Actions perform Tasks. Tasks produce Output. 
Output is consumed by Destination Schedules.

   ma-action-destinations:   An optional and possibly empty list of
                             names of destination schedules that consume
                             output produced by this action.

So, when we allow a Task to contain multiple Metric Registry URIs,
there will be a measured result for each Metric, which we would call
multiple outputs in the Registry Draft.  But if all the measured results
are considered "one" Output in the Info Model, then we appear to be 
synchronized on the notion of Output.

Then, if the Output can be fed to another schedule, with another action
to further process, or store the measured results with earlier results
for later reporting, or report according to the schedule, then that will work, too.

It's very difficult to gain procedural insights from an abstract model
alone. 

Al

> From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy
> (Timothy)
> Sent: Friday, September 25, 2015 8:39 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Simplification
> of multiple outputs resulting from an Action or List of Actions)
> 
> <Renamed the Subject>
> 
> Juergen,
> 
> "We have removed the notion of multiple outputs and we have simplified
> not into an action of a schedule)."
> 
> The only reason I ask is that the IPPM registry draft for output
> categories has been unchanged since January. So are we constraining
> (simplifying) what was agreed to previously?
> 
> Juergen - So where is the "link" between the Scheduled Action's output
> and the downstream Schedule? I didn't see this relationship.
> 
> BR,
> Tim
> 
> 
> > It used to be the case that a registry entry can define outputs that
> were pipelined to a scheduled action. Now I it looks like it is a
> schedule.
> >
> > An empty list means that all outputs defined by the Action's task
> registry are invoked. - this is missing from you draft - what do we do
> with an empty list?
> >
> > Likewise we actually defined the output number to a list of Schedules
> - I didn't see that modeled in the simple list of schedules.
> >
> > BR,
> > Tim
>

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 26 Sep 2015 19:33:20 +0000

Al,

Yes it is very difficult at the abstract level - I think I mentioned this in the last thread.

If we can take a concrete example (say TWAMP) and map from the Registry to the IM for a given task (run a TWAMP test for say 2 metrics) I think that will begin to alleviate the confusion.

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Saturday, September 26, 2015 12:18 PM
To: Carey, Timothy (Timothy); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification of multiple outputs resulting from an Action or List of Actions)

So, when we allow a Task to contain multiple Metric Registry URIs, there will be a measured result for each Metric, which we would call multiple outputs in the Registry Draft.  But if all the measured results are considered "one" Output in the Info Model, then we appear to be synchronized on the notion of Output.

Then, if the Output can be fed to another schedule, with another action to further process, or store the measured results with earlier results for later reporting, or report according to the schedule, then that will work, too.

It's very difficult to gain procedural insights from an abstract model alone. 

Al

> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: 
> Simplification of multiple outputs resulting from an Action or List of 
> Actions)
> 
> <Renamed the Subject>
> 
> Juergen,
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 26 Sep 2015 18:17:53 -0400

Yes, I've been working on a task configuration and report task configuration
using TWAMP and two metrics measured by the same task for the last day or so.
When you add that to the Registry example/initial contents draft,
that's a lot to cover at the Interim.

It's not the whole InfoModel picture, and maybe others will help with the rest
of a complete example so we will see what we really have here in a less
abstract form.

Al

> From: Carey, Timothy (Timothy) [mailto:[email-masked]]
> Sent: Saturday, September 26, 2015 3:33 PM
> To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification
> If we can take a concrete example (say TWAMP) and map from the Registry
> to the IM for a given task (run a TWAMP test for say 2 metrics) I think
> that will begin to alleviate the confusion.
> 
> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Simplification
> So, when we allow a Task to contain multiple Metric Registry URIs, there
> will be a measured result for each Metric, which we would call multiple
> outputs in the Registry Draft.  But if all the measured results are
> considered "one" Output in the Info Model, then we appear to be

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Sep 2015 15:29:37 +0200

Here is my understanding:

I think a task has one output but that one output can carry multiple
metrics. The metrics are properly tagged so that they can be filtered.
If task M produce metrics m1 andf m2, then the result records should
include the tags m1 and m2. If the output of M is forwarded to another
task, the task can either consume both m1 and m2 or it might simply
filter out one of them.

It would be nice if the registry would not just define the metrics but
also the tags for the metrics (as well as the option names used to set
the parameters of the metric).

/js