Subject: [lmap] well known channel names

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Aug 2016 13:09:15 +0200

Hi,

here is an attempt to resolve the discussion around option names.

OLD

   While many of the Task Configuration Options are left to individual
   tasks to define, some common Options are used by multiple tasks and
   benefit from standardisation:

   o  Channel is used to specify the details of an endpoint for Control
      or Reporting Task communications and is detailed elsewhere in this
      document.  The common option name for specifying the channel is
      "channel".

NEW

   The ma-option-obj is used to define Task Configuration Options.  Task
   Configuration Options are generally task specific.  For tasks
   associated with an entry in a registry, the registry may define well-
   known option names (e.g., the so-called parameters in the IPPM metric
   registry [I-D.ietf-ippm-metric-registry]).  Control and Reporting
   Tasks need to know the Channel they are going to use.  The common
   option name for specifying the channel is "channel" where the
   option's value refers to the name of an ma-channel-obj.

My intention was to explain more clearly that some of the option names
fall out of registries (e.g., the IPPM metric registry). I kept the
definition of the well-known "channel" option name and I clarified
that the value of this well-known option refers to the name of an
ma-channel-obj.

Personally, I would have preferred if we would not hard code any
option names in the information model. I would rather have a simple
LMAP task registry for (non-measurement) tasks that defines task
specific parameters or options. This would give us the flexibility to
define common non-measurement task options when we need them. But for
the sake of wrapping this document up in a timely manner, I am willing
to go along with the proposed text.

That all said, I personally find the IPPM metry registry somewhat
difficult to work with. I could envision an approach where we
complement the IPPM metric registry with an LMAP task registry that
simply defines LMAP tasks, their functionality, and their well-known
options. For measurement tasks, this LMAP task registry would refer to
the IPPM metric registry which has all the details for the differnet
IPPM metrics. For non-measurement tasks, the LMAP task registry would
provide the information necessary to use them in an interoperable
manner, such as the channel name or the flag whether empty reports
should be suppressed for report tasks. In essence, such an LMAP task
registry would consist of

  - a URI
  - a short description
  - an optional reference to a metric registry
  - a list of well-known option names, each with a short description

and this would give us a well-known URI for identifying lets say an
LMAP reporting task that has well-known options and we would not need
to hard-code anything in the information model.

/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: Fri, 12 Aug 2016 19:21:48 +0000

Juergen,

The text seems fine to me.

As to the LMAP registry, I know in the BBF we also plan to have a registry as well for some of the BBF specific tests and metrics. However we didn't think we should "wrapper" or "reference" the IPPM registry entries as they were suppose to be used directly in LMAP. I'm not sure why you would think that would be needed?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, August 12, 2016 6:09 AM
To: [email-masked]
Subject: [lmap] well known channel names

Hi,

OLD

NEW

My intention was to explain more clearly that some of the option names fall out of registries (e.g., the IPPM metric registry). I kept the definition of the well-known "channel" option name and I clarified that the value of this well-known option refers to the name of an ma-channel-obj.

Personally, I would have preferred if we would not hard code any option names in the information model. I would rather have a simple LMAP task registry for (non-measurement) tasks that defines task specific parameters or options. This would give us the flexibility to define common non-measurement task options when we need them. But for the sake of wrapping this document up in a timely manner, I am willing to go along with the proposed text.

That all said, I personally find the IPPM metry registry somewhat difficult to work with. I could envision an approach where we complement the IPPM metric registry with an LMAP task registry that simply defines LMAP tasks, their functionality, and their well-known options. For measurement tasks, this LMAP task registry would refer to the IPPM metric registry which has all the details for the differnet IPPM metrics. For non-measurement tasks, the LMAP task registry would provide the information necessary to use them in an interoperable manner, such as the channel name or the flag whether empty reports should be suppressed for report tasks. In essence, such an LMAP task registry would consist of

  - a URI
  - a short description

and this would give us a well-known URI for identifying lets say an LMAP reporting task that has well-known options and we would not need to hard-code anything in the information model.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Aug 2016 07:26:27 +0000

OK with me as well. 

Dan

(as contributor)

