Subject: [lmap] Proposed definition of Cycle-ID and related changes

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 8 Jun 2016 07:07:59 -0400

A small group discussed definitions, as requested 
during our LMAP session at IETF-95, primarily Cycle-ID.

Here are the definitions that we agreed to propose.
regards,
Tim, Phil, Barbara, Al

-=-=-=-=-=-=-=-=-=-=-=-=-=-

Cycle-ID

The Cycle-ID provides an easily distinguishable index for sets of results (or other aspect) from each "cycle" of Repeating Events (Recurring according to their Schedule). The Cycle-ID is comprised of two (2) parts; the Cycle-Context-ID and the Cycle-Number. The Cycle-Context-ID is used to correlate the set of results from each "cycle" in a larger systems context. For example the Cycle-Context-ID for a test related to a subscriber might use the service provider's handle for the subscriber. The Cycle-Number is a numerical field that describes the relative placement (index) of a set of results within the re-occurring event. Each event occurrence of a Task's results (e.g., measurements of multiple metrics on a single packet stream) are assigned the same Cycle-ID.

The MA receives the form and policy to generate the Cycle-ID as part of the Instruction's Schedule. The Cycle-Context-ID is provided through the use of the Tags and information on how a MA calculates the Cycle-Number is provided through information elements in the Schedule.

The MA generates a new Cycle-Number for each periodic or calendar Event. The MA reports that Cycle-ID with the corresponding results for the Task.

------------------------------------------------------------------
Also, we need to change the definition of "tags" to make it clear that the tag must be echoed (not changed) by the MA.
So:
   ma-report-result-tags:          An optional unordered set of tags.
                                   This is the joined set of tags
                                   defined for the task object and the
                                   action object.
becomes
   ma-report-result-tags:          An optional unordered set of tags.
                                   This is the joined set of tags
                                   defined for the task object and the
                                   action object, echoed by the MA.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 Jun 2016 11:14:52 +0000

Thanks to the small team.

>  The Cycle-Number is a numerical field
> that describes the relative placement (index) of a set of results within the re-
> occurring event.

It is implied that the Cycle-Number is a monotonous increasing numerical index (within a given Cycle-Context), right? Maybe this should be made explicit. 

Regards, 

Dan

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED
> C (AL)
> Sent: Wednesday, June 08, 2016 2:08 PM
> To: [email-masked]
> Cc: Carey, Timothy (Nokia - US) ([email-masked]);
> [email-masked]; STARK, BARBARA H
> Subject: [lmap] Proposed definition of Cycle-ID and related changes
> 
> A small group discussed definitions, as requested during our LMAP session at
> IETF-95, primarily Cycle-ID.
> 
> The Cycle-ID provides an easily distinguishable index for sets of results (or
> other aspect) from each "cycle" of Repeating Events (Recurring according to
> their Schedule). The Cycle-ID is comprised of two (2) parts; the Cycle-
> Context-ID and the Cycle-Number. The Cycle-Context-ID is used to correlate
> the set of results from each "cycle" in a larger systems context. For example
> the Cycle-Context-ID for a test related to a subscriber might use the service
> provider's handle for the subscriber. The Cycle-Number is a numerical field
> that describes the relative placement (index) of a set of results within the re-
> occurring event. Each event occurrence of a Task's results (e.g.,
> measurements of multiple metrics on a single packet stream) are assigned
> the same Cycle-ID.
> 
> The MA receives the form and policy to generate the Cycle-ID as part of the
> Instruction's Schedule. The Cycle-Context-ID is provided through the use of
> the Tags and information on how a MA calculates the Cycle-Number is
> provided through information elements in the Schedule.
> 
> The MA generates a new Cycle-Number for each periodic or calendar Event.
> The MA reports that Cycle-ID with the corresponding results for the Task.
> 
> _______________________________________________

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 8 Jun 2016 07:19:29 -0400

Dan,
...
> It is implied that the Cycle-Number is a monotonous increasing numerical
> index (within a given Cycle-Context), right? Maybe this should be made
> explicit.
[ACM] 
It could be more complex than a simple monotonic counter,
and we leave the possibilities open.
Al

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 Jun 2016 11:21:56 +0000

> From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> Sent: Wednesday, June 08, 2016 2:19 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: Proposed definition of Cycle-ID and related changes
> 
> Dan,
> ...
> > >  The Cycle-Number is a numerical field that describes the relative
> > > placement (index) of a set of results
> > within the re-
> > > occurring event.
> >
> > It is implied that the Cycle-Number is a monotonous increasing
> > numerical index (within a given Cycle-Context), right? Maybe this
> > should be made explicit.
> [ACM]
> It could be more complex than a simple monotonic counter, and we leave
> the possibilities open.
> Al
> 

