[ippm] Re: [ippm] Internet-Draftdraft-li-ippm-ioam-packet-triggered-reporting-00.txt is now

[李志强 <[e-mail]>]

Hi Justin,



Thank you for the careful review and concrete suggestions.



We agree with both points.



1. Namespace-ID



RFC 9197 (Section 4.1) requires the Namespace-ID field to be present

in all IOAM Option-Types.  Since this document defines a new IOAM

Option-Type, we should include it.  The current -00 version missed

this requirement, and we will correct it in the next revision.



This work is intended as an IOAM extension operating within an IOAM

domain, with its semantics processed by IOAM encapsulating, transit,

and decapsulating nodes.  Carrying Namespace-ID is therefore

necessary both for compliance with RFC 9197 and for proper

domain/namespace scoping.



2. Header Figure



We agree that the current header figure is inconsistent with the

text.  The document intends Cycle ID to be a 2-bit field (values 0,

1, 2, 3), but the figure does not make the bit allocation clear.  We

will fix this in the next revision.



We plan to revise the format to explicitly include: Namespace-ID,

Cycle ID, K flag, and Reserved bits.  For example:



 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         Namespace-ID          | Cycle ID |K|    Reserved     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Namespace-ID: 16 bits.  As defined in RFC 9197, Section 4.3.



   Cycle ID:      2 bits.  Identifies the current measurement cycle

                  (values 0-3).



   K:             1 bit.   [brief semantics description].



   Reserved:      13 bits.  MUST be set to zero on transmission and

                  ignored on receipt.



We will update the draft accordingly in the next version (-01).



Thanks again for the helpful review.



