Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

I believe this draft is ready for publication, after addressing my comments
below.

Comments:

Section 4.6 IOAM Edge-to-Edge Option-Type

In the trace option, the timestamp specifies “the time at which the packet
was received by the node.”

In the edge-to-edge option, it specifies a timestamp “for the transmission
of the frame”.

Why are these different?

Wouldn’t it make more sense to use the time when the packet was received,
in order to determine the overall time that the packet spends in the IOAM
domain?

Section 4.4.1 Pre-allocated and Incremental Trace Option-Types

Text along the following lines should be added somewhere in this section:

An IOAM transit node (that is not an IOAM encapsulating node or IOAM
decapsulating node) MUST NOT modify any of the fields in the fixed size
“trace option header”, other than “flags” and “RemainingLen”, i.e. an IOAM
transit node MUST NOT modify the Namespace-ID, NodeLen, IOAM-Trace-Type, or
Reserved fields.

The “Reserved” field in Section 4.4.1 just says “Must be zero”. That should
be expanded upon:

An IOAM encapsulating node MUST set the value to zero upon transmission.
IOAM transit nodes must ignore the received value.

The “Node data List [n]” description is a little confusing, particularly
the first sentence.

Aside from the first sentence, the rest of this text, as well as the
“RemainingLen” definition, imply that a “node data element” (i.e. list
item) contains all of the IOAM-Data-Fields that a particular node adds to
the trace option.

This implies that the IOAM-Trace-Type bits (collectively) determine which
data fields are included in each node data element.

Any reference to the “n-th node data in the node data list” is misleading
at best, more likely incorrect. That sentence should just be removed.

The last sentence before the “IOAM-Trace-Type” bit definitions could be
moved into the “Node data List [n]” definition instead:

The order of packing the data fields in each node data element follows the
bit order of the IOAM-Trace-Type field

Section 7.4 IOAM Trace-Flags Registry

This section should specify that Bits 1 through 3 are available for
assignment.
A process needs to be selected for assignment of these values, probably RFC
Required.

Section 8 Security Considerations

There is text present about "immediate export" mode.
This should probably be moved to the DEX draft.

Section 9 Acknowledgements

There is text present about "immediate export" mode that should be removed.

Mickey Spiegel
Barefoot Networks, an Intel company

On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> Hello IPPM,
>
> Happy New Year! This email starts a working group last call for "Data
> Fields for In-situ OAM" (
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).
>
> The last call will end on *Tuesday, January 21*. Please reply to
> ippm@ietf.org with your reviews and comments. Please indicate whether you
> think this document is ready for publication.
>
> Best,
> Tommy (as co-chair)
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>