Re: [lmap] well known channel names

["Carey, Timothy (Nokia - US)" <[e-mail]>]

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:[e-mail]] 
Sent: Monday, August 22, 2016 1:42 PM
To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
Cc: [e-mail]
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/ 

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

> -----Original Message-----
> From: lmap [mailto:[e-mail]] On Behalf Of Carey, Timothy 
> (Nokia - US)
> Sent: Monday, August 22, 2016 12:46 PM
> To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
> Cc: [e-mail]
> Subject: Re: [lmap] well known channel names
> 
> 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:[e-mail]]
> Sent: Monday, August 22, 2016 10:58 AM
> To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
> Cc: [e-mail]
> 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:
> 
>    {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
> 
> > -----Original Message-----
> > From: Carey, Timothy (Nokia - US) [mailto:[e-mail]]
> > Sent: Monday, August 22, 2016 11:47 AM
> > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
> > Cc: [e-mail]
> > Subject: RE: [lmap] well known channel names
> >
> > 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:[e-mail]]
> > Sent: Monday, August 22, 2016 10:40 AM
> > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
> > Cc: [e-mail]
> > Subject: RE: [lmap] well known channel names
> >
> > 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#sect
> > io
> > n-
> > 4.1.4
> >
> > Al
> >
> > > -----Original Message-----
> > > From: Carey, Timothy (Nokia - US) [mailto:[e-mail]]
> > > Sent: Monday, August 22, 2016 10:47 AM
> > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
> > > Cc: [e-mail]
> > > Subject: RE: [lmap] well known channel names
> > >
> > > 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:[e-mail]]
> > > Sent: Monday, August 22, 2016 8:05 AM
> > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder
> > > Cc: [e-mail]
> > > Subject: RE: [lmap] well known channel names
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: Carey, Timothy (Nokia - US) 
> > > > [mailto:[e-mail]]
> > > > Sent: Sunday, August 21, 2016 8:58 PM
> > > > To: Juergen Schoenwaelder
> > > > Cc: [e-mail]; 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).
> > > > 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:j.schoenwaelder@jacobs- 
> > > > university.de]
> > > > Sent: Monday, August 15, 2016 7:54 AM
> > > > To: Carey, Timothy (Nokia - US)
> > > > Cc: [e-mail]
> > > > Subject: Re: [lmap] well known channel names
> > > >
> > > > 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
> > > >
> > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia 
> > > > -
> > > > US)
> > > > wrote:
> > > > > 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:[e-mail]]
> > > > > Sent: Friday, August 12, 2016 6:09 AM
> > > > > To: [e-mail]
> > > > > Subject: [lmap] well known channel names
> > > > >
> > > > > 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: [phone]         Campus Ring 1 | 28759 Bremen |
> > > Germany
> > > > > Fax:   [phone]         <http://www.jacobs-
> university.de/>
> > > > >
> > > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > > Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> > Germany
> > > > Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap