Subject: [ippm] Fwd: New Version Notification for draft-spiegel-ippm-ioam-rawexport-00.txt

From: Mickey Spiegel <[email-masked]>
Date: Mon, 25 Jun 2018 11:35:32 -0700

Please find below links to a draft on raw export of IOAM data to monitoring
and analytics systems using IPFIX. This is meant to complement the ongoing
IPPM work on IOAM in the data plane.

Suggestions and comments would be much appreciated.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 19, 2018 at 2:39 AM
Subject: New Version Notification for
draft-spiegel-ippm-ioam-rawexport-00.txt
To: Frank Brockners <[email-masked]>, Shwetha Bhandari <
[email-masked]>, Mickey Spiegel <[email-masked]>, Ramesh
Sivakolundu <[email-masked]>

A new version of I-D, draft-spiegel-ippm-ioam-rawexport-00.txt
has been successfully submitted by Mickey Spiegel and posted to the
IETF repository.

Name:           draft-spiegel-ippm-ioam-rawexport
Revision:       00
Title:          In-situ OAM raw data export with IPFIX
Document date:  2018-03-19
Group:          Individual Submission
Pages:          19
URL:            https://www.ietf.org/internet-drafts/draft-spiegel-ippm-
ioam-rawexport-00.txt
Status:         https://datatracker.ietf.org/doc/draft-spiegel-ippm-ioam-
rawexport/
Htmlized:       https://tools.ietf.org/html/draft-spiegel-ippm-ioam-
rawexport-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-
ioam-rawexport

Abstract:
   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.  This document
   discusses how In-situ Operations, Administration, and Maintenance
   (IOAM) information can be exported in raw, i.e. uninterpreted, format
   from network devices to systems, such as monitoring or analytics
   systems using IPFIX.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mickey Spiegel <[email-masked]>
Date: Mon, 25 Jun 2018 14:56:50 -0700

On Mon, Jun 25, 2018 at 11:35 AM, Mickey Spiegel <
[email-masked]> wrote:

> Please find below links to a draft on raw export of IOAM data to
> monitoring and analytics systems using IPFIX. This is meant to complement
> the ongoing IPPM work on IOAM in the data plane.
>

To the best of our knowledge, the examples in section 4 of this draft
follow the requirements in the IPFIX RFCs.

However, while writing this up we noticed some opportunities to improve
encoding efficiency, if it were possible to update the "descriptions" of
some existing IPFIX information elements in the IANA registry at
https://www.iana.org/assignments/ipfix/ipfix.xhtml. This would be
significant when IOAM raw export is generated directly from highly
optimized data planes processing billions of packets per second.

How could we go about updating these "descriptions"?
Could we propose modifications in this draft itself?
Or does this need to be proposed somewhere else, preferably without having
to go through the entire RFC process?

Some details follow.

*Alignment of multiple records with variable length fields in a data set*

>From RFC 5153:

*4.4.3* <https://tools.ietf.org/html/rfc5153#section-4.4.3>*.  Alignment of
Records within a Set*

   ...

   Data Records can be aligned within a Set by appending instances of

   the paddingOctets Information Element at the end of the Record.

   Since all Data Records within a Set have the same structure and size,

   aligning one Data Record implies aligning all the Data Records within

   a single Set.

If there are variable length fields within the Data Record, this seems to
be insufficient. If the variable length field can vary in length by any
amount, not necessarily a multiple of 4n, then how can alignment of data
records within a set be achieved?

For our purposes, the question is really around variable length instances
of *313 ipHeaderPacketSection*. In the IANA registry, there is one sentence
of concern in the description:

When the sectionExportedOctets field corresponding to this Information
Element does not exist, this Information Element SHOULD have a variable
length and MUST NOT be padded.

In case the length of the IP packet is small and is not a multiple of 4
octets, could we use a variable length instance of *ipHeaderPacketSection*
without *sectionExportedOctets*, setting the *Length* to a multiple of 4
octets and inserting 0 to 3 octets of padding between the length of the IP
packet and the 4 octet aligned *Length* value? The collector could figure
out what is happening by observing the discrepancy between the IP packet
length and the *Length* of *ipHeaderPacketSection*.

*Overly Restrictive Descriptions of ipHeaderPacketSection and
dataLinkFrameSection*

For highly optimized data plane implementations in hardware or software,
every additional field eats up more resources. The descriptions of
*ipHeaderPacketSection* and *dataLinkFrameSection* in the IANA registry
require use of additional fields in some cases, but this seems to be
unnecessary.

*313 ipHeaderPacketSection:*

When the sectionExportedOctets field corresponding to this Information
Element does not exist, this Information Element SHOULD have a variable
length and MUST NOT be padded.

In this case *sectionExportedOctets* seems somewhat redundant with the
length in the IP packet. Why can't one omit *sectionExportedOctets* and
still use a fixed size *ipHeaderPacketSection* with padding?

*315 dataLinkFrameSection*

Same issue with *sectionExportedOctets* as *ipHeaderPacketSection*.

In addition:

