Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag?

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jul 2016 15:34:12 +0200

On Tue, Jun 14, 2016 at 07:20:19PM +0000, Carey, Timothy (Nokia - US) wrote:
> At the June 13, 2016 LMAP interim meeting we discussed whether the
> Cycle-Context-ID should be passed as a tag or option from the controller to the MA.  The group asked if we could attempt to come to consensus on this over the email list.
> 
> The following background information should be considered when deciding if something should be a tag or option.
> 
> 
> 1)      Tags were meant to be used within the MA and were not intended to be "passed" to measurement functions.
> 
> 2)      Tags are simply a list of free formatted strings
> 
> 3)      Tags can be assigned to tasks, schedules and actions
> 
> 4)      Tags were intended to be echoed by the results for the scheduled action.
> 
> 5)      Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA.
> 
> 6)      Options are list of name value pairs where the name has meaning. Some option names are reserved (i.e., Role, Channel)

I think we effectively eliminated the Role option since we now list
the set of roles as part of the ma-metric-registry-obj itself.
 
> 7)      Options can be assigned to tasks, schedules and actions
> 
> 8)      Options are reported by the results for the scheduled action
> 
> With this background in mind - there are 2 ways for a controller to pass the Cycle Context Identifier - as a tag or an option.
> 
> 
> If the identifier is used as a tag - the string value of the tag probably needs to have some format for the name (e.g., CycleContextId:<value>). As pointed out the value of the name portion of the tag could be an organizational construct.
> 
> If the identifier is used as an option -  we could reserve a name for the Option (e.g., CycleContextId). However it also could be an organizational construct as well.
> 
> So the choice is Tag or Option. If we use an option should we also reserve a name.
> 
> My opinion is to use an Option with a reserved name. This way every controller, agent, collector would understand the meaning.
>

I think the right tool here is a tag since there is no point to pass
the CycleContextId to the measurement functions. Tags are there for,
well, tagging (and this is what the CycleContextId is). The other meta
questions are whether the CycleContextId must be recognizable at all
and what you dof if for example a specific measurement serves multiple
purposes. I would prefer to not standardize how the tags are exactly
used. This does not preclude that other organizations establish
guidelines or conventions and who knows perhaps some of them will
become universally used. But at this point, me preference would be to
say 'if you need to tag your measurements, simply tag them'.

/js

-- 
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: Tue, 5 Jul 2016 17:58:44 +0000

Juergen,

Yes you are correct about role as an option. So the only well known option is Channel; which still holds the argument for an option to be used within the MA
> 5)      Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA.

BR,
Tim
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, July 05, 2016 8:34 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag?

> 6)      Options are list of name value pairs where the name has meaning. Some option names are reserved (i.e., Role, Channel)

I think we effectively eliminated the Role option since we now list the set of roles as part of the ma-metric-registry-obj itself.
 
> My opinion is to use an Option with a reserved name. This way every controller, agent, collector would understand the meaning.

I think the right tool here is a tag since there is no point to pass the CycleContextId to the measurement functions. Tags are there for, well, tagging (and this is what the CycleContextId is). The other meta questions are whether the CycleContextId must be recognizable at all and what you dof if for example a specific measurement serves multiple purposes. I would prefer to not standardize how the tags are exactly used. This does not preclude that other organizations establish guidelines or conventions and who knows perhaps some of them will become universally used. But at this point, me preference would be to say 'if you need to tag your measurements, simply tag them'.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Tue, 5 Jul 2016 18:02:47 +0000

Sorry I hit send accidentally

Yes you are correct about role as an option. So the only well known option is Channel; which still holds the argument for an option to be used within the MA but not the passed to a tag'

> 5)      Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA.

So it would be 
> 5)      Options are be assigned by the controller and either used within the MA (i.e., Channel).

BR,
Tim
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, July 05, 2016 8:34 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag?

 

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jul 2016 15:07:02 +0200

> > 5)      Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA.

This depends how you implement things. In my implementation, the
reporting will be done by just another task. So the channel
information is passed to the task.
 
> > 5)      Options are be assigned by the controller and either used within the MA (i.e., Channel).

This sound wrong since most options will be providing information to the measurement tasks. I think the better wording is:

5)      Options are be assigned by the controller and passed to tasks by the MA.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 7 Jul 2016 13:11:03 +0000

Juergen,

But how do we handle Channel?- There are channels used for the MA itself, right?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, July 07, 2016 8:07 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag?

> > 5)      Options are be assigned by the controller and either used within the MA (e.g., Channel) or passed to the measurement function by the MA.

This depends how you implement things. In my implementation, the reporting will be done by just another task. So the channel information is passed to the task.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jul 2016 15:23:51 +0200

I think the information model also allows the communication with the
controller to be a separate task:

   Tasks can implement a variety of different types of Actions.  While
   in terms of the Information Model, all Tasks have the same structure,
   it can help conceptually to think of different Task categories:

   1.  Measurement Tasks measure some aspect of network performance or
       traffic.  They may also capture contextual information from the
       MA device or network interfaces such as the device type or
       interface speed.

   2.  Data Transfer Tasks

       A.  Reporting Tasks report the results of Measurement Tasks to
           Collectors

       B.  Control Task(s) implement the Control Protocol and
           communicate with the Controller.

   3.  Data Analysis Tasks can exist to analyse data from other
       Measurement Tasks locally on the MA

   4.  Data Management Tasks may exist to clean-up, filter or compress
       data on the MA such as Measurement Task results

That said, I would not mind to get read of the well-known Channel
option as well. One thing I have to do is to work through a concrete
example how things will work with YANG/RESTCONF and in particular the
NETCONF/RESTCONF configuration data models worked on in the NETCONF
working group. Another option is that the IPPM metrics registry, which
currently is designed for Measurement Tasks, also hosts entries for
other tasks so that their options are defined outside the information
model and data models. I thinking loud, not sure any of this is really
a workable idea.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 7 Jul 2016 13:32:11 +0000

Juergen,

I am fine with your explaination (albeit the term tasks implies and implementation). Given this explaination the cycle context identifier can be used as an option its just given to a MA "task".

Anyway - the question is if we use a tag - do we need to have a specific format so that Controllers and Collectors will know this the Cycle-context-identifier. For options this is handled via a well known name.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, July 07, 2016 8:24 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] Information Model: Cycle Context Identifier Option or Tag?

I think the information model also allows the communication with the controller to be a separate task:

   2.  Data Transfer Tasks

That said, I would not mind to get read of the well-known Channel option as well. One thing I have to do is to work through a concrete example how things will work with YANG/RESTCONF and in particular the NETCONF/RESTCONF configuration data models worked on in the NETCONF working group. Another option is that the IPPM metrics registry, which currently is designed for Measurement Tasks, also hosts entries for other tasks so that their options are defined outside the information model and data models. I thinking loud, not sure any of this is really a workable idea.

/js

On Thu, Jul 07, 2016 at 01:11:03PM +0000, Carey, Timothy (Nokia - US) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > From: Juergen Schoenwaelder 
> > [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jul 2016 16:08:26 +0200

> I am fine with your explaination (albeit the term tasks implies and implementation). Given this explaination the cycle context identifier can be used as an option its just given to a MA "task".

I think the model is really simple:

- The MA is executing tasks.

- Options are name/value pairs and passed from the MA to tasks.

- Tags are simple strings and maintained by the MA but they are not
  passed to tasks.

Obviously, the MA is not executing itself as a task.

> Anyway - the question is if we use a tag - do we need to have a specific format so that Controllers and Collectors will know this the Cycle-context-identifier. For options this is handled via a wel…

- The tag used to identify a measurement cycle is only relevant for
  the code/human configuring the controller and doing the data
  analysis, i.e. consuming the data collected by the collector. Hence,
  all we have to do is to provide a means to carry the tags around
  (which we have accomplished).

- We define an information model that governs the design of data
  models / protocols that are used in concrete implementations. I do
  not think the information model should not define concrete option
  names or tag formats.

- If there is a need to define common or well-known option names or
  tag formats, I think we should do this separately so that these can
  evolve and change over time without requiring updates to the
  information model.

Given this, I propose to (a) not detail how tags are used to carry a
cycle ID and (b) to remove the text suggesting that there is a special
Channel option name. This kind of information should either fall out
of a registry or a separate applicability specification.

/js