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

[Mickey Spiegel <[e-mail]>]

On Mon, Jun 25, 2018 at 11:35 AM, Mickey Spiegel <
[e-mail]> 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.
>
> Suggestions and comments would be much appreciated.
>

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



>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Mon, Mar 19, 2018 at 2:39 AM
> Subject: New Version Notification for draft-spiegel-ippm-ioam-rawexp
> ort-00.txt
> To: Frank Brockners <[e-mail]>, Shwetha Bhandari <
> [e-mail]>, Mickey Spiegel <[e-mail]>,
> Ramesh Sivakolundu <[e-mail]>
>
>
>
> 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/d
> raft-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
>
>
>