> From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy
> (Nokia - US)
> Sent: Friday, August 12, 2016 10:22 PM
> To: Juergen Schoenwaelder; [email-masked]
> Subject: Re: [lmap] well known channel names
> 
> Juergen,
> 
> As to the LMAP registry, I know in the BBF we also plan to have a registry as
> well for some of the BBF specific tests and metrics. However we didn't think
> we should "wrapper" or "reference" the IPPM registry entries as they were
> suppose to be used directly in LMAP. I'm not sure why you would think that
> would be needed?
> 
> BR,
> Tim
> 
> My intention was to explain more clearly that some of the option names fall
> out of registries (e.g., the IPPM metric registry). I kept the definition of the
> well-known "channel" option name and I clarified that the value of this well-
> known option refers to the name of an ma-channel-obj.
> 
> Personally, I would have preferred if we would not hard code any option
> names in the information model. I would rather have a simple LMAP task
> registry for (non-measurement) tasks that defines task specific parameters
> or options. This would give us the flexibility to define common non-
> measurement task options when we need them. But for the sake of
> wrapping this document up in a timely manner, I am willing to go along with
> the proposed text.
> 
> That all said, I personally find the IPPM metry registry somewhat difficult to
> work with. I could envision an approach where we complement the IPPM
> metric registry with an LMAP task registry that simply defines LMAP tasks,
> their functionality, and their well-known options. For measurement tasks,
> this LMAP task registry would refer to the IPPM metric registry which has all
> the details for the differnet IPPM metrics. For non-measurement tasks, the
> LMAP task registry would provide the information necessary to use them in
> an interoperable manner, such as the channel name or the flag whether
> empty reports should be suppressed for report tasks. In essence, such an
> LMAP task registry would consist of
> 
>   - a URI
>   - a short description
> and this would give us a well-known URI for identifying lets say an LMAP
> reporting task that has well-known options and we would not need to hard-
> code anything in the information model.
> 
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Aug 2016 14:53:59 +0200

Tim,

I arrived at this conclusion because of two observations:

(a) LMAP has tasks that are not measurement tasks (like a reporting
    task) that will benefit of having some knowledge about common
    options; the metric registry does not apply to these
    non-measurement tasks (unless we start introducing pseudo
    metrics).

(b) We have been struggling with the question to what extend the IPPM
    metric registry is expected to drive automation (e.g, does the
    IPPM registry define LMAP option names and how parameters are
    encoded as LMAP option values).

If there would be an LMAP task registry, then the IPPM registry could
focus on the abstract definition of metrics while the LMAP task
registry would provide the binding to LMAP tasks, that is, how
concrete tasks name use options etc to control the parameters defined
in IPPM metrics. The LMAP task metric would likely be read by tools
while the IPPM metric would likely be read by code developers. For me,
this started to look like a rather natural split of concerns.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Aug 2016 00:57:51 +0000

Juergen,

Indeed in the BBF we are thinking about the same thing (having own own registry) for non-measurement related tasks and diagnostic tasks that are not strictly associated with a metric (e.g., HTTP Upload).
These should be new charter items IMHO.

I did think though IPPM would define the metrics sufficient enough that they would be self describing in that that they can be used directly as LMAP actions (including the actual test ala ICMP Ping) to run.

Looking at ietf-ippm-initial-registry (at least the first one in section 4) why do you think this is insufficient? 

I would like to hear Al's thoughts if he believes another registry is necessary for implementing IPPM entries as testable tasks.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 7:54 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] well known channel names

Tim,

If there would be an LMAP task registry, then the IPPM registry could focus on the abstract definition of metrics while the LMAP task registry would provide the binding to LMAP tasks, that is, how concrete tasks name use options etc to control the parameters defined in IPPM metrics. The LMAP task metric would likely be read by tools while the IPPM metric would likely be read by code developers. For me, this started to look like a rather natural split of concerns.

/js

On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Aug 2016 09:04:51 -0400

One point that has come up in IPPM discussion:

The Fixed and Run Tine Parameters in the registry all have names,
but we may need to form a sub-registry to ensure that the names
are used consistently (among different registry entries, and in their
interpretation by other operations, e.g., as options in LMAP).

IPPM agreed to continue with the IANA early review, and
determine the efficacy of the parameter sub-registry in those
conversations (on-going).

Otherwise, I would like to hear what else is necessary
(The IPPM RFCs and Metric entries are not abstract, IMO).

regards,
Al

