Re: [lmap] well known channel names

["MORTON, ALFRED C (AL)" <[e-mail]>]

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#sectio
> > 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