So what does 'relative placement' mean? Maybe you can give an example of one more complex case, and how the index should asses the 'relative placement'? 

Thanks and Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Jun 2016 13:35:37 +0200

Thanks for the input.

Is my simple interpretation correct that all I have to do is to add an
ma-report-result-event-id to the ma-report-result-obj? I find event-id
easier to understand than cycle-number and also clearer to implement
since everything is driven by events (and not cycles).

I am also not sure that adding 'echoed by the MA' to the description
of ma-report-result-tags adds much value given that the text already
says "This is the joined set of tags defined for the task object and
the action object".

/js

On Wed, Jun 08, 2016 at 07:07:59AM -0400, MORTON, ALFRED C (AL) wrote:
> 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 (Nokia - US)" <[email-masked]>
Date: Sat, 11 Jun 2016 16:46:35 +0000

Juergen,

There are 3 things that need to be supported

1) Cycle-Context-ID: Input as an option (we should discuss if this is an option or a tag - I assume option because it is a name/value pair Cycle-Context-ID:MyTest) associated Schedule or Action - We should discuss if this option name should be reserved in LMAP like channel or role.
2) Cycle-ID: As Al said this is generated based on: The MA receives the form and policy to generate the Cycle-ID as part of the Instruction's Schedule. The problem I see is "what is the form and policy that would be used" - We haven't addressed this piece. For example - there might be a policy to simply increment the Cycle-number.  If this is part of the knowledge of the task registry entry then OK; otherwise we might need some enhancements to the information model
3) Cycle-ID: This option (again name/value pair Cycle-ID:MyTest-1) is reported in the options element of the Result object. We should discuss if this option name should be reserved in LMAP. So a result would have the Cycle-Context-ID (since it was passed as input and echoed) and Cycle-ID in the result tags.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, June 08, 2016 6:36 AM
To: MORTON, ALFRED C (AL)
Cc: Carey, Timothy (Nokia - US); [email-masked]; STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Proposed definition of Cycle-ID and related changes

Thanks for the input.

Is my simple interpretation correct that all I have to do is to add an ma-report-result-event-id to the ma-report-result-obj? I find event-id easier to understand than cycle-number and also clearer to implement since everything is driven by events (and not cycles).

I am also not sure that adding 'echoed by the MA' to the description of ma-report-result-tags adds much value given that the text already says "This is the joined set of tags defined for the task object and the action object".

/js

On Wed, Jun 08, 2016 at 07:07:59AM -0400, MORTON, ALFRED C (AL) wrote:
> A small group discussed definitions, as requested during our LMAP 
> session at IETF-95, primarily Cycle-ID.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Jun 2016 13:39:12 +0200

> 1) Cycle-Context-ID: Input as an option (we should discuss if this is an option or a tag - I assume option because it is a name/value pair Cycle-Context-ID:MyTest) associated Schedule or Action - W…

Why would this be an option and not just a tag? Options are used to
pass information to a running task; I do not think the task needs to
know the Cycle-Context-ID since it is a pure organizational matter.

> 2) Cycle-ID: As Al said this is generated based on: The MA receives the form and policy to generate the Cycle-ID as part of the Instruction's Schedule. The problem I see is "what is the form and po…

Hence my proposal is that the implementation creates a unique event-id
for every firing event and this event-id is reported with the
result. I hope this event-id can be as simple as a counter that I bump
whenever an event fires.

> 3) Cycle-ID: This option (again name/value pair Cycle-ID:MyTest-1) is reported in the options element of the Result object. We should discuss if this option name should be reserved in LMAP. So a re…

Tags are already reported back in the result. I am not sure there is
anything needed to be done here.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 13 Jun 2016 13:36:02 +0000

Juergen,

Inline <TAC>

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 13, 2016 6:39 AM
To: Carey, Timothy (Nokia - US)
Cc: MORTON, ALFRED C (AL); [email-masked]; STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Proposed definition of Cycle-ID and related changes

> 1) Cycle-Context-ID: Input as an option (we should discuss if this is an option or a tag - I assume option because it is a name/value pair Cycle-Context-ID:MyTest) associated Schedule or Action - W…

Why would this be an option and not just a tag? Options are used to pass information to a running task; I do not think the task needs to know the Cycle-Context-ID since it is a pure organizational matter.
<TAC> As I understand it tags do not have the capability for a Name and Value - its just a tag. So using a tag I can't know if MyTest tag value is the Cycle-Context-ID. However if I use an option - I could have Cycle-Context-ID name and MyTest value.