> From: Carey, Timothy (Nokia - US) [mailto:[email-masked]]
> Sent: Sunday, August 21, 2016 8:58 PM
> To: Juergen Schoenwaelder
> Cc: [email-masked]; MORTON, ALFRED C (AL)
> Subject: RE: [lmap] well known channel names
> 
> Juergen,
> 
> Indeed in the BBF we are thinking about the same thing (having own own
> registry) for non-measurement related tasks and diagnostic tasks that
> are not strictly associated with a metric (e.g., HTTP Upload).
> I did think though IPPM would define the metrics sufficient enough that
> they would be self describing in that that they can be used directly as
> LMAP actions (including the actual test ala ICMP Ping) to run.
> 
> Looking at ietf-ippm-initial-registry (at least the first one in section
> 4) why do you think this is insufficient?
> 
> I would like to hear Al's thoughts if he believes another registry is
> necessary for implementing IPPM entries as testable tasks.
> 
> BR,
> Tim
> 
> focus on the abstract definition of metrics while the LMAP task registry
> would provide the binding to LMAP tasks, that is, how concrete tasks
> name use options etc to control the parameters defined in IPPM metrics.
> The LMAP task metric would likely be read by tools while the IPPM metric
> would likely be read by code developers. For me, this started to look
> like a rather natural split of concerns.
> 
> /js
> 
> > As to the LMAP registry, I know in the BBF we also plan to have a
> registry as well for some of the BBF specific tests and metrics. However
> we didn't think we should "wrapper" or "reference" the IPPM registry
> entries as they were suppose to be used directly in LMAP. I'm not sure
> why you would think that would be needed?
> >
> > BR,
> > Tim
> >
> definition of the well-known "channel" option name and I clarified that
> the value of this well-known option refers to the name of an ma-channel-
> obj.
> >
> option names in the information model. I would rather have a simple LMAP
> task registry for (non-measurement) tasks that defines task specific
> parameters or options. This would give us the flexibility to define
> common non-measurement task options when we need them. But for the sake
> of wrapping this document up in a timely manner, I am willing to go
> along with the proposed text.
> >
> LMAP reporting task that has well-known options and we would not need to
> hard-code anything in the information model.
> >
> > /js
> >
> > --

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Aug 2016 14:47:15 +0000

Al,

I will say that when I looked at the first registry entry is was difficult for me to understand what the actual test (ICMP ping, UDP Echoplus) that was to be run for the action.

BR,
Tim

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 8:05 AM
To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] well known channel names

The Fixed and Run Tine Parameters in the registry all have names, but we may need to form a sub-registry to ensure that the names are used consistently (among different registry entries, and in their interpretation by other operations, e.g., as options in LMAP).

IPPM agreed to continue with the IANA early review, and determine the efficacy of the parameter sub-registry in those conversations (on-going).

Otherwise, I would like to hear what else is necessary (The IPPM RFCs and Metric entries are not abstract, IMO).

regards,
Al

> I did think though IPPM would define the metrics sufficient enough 
> that they would be self describing in that that they can be used 
> directly as LMAP actions (including the actual test ala ICMP Ping) to run.
> 
> concrete tasks name use options etc to control the parameters defined in IPPM metrics.
> The LMAP task metric would likely be read by tools while the IPPM 
> metric would likely be read by code developers. For me, this started 
> to look like a rather natural split of concerns.
> 
> /js
> 
> registry as well for some of the BBF specific tests and metrics. 
> However we didn't think we should "wrapper" or "reference" the IPPM 
> registry entries as they were suppose to be used directly in LMAP. I'm 
> not sure why you would think that would be needed?
> >
> > BR,
> > Tim
> >
> ma-channel- obj.
> > options. For measurement tasks, this LMAP task registry would refer 
> > to the IPPM metric registry which has all the details for the 
> > differnet IPPM metrics. For non-measurement tasks, the LMAP task 
> > registry would provide the information necessary to use them in an 
> > interoperable manner, such as the channel name or the flag whether 
> > empty reports should be suppressed for report tasks. In essence, 
> > such an LMAP task registry would consist of
> >
> >   - a URI
> >   - a short description

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Aug 2016 11:40:09 -0400

Hi Tim,
Maybe we can improve the Description, to mention UDP or other deatils?
https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#section-4.1.4

Al

> Sent: Monday, August 22, 2016 10:47 AM
> To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
> Cc: [email-masked]
> I will say that when I looked at the first registry entry is was
> difficult for me to understand what the actual test (ICMP ping, UDP
> Echoplus) that was to be run for the action.
> 
> BR,
> Tim
> 
> The Fixed and Run Tine Parameters in the registry all have names, but we
> may need to form a sub-registry to ensure that the names are used
> consistently (among different registry entries, and in their
> IPPM agreed to continue with the IANA early review, and determine the
> efficacy of the parameter sub-registry in those conversations (on-
> going).
> 
> Otherwise, I would like to hear what else is necessary (The IPPM RFCs
> and Metric entries are not abstract, IMO).
> 
> regards,
> Al
> 
> in IPPM metrics.

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Aug 2016 15:46:43 +0000

Al,

I thought it would be in the method of measurement section.
RFC 2681 doesn't explicitly call out the test that I could easily find although it does say you can use ping.

If we are explicit in the test actual test to run for the metric in the method (or description) - I can then run that test with the inputs and outputs for the assigned role.

BR,
Tim

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 10:40 AM
To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] well known channel names

Hi Tim,

Al

> The Fixed and Run Tine Parameters in the registry all have names, but 
> we may need to form a sub-registry to ensure that the names are used 
> > registry) for non-measurement related tasks and diagnostic tasks 
> > that are not strictly associated with a metric (e.g., HTTP Upload).
> > directly as LMAP actions (including the actual test ala ICMP Ping) 
> > to
> run.
> >
> > I would like to hear Al's thoughts if he believes another registry 
> > is necessary for implementing IPPM entries as testable tasks.
> >
> > BR,
> > Tim
> >
> > If there would be an LMAP task registry, then the IPPM registry 
> > could focus on the abstract definition of metrics while the LMAP 
> > task registry would provide the binding to LMAP tasks, that is, how 
> > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - 
> > US)
> > wrote:
> > > Juergen,
> > >
> > registry entries as they were suppose to be used directly in LMAP. 
> > I'm not sure why you would think that would be needed?
> > >
> > > BR,
> > > Tim
> > >
> > >       or Reporting Task communications and is detailed elsewhere 
> > > in
> > this
> > specific parameters or options. This would give us the flexibility 
> > to define common non-measurement task options when we need them. But 
> > for the sake of wrapping this document up in a timely manner, I am 
> > willing to go along with the proposed text.
> > >
> > > complement the IPPM metric registry with an LMAP task registry 
> > > that simply defines LMAP tasks, their functionality, and their 
> > > well-known options. For measurement tasks, this LMAP task registry 
> > > would refer to the IPPM metric registry which has all the details 
> > > for the differnet IPPM metrics. For non-measurement tasks, the 
> > > LMAP task registry would provide the information necessary to use 
> > > them in an interoperable manner, such as the channel name or the 
> > > flag whether empty reports should be suppressed for report tasks. 
> > > In essence, such an LMAP task registry would consist of
> > >
> > >   - a URI
> > >   - a short description
> > LMAP reporting task that has well-known options and we would not 
> > need to hard-code anything in the information model.
> > >
> > > /js
> > >
> > > --

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Aug 2016 11:57:52 -0400

Hi Tim,
When you say "actual test to run", are you referring to the 
software tool that would perform one role of the test?

When RFC2681 mentions ping, it also reminds the reader 
that the RT delay would be based on ICMP echo request/reply.
This is not the same measurement as the UDP RT Delay would
measure, possibly for the reasons cited in section 2.6:

   {Comment: "ping" would qualify as a round-trip measure under this
   definition, with a Type-P of ICMP echo request/reply with 60-byte
   packets.  However, the uncertainties associated with a typical ping
   program must be analyzed as in the next section, including the type
   of reflecting point (a router may not handle an ICMP request in the
   fast path) and effects of load on the reflecting point.}

Is "test" synonymous with SW tool below?
Al

> Sent: Monday, August 22, 2016 11:47 AM
> If we are explicit in the test actual test to run for the metric in the
> method (or description) - I can then run that test with the inputs and
> outputs for the assigned role.
> 
> BR,
> Tim
>

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Aug 2016 16:45:30 +0000

Al,

I didn't anything referencing "SW tool" in this thread.

Is ICMP ping a SW tool in your mind? That is what I was referring to as a test.  I certainly am not referring to LMAP as the test or SW tool in this thread.

For example in section 7 of the initial registry draft - infers TWAMP is the test used (yes I know it's a protocol). 

I guess I should have said the protocol to use for the actual measurement.... For section 5 PDV what is the protocol to use for the actual measurement? 

BR,
Tim

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 10:58 AM
To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] well known channel names

