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

[Tal Mizrahi <[e-mail]>]

Dear Robert,

Many thanks for the comments.

We have uploaded an updated version that hopefully addresses the
DISCUSS comments.
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/

Please see my responses below, marked [TM].

Please let us know if there are further comments.
Cheers,
Tal.

On Thu, Jun 30, 2022 at 1:37 PM Robert Wilton via Datatracker
<[e-mail]> wrote:
>
> 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

[TM] The text was updated - only packets with the DEX option are counted.

>
> 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.
>

[TM] Fixed.

> 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?

[TM] Agree. Changed to "IETF Review"


>
> 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
>
>
>