> 2) Cycle-ID: As Al said this is generated based on: The MA receives 
> the form and policy to generate the Cycle-ID as part of the 
> Instruction's Schedule. The problem I see is "what is the form and 
> policy that would be used" - We haven't addressed this piece. For 
> example - there might be a policy to simply increment the 
> Cycle-number.  If this is part of the knowledge of the task registry 
> entry then OK; otherwise we might need some enhancements to the 
> information model

Hence my proposal is that the implementation creates a unique event-id for every firing event and this event-id is reported with the result. I hope this event-id can be as simple as a counter that I bump whenever an event fires.
<TAC> Well Cycle-numbers are necessarily tied to a firing of event - I thought it had its own context and definition - which can be tied to a firing of an event -sure but we risk overloading the term event-id. Which I would like to avoid.

> 3) Cycle-ID: This option (again name/value pair Cycle-ID:MyTest-1) is reported in the options element of the Result object. We should discuss if this option name should be reserved in LMAP. So a re…

Tags are already reported back in the result. I am not sure there is anything needed to be done here.
<TAC> The Cycle-ID is a result of combining the Cycle-Context-ID and the Cycle-Number - So for results - the Cycle-Context-ID is reported as a tag or option but the Cycle-Number is not reported - so we need to report that (or the combined Cycle-ID as an option, tag or as you suggest and I am leary of, an event-id.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Jun 2016 15:43:28 +0200

> <TAC> As I understand it tags do not have the capability for a Name and Value - its just a tag. So using a tag I can't know if MyTest tag value is the Cycle-Context-ID. However if I use an option -…

A Cycle-Context-ID is generated by a controller and likely meaningful
to a piece of software analyzing data collected by a collector. I
would assume that the data analysis software will obtain information
from the controll about the tags the controller used to tag
measurements.
 
> <TAC> Well Cycle-numbers are necessarily tied to a firing of event - I thought it had its own context and definition - which can be tied to a firing of an event -sure but we risk overloading the te…

So what is then this 'own context and definition' and how would I
implement it? I do know how to implement an event-id and from what I
understood Al Morton talking about this event-id would give him the
means to correlate results.

> <TAC> The Cycle-ID is a result of combining the Cycle-Context-ID and the Cycle-Number - So for results - the Cycle-Context-ID is reported as a tag or option but the Cycle-Number is not reported - s…

My simple minded solution is that the controller tags measurements as
it sees fit (this takes care of the Cycle-Context-ID) and the LMAP
implementation would add an event-id to the result records, which
echoes back the tags already. A data analysis program can then filter
on both of them if desired.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 13 Jun 2016 13:52:18 +0000

Inline <TAC2>

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 13, 2016 8:43 AM
To: Carey, Timothy (Nokia - US)
Cc: MORTON, ALFRED C (AL); [email-masked]; STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Proposed definition of Cycle-ID and related changes

On Mon, Jun 13, 2016 at 01:36:02PM +0000, Carey, Timothy (Nokia - US) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

A Cycle-Context-ID is generated by a controller and likely meaningful to a piece of software analyzing data collected by a collector. I would assume that the data analysis software will obtain information from the controll about the tags the controller used to tag measurements.

<TAC2> Lets ask Al; what happens if/when the MAs and controllers are not in the same administrative domain - Me I like to be explicit about these things.
 
> <TAC> Well Cycle-numbers are necessarily tied to a firing of event - I thought it had its own context and definition - which can be tied to a firing of an event -sure but we risk overloading the te…

So what is then this 'own context and definition' and how would I implement it? I do know how to implement an event-id and from what I understood Al Morton talking about this event-id would give him the means to correlate results.
<TAC2> Correct the Cycle-Number allows you to correlate the results within the context of the Cycle-Context-ID. How the Cycle-Number is calculated is what isn't defined right now and we should discuss how that is defined.

> <TAC> The Cycle-ID is a result of combining the Cycle-Context-ID and the Cycle-Number - So for results - the Cycle-Context-ID is reported as a tag or option but the Cycle-Number is not reported - s…

My simple minded solution is that the controller tags measurements as it sees fit (this takes care of the Cycle-Context-ID) and the LMAP implementation would add an event-id to the result records, which echoes back the tags already. A data analysis program can then filter on both of them if desired.
<TAC> Yep I see that - Lets just make sure of the assumptions that the Context-ID can be used as a tag and the cycle-number can be restricted to the algorithm that would assign an event-id. Again I just like to be explicit since we do not know how this would work across administrative domains or if the operators would be able enforce a naming convention on a tag so that their system knows this is the Cycle-Context-ID.

/js