Further Information Elements, i.e., dataLinkFrameType and
dataLinkFrameSize, are needed to specify the data link type and the size of
the data link frame of this Information Element. A set of these Information
Elements MAY be contained in a structured data type, as expressed in [
RFC6313 <http://www.iana.org/go/rfc6313>]. Or a set of these Information
Elements MAY be contained in one Flow Record as shown in Appendix B of [
RFC7133 <http://www.iana.org/go/rfc7133>].

Why can't there be a default value of *Ethernet II* when
*dataLinkFrameSection* is present but *dataLinkFrameType* is omitted?

Why does *dataLinkFrameSize* need to be present?

In case of a truncated packet section, is this supposed to be the length
before truncation, or the size of the truncated portion?

In case of a variable length encoding, wouldn't the *Length* of
*dataLinkFrameSection* be enough?

Suggestions and comments regarding these issues would be appreciated.

Mickey

> Subject: New Version Notification for draft-spiegel-ippm-ioam-rawexp
> ort-00.txt
> [email-masked]>, Mickey Spiegel <[email-masked]>,
> Ramesh Sivakolundu <[email-masked]>
>
>
>
> URL:            https://www.ietf.org/internet-
> drafts/draft-spiegel-ippm-ioam-rawexport-00.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-spiegel-ippm-ioam-rawexport/
> Htmlized:       https://tools.ietf.org/html/d
> raft-spiegel-ippm-ioam-rawexport-00
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-spiegel-ippm-ioam-rawexport
>
>
> Abstract:

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 27 Jun 2018 10:21:54 +0000

Hi Mickey,

two quick notes/questions on the draft:

·       Why was IPFIX chosen to frame the IOAM data for raw export? It was probably cutting the balance between efficiency and the fact that IPFIX is already well established – but some additional color would be nice.

·       ioamReportFlags (section 3.2.1): For dropped packets, is seems as if so far only the fact that the packet was dropped is indicated – but not why it was dropped. Would it make sense to also have a drop reason indicated, e.g. buffer overflow, no route to host, etc.?

Thanks, Frank

From: ippm <[email-masked]> On Behalf Of Mickey Spiegel
Sent: Montag, 25. Juni 2018 20:36
To: IETF IPPM WG <[email-masked]>
Subject: [ippm] Fwd: New Version Notification for draft-spiegel-ippm-ioam-rawexport-00.txt

Please find below links to a draft on raw export of IOAM data to monitoring and analytics systems using IPFIX. This is meant to complement the ongoing IPPM work on IOAM in the data plane.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Mar 19, 2018 at 2:39 AM
Subject: New Version Notification for draft-spiegel-ippm-ioam-rawexport-00.txt
To: Frank Brockners <[email-masked]<mailto:[email-masked]>>, Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>, Mickey Spiegel <[email-masked]<mailto:[email-masked]>>, Ramesh Sivakolundu <[email-masked]<mailto:[email-masked]>>

Name:           draft-spiegel-ippm-ioam-rawexport
Revision:       00
Title:          In-situ OAM raw data export with IPFIX
Document date:  2018-03-19
Group:          Individual Submission
Pages:          19
URL:            https://www.ietf.org/internet-drafts/draft-spiegel-ippm-ioam-rawexport-00.txt
Status:         https://datatracker.ietf.org/doc/draft-spiegel-ippm-ioam-rawexport/
Htmlized:       https://tools.ietf.org/html/draft-spiegel-ippm-ioam-rawexport-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Mickey Spiegel <[email-masked]>
Date: Wed, 27 Jun 2018 19:29:19 -0700

On Wed, Jun 27, 2018 at 3:21 AM, Frank Brockners (fbrockne) <
fbrockne=[email-masked]> wrote:

> ·       Why was IPFIX chosen to frame the IOAM data for raw export? It
> was probably cutting the balance between efficiency and the fact that IPFIX
> is already well established – but some additional color would be nice.
>
There are many reasons why IPFIX makes sense to define the format for raw
export of IOAM metadata. These include:

   1. IPFIX is a widely adopted solution for export of flow statistics to
   collectors. Even though IOAM has different capabilities, focusing primarily
   on per packet telemetry metadata rather than flow statistics, there is
   enough similarity to IPFIX and its PSAMP variant that it can be considered
   to be in the same category.
   2. There is an ecosystem of IPFIX implementations, with numerous
   implementations of IPFIX collectors that could be extended to support IOAM
   raw export.
   3. Many of the information elements required for raw export of IOAM
   metadata are already defined in IPFIX and PSAMP (RFC 5477), as listed in
   the IANA registry for IP Flow Information Export (IPFIX) Entities at
   https://www.iana.org/assignments/ipfix/ipfix.xhtml. The key IPFIX
   information elements that can be leveraged for IOAM raw data export are
   listed in Section 3.1 of the draft.

While many highly optimized data plane implementations of IOAM may not be
able to take advantage of the full flexibility of IPFIX, only supporting a
small number of fields and templates, this flexibility does allow the data
plane implementations to minimize implementation effort by creating a
handful of pre-defined templates that specifically match their
capabilities. Meanwhile monitoring and analytics systems that already
implement IPFIX can leverage their existing code to interpret the received
export packets.

> ·       ioamReportFlags (section 3.2.1): For dropped packets, is seems as
> if so far only the fact that the packet was dropped is indicated – but not
> why it was dropped. Would it make sense to also have a drop reason
> indicated, e.g. buffer overflow, no route to host, etc.?
>
The drop reason is already defined in the existing IPFIX information
element with ID 89, forwardingStatus, as defined at
https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status.

Mickey

>
>
> Thanks, Frank
>
>
>
> *From:* ippm <[email-masked]> *On Behalf Of *Mickey Spiegel
> *Sent:* Montag, 25. Juni 2018 20:36
> *To:* IETF IPPM WG <[email-masked]>
> *Subject:* [ippm] Fwd: New Version Notification for