Best regards,



 ----邮件原文----发件人：Justin Iurman  <[e-mail]>收件人："[e-mail]" <[e-mail]>,ippm  <[e-mail]>抄　送: (无)发送时间：2026-03-08 16:26:10主题：Re: [ippm] Internet-Draftdraft-li-ippm-ioam-packet-triggered-reporting-00.txt is nowHi, From RFC9197:    An IOAM-Namespace is identified by a 16-bit namespace identifier    (Namespace-ID).  The IOAM-Namespace field is included in all the    IOAM-Option-Types defined in this document and MUST be included in    all future IOAM-Option-Types.Since your draft defines a new IOAM Option-Type, you must include that field. Also, the draft mentions a "2-bit Cycle ID field", while the header definition suggests otherwise (i.e., a 6-bit field). I would suggest at least the following change:# OLD     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    | Cycle ID  |K|                    Reserved                    |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+# NEW     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |         Namespace-ID          | X |K|        Reserved         |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... where X represents the Cycle-ID field.If the need for a Namespace-ID is unclear, then you may not need IOAM at all.Cheers,JustinOn 3/6/26 05:54, [e-mail] wrote:>>     Hi all,>>>>     We submitted a new document to discuss a packet-triggered>>     statistics reporting  extension for In-situ Operations,>>     Administration, and Maintenance (IOAM).>>>>>>     The draft may be found here:https://datatracker.ietf.org/doc/>>     draft-li-ippm-ioam-packet-triggered-reporting/ <https://>>     datatracker.ietf.org/doc/draft-li-ippm-ioam-packet-triggered->>     reporting/>>>>>>>     The draft  defines an extension mechanism for "In-situ OAM" (IOAM)>>     called "packet-triggered statistical reporting.">>>>>>     Its core objective is to address the challenge of how to more>>     reliably and promptly trigger and report statistical information>>     (such as packet and byte counts) for each measurement interval in>>     periodic packet loss measurement.>>>>>>     The draft standardizes a 2-bit "Cycle ID" field, which enables the>>     receiving node (the decapsulating node) to automatically detect>>     the sequential change in the Cycle ID value within packets (0 → 1>>     → 2 → 3 → 0...) and thereby trigger the reporting of statistics>>     for the previous measurement cycle.>>>>>>     This approach serves as an alternative or supplement to>>     traditional timer-based reporting methods.>>>>>>     The mechanism also defines rules for generating "Keepalive">>     packets to ensure that during measurement intervals with no user>>     data traffic, at least one packet carrying the Cycle ID reaches>>     the receiver, thereby maintaining measurement continuity.>>>>>>     Its significance lies in providing a more precise, traffic->>     agnostic, and globally clock-synchronization-independent OAM>>     measurement triggering solution for high-performance networks>>     (such as data centers and telecom core networks), effectively>>     enhancing the automation and timeliness of network performance>>     monitoring and fault localization.>>>>>>     This is an initial version for discussion on the mailing list.>>>>>>     We will update it based on the discussion progress!>>>>>>     Welcome more contribution and collaboration!>>>>>>     Thanks!>>> > ------------------------------------------------------------------------> [e-mail]> > _______________________________________________> ippm mailing list -- [e-mail]> To unsubscribe send an email to [e-mail]：Re: [ippm] Internet-Draftdraft-li-ippm-ioam-packet-triggered-reporting-00.txt is nowHi, From RFC9197:    An IOAM-Namespace is identified by a 16-bit namespace identifier    (Namespace-ID).  The IOAM-Namespace field is included in all the    IOAM-Option-Types defined in this document and MUST be included in    all future IOAM-Option-Types.Since your draft defines a new IOAM Option-Type, you must include that field. Also, the draft mentions a "2-bit Cycle ID field", while the header definition suggests otherwise (i.e., a 6-bit field). I would suggest at least the following change:# OLD     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    | Cycle ID  |K|                    Reserved                    |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+# NEW     0                   1                   2                   3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |         Namespace-ID          | X |K|        Reserved         |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... where X represents the Cycle-ID field.If the need for a Namespace-ID is unclear, then you may not need IOAM at all.Cheers,JustinOn 3/6/26 05:54, [e-mail] wrote:>>     Hi all,>>>>     We submitted a new document to discuss a packet-triggered>>     statistics reporting  extension for In-situ Operations,>>     Administration, and Maintenance (IOAM).>>>>>>     The draft may be found here:https://datatracker.ietf.org/doc/>>     draft-li-ippm-ioam-packet-triggered-reporting/ <https://>>     datatracker.ietf.org/doc/draft-li-ippm-ioam-packet-triggered->>     reporting/>>>>>>>     The draft  defines an extension mechanism for "In-situ OAM" (IOAM)>>     called "packet-triggered statistical reporting.">>>>>>     Its core objective is to address the challenge of how to more>>     reliably and promptly trigger and report statistical information>>     (such as packet and byte counts) for each measurement interval in>>     periodic packet loss measurement.>>>>>>     The draft standardizes a 2-bit "Cycle ID" field, which enables the>>     receiving node (the decapsulating node) to automatically detect>>     the sequential change in the Cycle ID value within packets (0 → 1>>     → 2 → 3 → 0...) and thereby trigger the reporting of statistics>>     for the previous measurement cycle.>>>>>>     This approach serves as an alternative or supplement to>>     traditional timer-based reporting methods.>>>>>>     The mechanism also defines rules for generating "Keepalive">>     packets to ensure that during measurement intervals with no user>>     data traffic, at least one packet carrying the Cycle ID reaches>>     the receiver, thereby maintaining measurement continuity.>>>>>>     Its significance lies in providing a more precise, traffic->>     agnostic, and globally clock-synchronization-independent OAM>>     measurement triggering solution for high-performance networks>>     (such as data centers and telecom core networks), effectively>>     enhancing the automation and timeliness of network performance>>     monitoring and fault localization.>>>>>>     This is an initial version for discussion on the mailing list.>>>>>>     We will update it based on the discussion progress!>>>>>>     Welcome more contribution and collaboration!>>>>>>     Thanks!>>> > ------------------------------------------------------------------------> [e-mail]> > _______________________________________________> ippm mailing list -- [e-mail]> To unsubscribe send an email to [e-mail]