Subject: Re: [ippm] metric registry data formats

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 2 Oct 2015 12:14:30 -0400

Hi Juergen and Barbara,

Let's try keep this thread on data formats, though I suppose the 
machine-parse-able considerations are related.

When I wrote the examples with standard data formats, with
binary representations in many cases, I was considering these factors:

* the IETF IPPM protocols that (could) perform the measurements use
  the binary values 
* the standard/binary representations convey many aspects of the 
  format with exactness == the units, the numerical resolution, etc.
* we have a "Large Scale" system to consider in LMAP, so many
  lightweight MAs and their associated measurement systems should 
  be considered, in terms of control/reporting BW and data conversion load.

Perhaps there is a way to accommodate both binary and XML/JSON encoding.

Would it be too clumsy to define 2 or more format categories in the registry entries,
and add a Run-time parameter to designate which of the categories will
be used?  We would still lean on the binary formats for units and resolution
and require equivalent representation in the alternate formats.

If we go this way, It would help if folks suggest the XML/JSON formats 
they would like to use.

It strikes me as a bit funny that even where we specified binary formats,
folks want a different machine parse-able form instead.

regards,
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: Wednesday, September 30, 2015 10:15 AM
> To: Juergen Schoenwaelder; [email-masked]
> Subject: Re: [ippm] metric registry data formats
> 
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more
> information.
> 
> > the metrics registry seems to mandate data encoding. For example,
> > entries say that an IPv4 address is a 32 bit unsigned integer or that
> > a timestampe is to be represented as a specific NTP encoding. The
> > general assumption here seems to be that metric parameters (and
> > outputs) are encoded in binary formats. Given that LMAP intends to use
> > the metrics registry with protocols that use XML or JSON as their
> > encoding, it seems kind of odd to represent parameters in binary
> > (which essentially leads to base64 encoded values).
> >
> > My proposal would be that the metrics registry entries instead define
> > clearly what the parameters are and what the precision requirements
> > are but that they leave the encoding details to users of the registry.
> > I would also be fine if there are specific suggestions, e.g., for use
> > with YANG, the IP address parameters are represented as an ip-address
> > as defined in RFC 6991. Or anything in between is fine - I just would
> > dislike to configure parameters in binary base64 encoded values.
> 
> I agree with Juergen that the data format (encoding) of run-time
> parameters does not need to be specified.
> My expectation of the registry entries for the Run-time Parameters
> column would be that the parameters listed use precisely the names of
> parameters from the referenced specification (which is what the example
> from
> https://www.ietf.org/proceedings/interim/2015/09/29/lmap/slides/slides-
> interim-2015-lmap-3-1.pdf mostly did). What's not clear to me is how
> these parameter names are delimited in the registry. In order for them
> to be machine parsable (which would be great), I really need to
> understand how they are delimited in the registry entry. I would think
> comma delimited would be good, with quotes around the names?
> "Src", "Dst", "T0", "Tf", "upper bound" [note that the upper bound,
> which the example has as "Upper limit on Poisson distribution" is
> problematic because the reference (RFC2681) only loosely describes this
> concept and does not list it as a parameter]
> 
> I'm even more concerned with the format of registry entries that would
> be very useful if they were machine-parsable, such as Fixed Parameters.
> The example of fixed parameters that was on slide 9 of
> https://www.ietf.org/proceedings/interim/2015/09/29/lmap/slides/slides-
> interim-2015-lmap-3-1.pdf is very unparsable. Something like
> "IPv4.dscp"="0", "IPv4.ttl"="255", "IPv4.protocol"="17", "Tmax"="3
> seconds", "payload.length"="16 octets"
> [I was going to put the other elements listed as fixed parameters on
> that slide, but got really confused as to how a locally generated (at
> run-time?) checksum, sequence number, and timestamp were "fixed"
> parameters -- really what these seem to be are attempts to specify
> unspecified portions of the reference that hint at the need to include
> timestamp and sequence number in the payload, which is awkward.] But
> something like this means there would need to be a list of these sorts
> of fixed parameter names and how to express them. I would be tempted to
> use something like Wireshark names for protocol components.
> Barbara
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Oct 2015 09:33:50 +0200

