[ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-ioam-direct-export-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

I had a couple of minor discuss comments to clarify a couple of points that
seemed unclear:

1) Definition of Sequence Number:

   Sequence Number An optional 32-bit sequence number starting from 0
                   and increasing by 1 for each following monitored
                   packet from the same flow at the encapsulating node.
                   The Sequence Number, when combined with the Flow ID,
                   provides a convenient approach to correlate the
                   exported data from the same user packet.

Please can you clarify.  Is this every packet in the flow (presumably not)? 
Does monitored packet means just those with the DEX option?  Could it include
other packets

2. Optional field ordering.
   Optional fields The optional fields, if present, reside after the
                   Reserved field.  The order of the optional fields is
                   according to the respective bits that are enabled in
                   the Extension-Flags field.  Each optional field is 4
                   octets long.

Please can clarify that the order is from most significant bit to least
significant bit of the option field.

3. Allocation is based on the "RFC
   Required" procedure, as defined in [RFC8126].

Given the number of extensions is so limited, is RFC required (e.g. allows ISE)
really a strict enough allocation policy?

Regards,
Rob


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Here are my non-blocking comments:

1.
   This draft has evolved from combining some of the concepts of PBT-I
   from [I-D.song-ippm-postcard-based-telemetry] with immediate
   exporting from [I-D.ietf-ippm-ioam-flags].

I'm not sure that this paragraph is really helpful now, and could probably be
deleted - you could use the datatracker to indicate the document history and
which previous drafts this document replaces.

2.
   N >> M

I'm assuming that by ">>", this means much greater than?  It would be better
use words here, or at least define what this means (e.g., as opposed to a
bit-shift).

3.
   An IOAM node
   MAY maintain a counter or a set of counters that count the events in
   which the IOAM node receives a packet with the DEX Option-Type and
   does not collect and/or export data due to the rate limits.

Given that this is a MAY, I wasn't sure that this really specifies anything, I
guess that it is just offering a suggestion.

4.
   Exported packets SHOULD NOT be exported over a path or a tunnel that
   is subject to IOAM direct exporting.  Furthermore, IOAM encapsulating
   nodes that can identify a packet as an IOAM exported packet MUST NOT
   push a DEX Option-Type into such a packet.  This requirement is
   intended to prevent nested exporting and/or exporting loops.

It was unclear to me how that that SHOULD NOT can really be enforced, if the
exported packets are allowed to leave the limited domain.  Perhaps the "SHOULD
NOT" should be limited to the domain where IOAM is operating?

5.
   transit or decapsulating IOAM node that receives an unknown IOAM-
   Option-Type ignores it (as defined in [RFC9197]), and specifically
   nodes that do not support the DEX Option-Type ignore it.  Note that
   as per [RFC9197] a decapsulating node removes the IOAM encapsulation
   and all its IOAM-Option-Types, and specifically in the case where one
   of these options is a (possibly unknown) DEX Option-Type.  The
   ability to skip over a (possibly unknown) DEX Option-Type in the
   parsing or in the decapsulation procedure is dependent on the
   specific encapsulation, which is outside the scope of this document.
   For example, when IOAM is encapsulated in IPv6

I found the sentence from "Note that ..." to be somewhat unclear.

6. Option-Type Format

Would it be more helpful to explicitly specify what the length is.  I.e., X
bytes + 4 * number of set bits in the Extension-Flags?

7. Extension-Flags

More a question for my own knowledge:  I presume that the length calculation
(i.e., checking for the count of set bits) can be performed efficiently?  I.e.,
if calculating the length is important on any fast path.

8. subject to birthday problem conflicts, while centralized

Would it be helpful to spell out what is meant by "birthday problem conflicts",
or perhaps include an informative reference to the wiki page?

Nits:
N>100 => N > 100