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

Dear All,
please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM WG
Last Call:

   - In Abstract and Section 3, Segment Routing is characterized, among
   other networking technologies, as a transport. RFC 8402 defines Segment
   Routing as a method to leverage the source routing paradigm. Where else
   could the Segment Routing be defined as transport?
   - Also, "native IPv6" is mentioned in the Abstract as transport. Could
   it be just a reference to IPv6? What is the significance of singling out
   "native IPv6"?
   - Introduction section explains the "in-situ" term as

   The term "in-situ" refers to the fact that the OAM
   data is added to the data packets rather than is being sent within
   packets specifically dedicated to OAM.

But with the introduction of Loopback and Direct Export as iOAM behaviors,
iOAM data are not added to the data packet. And how these new iOAM
functions affect the definition of IOAM control points in Section 3?

   - I-D.lapukhov-dataplane-probe referenced as describing "recent active
   probing mechanisms". That could have been the case in 2016 when the draft
   was last time updated. But has expired and has not been discussed or worked
   for 3.5 years.
   - In regard to the control over iOAM, text in Section 3 states "It
   SHOULD be possible to enable IOAM on a selected set of traffic ..." Does
   that mean that not providing the selective enabling of iOAM is an
   acceptable option?
   - Further in Section 3, the requirement for encapsulation independence
   is using SHOULD "Data formats for IOAM SHOULD be defined in a
   transport-independent manner." What are the examples of exceptions?
   - section 4.4 introduces the notion of an "iOAM capable node". Which of
   iOAM objects are expected to be supported by the iOAM capable node? If a
   node doesn't support a sub-set of iOAM data types, would it still be
   considered as iOAM capable?
   - Section 4.4.1 I'm having a hard time figuring how the presence
   of Opaque State Snapshot space can be deduced. The explanation in NodeLen
   is not clear to me.
   - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only in
   part of the latter specifying that the format is wide. What is the length
   on data identified by Bit 0?
   - Hop_limit in Section 4.4.2 is defined as

        This is copied from the lower
         layer, e.g., TTL value in IPv4 header or hop limit field from
         IPv6 header of the packet when the packet is ready for
         transmission.
What is the value of Hop_Limit field if the lower level does not include
TTL/Hop Limit field?

   - Four octets are allocated for timestamp subseconds in Section 4.4.2.
   Both PTP and NTP have formats that can provide a higher resolution of a
   timestamp. That likely to be useful where a higher resolution of time
   measurement, e.g. delay variation is needed (for example, URLLC
   applications of 5G, TSN or DetNet). Can iOAM data be extended in the future
   to support a different length of the subsecond field?
   - What was the rationale to choose nanoseconds as the unit for transit
   delay?
   - How future proof is allocating four octets to express the length of an
   egress queue (queue depth)? What should be the value if an iOAM node cannot
   write the local value in four octets?
   - Similar to the questions above but in regard to the buffer occupancy
   field.
   - Checksum Complement may be practical but it raises serious security
   issues. I couldn't find these being identified and discussed in the
   document.
   - Section 5 defers the specification of the particular timestamp format
   used in the given iOAM Namespace to the management plane. Does that mean
   that all nodes in the given iOAM Domain must support the same format? In
   other words, timestamps collected in the domain required to be in the
   homogeneous format - either all in NTP, all in PTP, or all in POSIX. That
   looks like unnecessary complexity and limitation and may cause lower
   accuracy of time measurement as an iOAM node may be required to transform
   from its native time format into the format chosen by the management plane.

Regards,
Greg

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
>