Hi,

I am a bit confused about this comment and the follow up discussion.

Are you guys talking about draft-ietf-ippm-metric-registry-04 or about 
draft-morton-ippm-initial-registry-00?

The registry is defined in draft-ietf-ippm-metric-registry-04 and afaict 
it does not define any data encoding, does it?

If this is the case, then i think the registry definition already 
fullfills what Juergen and Barbara are asking for?

Now, draft-morton-ippm-initial-registry-00 does defines the data format 
for the different parameters. I think we have a few options here.
- either each registry entry defines the data format (not required nor 
prevented by the current registry format document), which would imply 
that two metrics with everything the same except for the data format 
would be two different entries in the registry. This may be reasonable, 
since if what we want is to guarantee interoperability, the data format 
used by the MA and the cotnroller must be the same and using two 
different formats should result in different entries.
- either the registry entries do not define any format and it is up to 
the involved parties to make sure they use the same format, which is 
allowed by the current registry format.
- either to add the fixed parameter Al was suggesting describing the 
format used in thei particular entry. This again is supported by the 
registry.

So, in terms of the registry document i.e. 
draft-ietf-ippm-metric-registry i understand we have a few options:

- leave it as it is, as it seems to support all the considered options
- include some guidelines about how to handle this particular issue, or 
at least describing the 3 options above to handle it
- mandate an encoding

I wouldnt go for the last option.
I am fine with either of the first two.

Opinions?

regards, marcelo

El 30/09/15 a las 12:27, Juergen Schoenwaelder escribió:
> Hi,
> /js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 15 Oct 2015 20:06:52 -0400

Hi Marcelo,