Hi Tim,
When you say "actual test to run", are you referring to the software tool that would perform one role of the test?

When RFC2681 mentions ping, it also reminds the reader that the RT delay would be based on ICMP echo request/reply.
This is not the same measurement as the UDP RT Delay would measure, possibly for the reasons cited in section 2.6:

> If we are explicit in the test actual test to run for the metric in 
> the method (or description) - I can then run that test with the inputs 
> and outputs for the assigned role.
> 
> BR,
> Tim
> 
> https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#sectio
> n-
> 4.1.4
> 
> Al
> 
> > but we may need to form a sub-registry to ensure that the names are 
> > used consistently (among different registry entries, and in their 
> > IPPM agreed to continue with the IANA early review, and determine 
> > the efficacy of the parameter sub-registry in those conversations 
> > (on- going).
> >
> > Otherwise, I would like to hear what else is necessary (The IPPM 
> > RFCs and Metric entries are not abstract, IMO).
> >
> > regards,
> > Al
> >
> > > task registry would provide the binding to LMAP tasks, that is, 
> > > how concrete tasks name use options etc to control the parameters 
> > > defined
> > in IPPM metrics.
> > > metric would likely be read by code developers. For me, this 
> > > started to look like a rather natural split of concerns.
> > >
> > > /js
> > >
> > > However we didn't think we should "wrapper" or "reference" the 
> > > IPPM registry entries as they were suppose to be used directly in LMAP.
> > > >    tasks to define, some common Options are used by multiple 
> > > > tasks
> > and
> > > >       document.  The common option name for specifying the 
> > > > channel
> > is
> > > >       "channel".
> > > >
> > > > NEW
> > > >
> > > >    associated with an entry in a registry, the registry may 
> > > > define
> > > well-
> > > >    known option names (e.g., the so-called parameters in the 
> > > > IPPM
> > > metric
> > > fall out of registries (e.g., the IPPM metric registry). I kept 
> > > the definition of the well-known "channel" option name and I 
> > > clarified that the value of this well-known option refers to the 
> > > name of an
> > > ma-channel- obj.
> > > >
> > > option names in the information model. I would rather have a 
> > > simple LMAP task registry for (non-measurement) tasks that defines 
> > > task specific parameters or options. This would give us the 
> > > flexibility to define common non-measurement task options when we 
> > > need them. But for the sake of wrapping this document up in a 
> > > timely manner, I am willing to go along with the proposed text.
> > > >
> > > > That all said, I personally find the IPPM metry registry 
> > > > somewhat difficult to work with. I could envision an approach 
> > > > where we complement the IPPM metric registry with an LMAP task 
> > > > registry that simply defines LMAP tasks, their functionality, 
> > > > and their well-known options. For measurement tasks, this LMAP 
> > > > task registry would refer to the IPPM metric registry which has 
> > > > all the details for the differnet IPPM metrics. For 
> > > > non-measurement tasks, the LMAP task registry would provide the 
> > > > information necessary to use them in an interoperable manner, 
> > > > such as the channel name or the flag whether empty reports should be suppressed for report tasks.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Aug 2016 14:42:24 -0400

Hi Tim,

Although ping is synonymous with sending ICMP echo requests,
ping is a SW tool for controlling send/receive/results reporting.
That's not just in my mind, it's in the *nix man pages:
http://www.unix.com/man-page/linux/8/ping/ 

Let me try this as the explanation:

The type of packets used in the measurement are specified in 
the metric registry, so you will see IP/UDP in the entries now.
We have a request to specify an IP/ICMP round trip time metric, TBD.
But the metric registry is currently agnostic to the measurement 
control protocol for arranging measurements between MAs or MA - MP
(the IPPM RFCs for metrics are agnostic too: they existed before
OWAMP and TWAMP).

So, specifying that the measurement is conducted using
TWAMP, IPSLA, netperf, some tool that launches DNS requests, or ping 
is a configuration option/parameter that currently needs to be
communicated in addition to the registry entry.

hope this helps,
Al

> Sent: Monday, August 22, 2016 12:46 PM
> Is ICMP ping a SW tool in your mind? That is what I was referring to as
> a test.  I certainly am not referring to LMAP as the test or SW tool in
> this thread.
> 
> For example in section 7 of the initial registry draft - infers TWAMP is
> the test used (yes I know it's a protocol).
> 
> I guess I should have said the protocol to use for the actual
> measurement.... For section 5 PDV what is the protocol to use for the
> actual measurement?
> 
> BR,
> Tim
> 
> 
> 
> When you say "actual test to run", are you referring to the software
> tool that would perform one role of the test?
> 
> When RFC2681 mentions ping, it also reminds the reader that the RT delay
> would be based on ICMP echo request/reply.
> This is not the same measurement as the UDP RT Delay would measure,
> possibly for the reasons cited in section 2.6:
> 
> > > > >    The ma-option-obj is used to define Task Configuration
> Options.
> > > > Task
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Aug 2016 21:04:13 +0200

> These should be new charter items IMHO.

Exactly, there are LMAP tasks that do not implement a metric and that
likely benefit from agreement on option names etc.

> I would like to hear Al's thoughts if he believes another registry is necessary for implementing IPPM entries as testable tasks.

To be honest, I have trouble with the IPPM registry since it does not
feel like a registry according to my expectations of a registry. ;-)

Lets take section 4 "UDP Round-trip Latency Registry Entry" of
draft-ietf-ippm-initial-registry-01 as an example:

- This entry is ~8 pages of RFC text primarily targeting a human
  implementing the metric (and I note that the entry text is still
  incomplete). Why publish a specification of this size via IANA?

- I still fail to see the need for N different identifiers (name, ID,
  URI, URL) [but this is really a very minor issue - I could get over
  it but since you asked...

- It is still not clear what are option names and what are option
  values. Perhaps the idea is that runtime parameter names (such as
  'Reciprocal_lambda') are LMAP option names but then I hardly know
  tools that use these kind of option names (perhaps my fault but in
  the world I am living in --reciprocal-lambda would be more common
  than Reciprocal_lambda).

- The output data format description leaves me puzzled how data is
  encoded (Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile does
  not resolve to anything I can find in the document, likely a bug).

Initially, the IPPM registry did not include a textual serialization
of parameter values etc. Looking back, perhaps this was the right
approach and we would overall benefit from separating the
specification of metrics from the syntactic aspects of LMAP option
names etc.

For LMAP, I think we want a registry that is encoded in a format that
is ready to drive tools (please recall the discussion we had to what
extend the IPPM metric registry entry should be machine readable).
This is another indicator for me that we would likely be better off
separating concerns by having an IPPM metric registry focussed on
_defining metrics_ and a separate LMAP task registry _defining LMAP
tasks_. These two things are related but simply not the same.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Aug 2016 19:08:24 +0000

Al,

Yes - but where is this configuration option normatively specified if not IPPM?

I am looking at this from the standpoint of a MA implementation. When I say my MA has these Task capabilities (including registry entry and roles) for the Task. That capability needs to include "tool(s)" used to implement metric.  This is necessary for a controller to adequately configure the endpoints.

Maybe this is what Juergen meant by what is missing.  If so then yes indeed the LMAP registry entry is needed for instructions as well as housekeeping tasks and the IPPM registry would NOT be directly referenced by LMAP agents - Juergen?

BR,
Tim

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 1:42 PM
To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] well known channel names

Hi Tim,

Although ping is synonymous with sending ICMP echo requests, ping is a SW tool for controlling send/receive/results reporting.
That's not just in my mind, it's in the *nix man pages:
http://www.unix.com/man-page/linux/8/ping/ 

The type of packets used in the measurement are specified in the metric registry, so you will see IP/UDP in the entries now.
We have a request to specify an IP/ICMP round trip time metric, TBD.
But the metric registry is currently agnostic to the measurement control protocol for arranging measurements between MAs or MA - MP (the IPPM RFCs for metrics are agnostic too: they existed before OWAMP and TWAMP).

So, specifying that the measurement is conducted using TWAMP, IPSLA, netperf, some tool that launches DNS requests, or ping is a configuration option/parameter that currently needs to be communicated in addition to the registry entry.

hope this helps,
Al

> Is ICMP ping a SW tool in your mind? That is what I was referring to 
> as a test.  I certainly am not referring to LMAP as the test or SW 
> tool in this thread.
> 
> For example in section 7 of the initial registry draft - infers TWAMP 
> is the test used (yes I know it's a protocol).
> 
> When RFC2681 mentions ping, it also reminds the reader that the RT 
> delay would be based on ICMP echo request/reply.
> > RFC 2681 doesn't explicitly call out the test that I could easily 
> > find although it does say you can use ping.
> >
> > the method (or description) - I can then run that test with the 
> > inputs and outputs for the assigned role.
> >
> > BR,
> > Tim
> >
> > > are used consistently (among different registry entries, and in 
> > > their interpretation by other operations, e.g., as options in LMAP).
> > >
> > > > I did think though IPPM would define the metrics sufficient 
> > > > enough that they would be self describing in that that they can 
> > > > be used directly as LMAP actions (including the actual test ala 
> > > > ICMP Ping) to
> > > run.
> > > >
> > > > I would like to hear Al's thoughts if he believes another 
> > > > registry is necessary for implementing IPPM entries as testable tasks.
> > > >
> > > > BR,
> > > > Tim
> > > >
> > > > how concrete tasks name use options etc to control the 
> > > > parameters defined
> > > in IPPM metrics.
> > > > The LMAP task metric would likely be read by tools while the 
> > > > IPPM metric would likely be read by code developers. For me, 
> > > > IPPM registry entries as they were suppose to be used directly 
> > > > in
> LMAP.
> > > > >    o  Channel is used to specify the details of an endpoint 
> > > > > for
> > > > Control
> > > > >       or Reporting Task communications and is detailed 
> > > > > elsewhere in
> > > > this
> > > > simple LMAP task registry for (non-measurement) tasks that 
> > > > defines task specific parameters or options. This would give us 
> > > > the flexibility to define common non-measurement task options 
> > > > when we need them. But for the sake of wrapping this document up 
> > > > in a timely manner, I am willing to go along with the proposed text.
> > > > >
> > > > > task registry would refer to the IPPM metric registry which 
> > > > > has all the details for the differnet IPPM metrics. For 
> > > > > non-measurement tasks, the LMAP task registry would provide 
> > > > > the information necessary to use them in an interoperable 
> should be suppressed for report tasks.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 22 Aug 2016 15:20:59 -0400

The metric Registry identifies *what* will be measured,
and LMAP still needs to communicate the set of metrics
that any tool/measurement system will measure and report.

Most measurement tools can make lots of different measurements,
with different size packets, different measurement durations, etc.
The Metric registry entries narrow the choices for *any* measurement
tool (compliant with the method of measurement in the entry),
and specify how the results will be reported.

I'm saying we need LMAP to communicate the set of metrics
and the method (assuming the MA has more than one, and that
may not be universally applicable, some MAs may have exactly
one system/protocol to conduct measurements).

Al

> Sent: Monday, August 22, 2016 3:08 PM
> I am looking at this from the standpoint of a MA implementation. When I
> say my MA has these Task capabilities (including registry entry and
> roles) for the Task. That capability needs to include "tool(s)" used to
> implement metric.  This is necessary for a controller to adequately
> configure the endpoints.
>
> Maybe this is what Juergen meant by what is missing.  If so then yes
> indeed the LMAP registry entry is needed for instructions as well as
> housekeeping tasks and the IPPM registry would NOT be directly
> referenced by LMAP agents - Juergen?
>
> BR,
> Tim
>
> Although ping is synonymous with sending ICMP echo requests, ping is a
> SW tool for controlling send/receive/results reporting.
> The type of packets used in the measurement are specified in the metric
> registry, so you will see IP/UDP in the entries now.
> But the metric registry is currently agnostic to the measurement control
> protocol for arranging measurements between MAs or MA - MP (the IPPM
> RFCs for metrics are agnostic too: they existed before OWAMP and TWAMP).
>
> So, specifying that the measurement is conducted using TWAMP, IPSLA,
> netperf, some tool that launches DNS requests, or ping is a
> configuration option/parameter that currently needs to be communicated
> in addition to the registry entry.
>
> hope this helps,
> Al
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Aug 2016 21:20:55 +0200

> Maybe this is what Juergen meant by what is missing.  If so then yes indeed the LMAP registry entry is needed for instructions as well as housekeeping tasks and the IPPM registry would NOT be direc…

I believe it is simpler to separate concerns.

a) IPPM cares about precise definitions of metrics. This is
   goodness. Their primary target are humans, not tools.

b) LMAP is concernd about tasks, their options, etc. LMAP prefers to
   have machine readable information that can drive tools.

Merging both aspects into a single registry may be feasible in theory,
but it seems difficult in practice. And we would end up with corner
cases like LMAP tasks that are not implementing metrics (unless we
start creating ugly pseudo IPPM metrics since all we have is a single
registry).

/js