All the data format comments were precipitated by a review of 
draft-morton-ippm-initial-registry-00, which provided the 
examples of the registry entries Juergen sought.  I was very 
happy to get some review of draft-morton-ippm-initial-registry-00.
All our descriptions are a bit abstract until we provide some
examples (we had some examples in our first version of the registry,
but now that's almost 3 years ago).  It was equally revealing to
see some example attempts to populate the LMAP Information Model,
so we had a rather productive LMAP interim meeting, all in all.

> I am fine with either of the first two.

I agree to avoid a mandated encoding, but I think this is an
area of potential incompatibility, therefore:

In the registry Draft:
* I'm in favor of providing guidelines, particularly describing the
two formats which have been suggested: Binary and something compatible 
with YANG. If both are present, we could make the units and resolution 
equivalent.

* If others agree it is useful to provide both, then we provide a 
Fixed parameter to select a format, with a binary format and a 
format and a YANG/human-readable format, plus 3rd possibility to indicate
a locally-agreed format not mentioned in the registry entry?

that's where I end-up,
Al

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Monday, October 12, 2015 3:34 AM
> To: [email-masked]; MORTON, ALFRED C (AL); Juergen Schoenwaelder

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 16 Oct 2015 08:51:39 +0200

Hi Al,

Basically you are suggesting to include a fixed parameter that is the 
data encoding for all input parameters and probably for all outputs, is 
that so?

Regards, marcelo

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 16 Oct 2015 07:36:34 -0400

I did, but now I see that this needs to be a *Run-time*
parameter, of course! (this was the last message I sent last 
night, sorry).

It is a way to cover the most popular choice of output,
without expanding the registry with an entry for each format.

Al

> Sent: Friday, October 16, 2015 2:52 AM
> To: MORTON, ALFRED C (AL); marcelo bagnulo braun; [email-masked]; Juergen
> Schoenwaelder
> > draft-morton-ippm-initial-registry-00, which provided the examples of
> > the registry entries Juergen sought.  I was very happy to get some
> > review of draft-morton-ippm-initial-registry-00.
> > All our descriptions are a bit abstract until we provide some examples
> > (we had some examples in our first version of the registry, but now
> > that's almost 3 years ago).  It was equally revealing to see some
> > example attempts to populate the LMAP Information Model, so we had a
> > rather productive LMAP interim meeting, all in all.
> >
> > you wrote:
> >> - include some guidelines about how to handle this particular issue,
> >> or at least describing the 3 options above to handle it
> >> - mandate an encoding
> >>
> > I agree to avoid a mandated encoding, but I think this is an area of
> > potential incompatibility, therefore:
> >
> > In the registry Draft:
> > Fixed parameter to select a format, with a binary format and a format
> > and a YANG/human-readable format, plus 3rd possibility to indicate a
> > locally-agreed format not mentioned in the registry entry?
> >
> > that's where I end-up,
> > Al
> >
> >> Are you guys talking about draft-ietf-ippm-metric-registry-04 or
> >> about draft-morton-ippm-initial-registry-00?
> >>
> >> The registry is defined in draft-ietf-ippm-metric-registry-04 and
> >> afaict it does not define any data encoding, does it?
> >>
> >> Now, draft-morton-ippm-initial-registry-00 does defines the data
> >> format for the different parameters. I think we have a few options
> here.
> >> - either each registry entry defines the data format (not required
> >> nor prevented by the current registry format document), which would
> >> imply that two metrics with everything the same except for the data
> >> format would be two different entries in the registry. This may be
> >> reasonable, since if what we want is to guarantee interoperability,
> >> the data format used by the MA and the cotnroller must be the same
> >> and using two different formats should result in different entries.
> >> - either the registry entries do not define any format and it is up
> >> to the involved parties to make sure they use the same format, which
> >> is allowed by the current registry format.
> >> - include some guidelines about how to handle this particular issue,
> >> or at least describing the 3 options above to handle it
> >> - mandate an encoding
> >>
> >>> entries say that an IPv4 address is a 32 bit unsigned integer or
> >>> that a timestampe is to be represented as a specific NTP encoding.
> >>> The general assumption here seems to be that metric parameters (and
> >>> outputs) are encoded in binary formats. Given that LMAP intends to
> >>> use the metrics registry with protocols that use XML or JSON as
> >>> their encoding, it seems kind of odd to represent parameters in
> >>> binary (which essentially leads to base64 encoded values).
> >>>
> >>> My proposal would be that the metrics registry entries instead
> >>> define clearly what the parameters are and what the precision
> >>> requirements are but that they leave the encoding details to users
> of the registry.
> >>> I would also be fine if there are specific suggestions, e.g., for
> >>> use with YANG, the IP address parameters are represented as an
> >>> ip-address as defined in RFC 6991. Or anything in between is fine -
> >>> I just would dislike to configure parameters in binary base64
> encoded values.
> >>>
> >>> /js
> >>>
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Oct 2015 09:01:52 +0200

I was thinking about this a little more and i was wondering if it 
wouldnt be better to say something like this:

Parameters MUST have a well defined data encoding for their values. For 
example, parameters that include an IPv4 address can be encoded as a 32 
bit integer (i.e. binary base64 encoded value) or ip-address as defined 
in RFC 6991. The actual encoding(s) used should be explicitly defined 
for each Run-time parameter.

(the motivation is that the encoding may be specific to the specific 
parameter, so a single encoding parameter to define the encoding of all 
parameters wouldnt work, i think)

I am wondering if we should say the same thing for outputs, i think we 
should, no?

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 17 Oct 2015 08:28:17 -0400

Hi Marcelo,

Yes, that's exactly right, Outputs MUST have well-defined encoding for
their values. That's what I did in the registry contents draft.

The mission here is to be specific, and avoid ambiguity.
thanks,
Al

> Sent: Saturday, October 17, 2015 3:02 AM
> examples
> format