Return-Path: X-Original-To: ippm@mail2.ietf.org Delivered-To: ippm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E57D0CA199B6 for ; Sat, 14 Mar 2026 19:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 0.938 X-Spam-Level: X-Spam-Status: No, score=0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=chinamobile.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xad2yudwN6Ps for ; Sat, 14 Mar 2026 19:16:51 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [111.22.67.139]) by mail2.ietf.org (Postfix) with ESMTP id 19BAFCA199AA for ; Sat, 14 Mar 2026 19:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chinamobile.com; s=default; l=0; h=from:subject:message-id:to:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=aogjhlYb42D9y06Ov/ZP8oAVBD28D9lc97efEUH+f1PSUJ2kIs3nyIHEuNnT3WJ/ROtbdOJ2pmtZw IRrWOkoAhUxJqoAZchDCWXxqh/JgK55b16ZDExh+tLtkIAEPOamZCZ6PuiOstNg303UAI5RyJH1u+c DFJDTj/yVbWFmZGE= X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee969b6167e156-ec236; Sun, 15 Mar 2026 10:16:31 +0800 (CST) X-RM-TRANSID: 2ee969b6167e156-ec236 X-RM-SPAM-FLAG: 00000000 Received: from lizhiqiangyjy@chinamobile.com ( [14.127.217.225] ) by ajax-webmail-syy-appsvr05-11005 (Richmail) with HTTP; Sun, 15 Mar 2026 10:16:29 +0800 (CST) Date: Sun, 15 Mar 2026 10:16:29 +0800 (CST) From: =?utf-8?B?5p2O5b+X5by6?= To: Justin Iurman , ippm Message-ID: <2afd69b61608042-0000f.Richmail.00002072661092907087@chinamobile.com> References: <2026030612541709606416@chinamobile.com>, <1e058a78-10e0-416f-b803-923928d435a8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_608987_378200506.1773540989614" X-Priority: 3 X-RM-TRANSID: 2afd69b61608042-0000f Encrypt-Channel: web X-RM-OA-ENC-TYPE: 0 X-RM-FontColor: 0 X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0 X-Mailer: Richmail_Webapp(V2.5.01) Message-ID-Hash: A4HFP4C4MCPL7OHTS2QW2NQDHBN6HNMX X-Message-ID-Hash: A4HFP4C4MCPL7OHTS2QW2NQDHBN6HNMX X-MailFrom: lizhiqiangyjy@chinamobile.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bippm=5D_Re=3A_=5Bippm=5D_Internet-Draftdraft-li-ippm-ioam-packe?= =?utf-8?q?t-triggered-reporting-00=2Etxt_is_now?= List-Id: IETF IP Performance Metrics Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_608987_378200506.1773540989614 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----=E5=8F=91=E4=BB=B6=E4=BA=BA=EF= =BC=9AJustin Iurman =E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A"lizhiqiangyjy@chinamobile.com" ,ip= pm =E6=8A=84=E3=80=80=E9=80=81: (=E6=97=A0)=E5=8F=91=E9=80= =81=E6=97=B6=E9=97=B4=EF=BC=9A2026-03-08 16:26:10=E4=B8=BB=E9=A2=98=EF=BC= =9ARe: [ippm] Internet-Draftdraft-li-ippm-ioam-packet-triggered-reporting-0= 0.txt is nowHi, From RFC9197: An IOAM-Namespace is identified by a 16-bi= t namespace identifier (Namespace-ID). The IOAM-Namespace field is incl= uded in all the IOAM-Option-Types defined in this document and MUST be i= ncluded in all future IOAM-Option-Types.Since your draft defines a new I= OAM 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-I= D is unclear, then you may not need IOAM at all.Cheers,JustinOn 3/6/26 05:5= 4, lizhiqiangyjy@chinamobile.com wrote:>> Hi all,>>>> We submitted = a new document to discuss a packet-triggered>> statistics reporting ex= tension 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/ > datatr= acker.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 pro= mptly trigger and report statistical information>> (such as packet and = byte counts) for each measurement interval in>> periodic packet loss me= asurement.>>>>>> 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= =E2=86=92 1>> =E2=86=92 2 =E2=86=92 3 =E2=86=92 0...) and thereby trig= ger the reporting of statistics>> for the previous measurement cycle.>>= >>>> This approach serves as an alternative or supplement to>> trad= itional timer-based reporting methods.>>>>>> The mechanism also defines= rules for generating "Keepalive">> packets to ensure that during measu= rement intervals with no user>> data traffic, at least one packet carry= ing the Cycle ID reaches>> the receiver, thereby maintaining measuremen= t 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>> enhanci= ng the automation and timeliness of network performance>> monitoring an= d fault localization.>>>>>> This is an initial version for discussion o= n the mailing list.>>>>>> We will update it based on the discussion pro= gress!>>>>>> Welcome more contribution and collaboration!>>>>>> Tha= nks!>>> > -----------------------------------------------------------------= -------> lizhiqiangyjy@chinamobile.com> > _________________________________= ______________> ippm mailing list -- ippm@ietf.org> To unsubscribe send an = email to ippm-leave@ietf.orgSubject=EF=BC=9ARe: [ippm] Internet-Draftdraft-= li-ippm-ioam-packet-triggered-reporting-00.txt is nowHi, From RFC9197: A= n IOAM-Namespace is identified by a 16-bit namespace identifier (Namespa= ce-ID). The IOAM-Namespace field is included in all the IOAM-Option-Typ= es defined in this document and MUST be included in all future IOAM-Opti= on-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 he= ader definition suggests otherwise (i.e., a 6-bit field). I would suggest a= t 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 +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name= space-ID | X |K| Reserved | +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... where X represents the Cyc= le-ID field.If the need for a Namespace-ID is unclear, then you may not nee= d IOAM at all.Cheers,JustinOn 3/6/26 05:54, lizhiqiangyjy@chinamobile.com w= rote:>> 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 foun= d here:https://datatracker.ietf.org/doc/>> draft-li-ippm-ioam-packet-tr= iggered-reporting/ > datatracker.ietf.org/doc/draft-li-ippm-i= oam-packet-triggered->> reporting/>>>>>>> The draft defines an ext= ension mechanism for "In-situ OAM" (IOAM)>> called "packet-triggered st= atistical reporting.">>>>>> Its core objective is to address the challe= nge of how to more>> reliably and promptly trigger and report statistic= al information>> (such as packet and byte counts) for each measurement = interval in>> periodic packet loss measurement.>>>>>> The draft sta= ndardizes a 2-bit "Cycle ID" field, which enables the>> receiving node = (the decapsulating node) to automatically detect>> the sequential chang= e in the Cycle ID value within packets (0 =E2=86=92 1>> =E2=86=92 2 =E2= =86=92 3 =E2=86=92 0...) and thereby trigger the reporting of statistics>> = for the previous measurement cycle.>>>>>> This approach serves as a= n alternative or supplement to>> traditional timer-based reporting meth= ods.>>>>>> 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 signif= icance lies in providing a more precise, traffic->> agnostic, and globa= lly clock-synchronization-independent OAM>> measurement triggering solu= tion for high-performance networks>> (such as data centers and telecom = core networks), effectively>> enhancing the automation and timeliness o= f network performance>> monitoring and fault localization.>>>>>> Th= is is an initial version for discussion on the mailing list.>>>>>> We w= ill update it based on the discussion progress!>>>>>> Welcome more cont= ribution and collaboration!>>>>>> Thanks!>>> > ------------------------= ------------------------------------------------> lizhiqiangyjy@chinamobile= .com> > _______________________________________________> ippm mailing list = -- ippm@ietf.org> To unsubscribe send an email to ippm-leave@ietf.org ------=_Part_608987_378200506.1773540989614 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Justin,


Thank you for the careful review and concrete suggestions.

=

We agree with both points.


1. Name= space-ID


RFC 9197 (Section 4.1) requires the Nam= espace-ID field to be present

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

Option-Type, we should inclu= de it.  The current -00 version missed

this requirement, and we will correct it in the next revis= ion.


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

do= main, with its semantics processed by IOAM encapsulating, transit,

and decapsulating nodes.  Carr= ying 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-bi= t field (values 0,

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

will fix this in the next revision.<= /span>


We plan to revise the format to explicitly inclu= de: Namespace-ID,

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


&= nbsp;0                   = 1                   2&nbs= p;                  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 de= fined in RFC 9197, Section 4.3.


   Cyc= le ID:      2 bits.  Identifies the current measurement= cycle

     =             (values 0-3).


   K:             1 b= it.   [brief semantics description].


&= nbsp;  Reserved:      13 bits.  MUST be set to zer= o on transmission and

 = ;                 ignored on receip= t.


We will update the draft accordingly in the n= ext version (-01).


Thanks again for the helpful = review.


= Best regards,



 

----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87----
=E5=8F=91=E4=BB= =B6=E4=BA=BA=EF=BC=9AJustin Iurman  <justin.iurman@gmail.= com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"lizhiqiangyjy@chinamo= bile.com" <lizhiqiangyjy@chinamobile.com>,ippm  &= lt;ippm@ietf.org>
=E6=8A=84=E3=80=80=E9=80=81: (=E6=97=A0)
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2026-03-08 16:26:10
= =E4=B8=BB=E9=A2=98=EF=BC=9ARe: [ippm] Internet-Draftdraft-li-ippm= -ioam-packet-triggered-reporting-00.txt is now

Hi,
<= br/> 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&nbs= p;this document and MUST be included in
&= nbsp;   all future IOAM-Option-Types.

Sin= ce 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&n= bsp;suggests otherwise (i.e., a 6-bit field). = ;I would 
suggest at least the following&= nbsp;change:

# OLD

     0&n= bsp;            = ;      1      &= nbsp;           &nbs= p;2            =        3
    &nb= sp;0 1 2 3 4 5 6 7 8 9 0&= nbsp;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   =             &nb= sp;    |
    +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

# NEW
     0       =             1&n= bsp;            = ;      2      &= nbsp;           &nbs= p;3
     0 1 2 3 4 5&= nbsp;6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6&nbs= p;7 8 9 0 1
    +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   &n= bsp;|         Namespace-ID&nbs= p;         | X |K|&n= bsp;       Reserved   &nb= sp;     |
    +-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... whe= re X represents the Cycle-ID field.

If&nb= sp;the need for a Namespace-ID is unclear,&nb= sp;then you may not need IOAM at 
al= l.

Cheers,
Justin

On 3/6/26 05:54, liz= hiqiangyjy@chinamobile.com wrote:
>>    =  Hi all,
>>
>>     W= e submitted a new document to discuss a&= nbsp;packet-triggered
>>     statistics&= nbsp;reporting  extension for In-situ Operations,<= br/>>>     Administration, and Mai= ntenance (IOAM).
>>
>>
>>  &nb= sp;  The draft may be found here:https:/= /datatracker.ietf.org/doc/
>>     draft-= li-ippm-ioam-packet-triggered-reporting/ <https://
>>&nbs= p;    datatracker.ietf.org/doc/draft-li-ippm-ioam-packe= t-triggered-
>>     reporting/>
&= gt;>
>>
>>     The dra= ft  defines an extension mechanism for &= quot;In-situ OAM" (IOAM)
>>    = ; called "packet-triggered statistical reporting.&= quot;
>>
>>
>>     I= ts core objective is to address the chal= lenge of how to more
>>   &nbs= p; reliably and promptly trigger and report&n= bsp;statistical information
>>     = (such as packet and byte counts) for eac= h measurement interval in
>>   &nbs= p; periodic packet loss measurement.
>>
&= gt;>
>>     The draft stand= ardizes a 2-bit "Cycle ID" field, w= hich enables the
>>     receiv= ing node (the decapsulating node) to automati= cally detect
>>     the sequen= tial change in the Cycle ID value within=  packets (0 =E2=86=92 1
>>   &= nbsp; =E2=86=92 2 =E2=86=92 3 =E2=86=92 0...)=  and thereby trigger the reporting of st= atistics
>>     for the previo= us measurement cycle.
>>
>>
>> = ;    This approach serves as an&nbs= p;alternative or supplement to
>>   = ;  traditional timer-based reporting methods.
= >>
>>
>>     The me= chanism also defines rules for generating &qu= ot;Keepalive"
>>     packets t= o ensure that during measurement intervals wi= th no user
>>     data tr= affic, at least one packet carrying the = Cycle ID reaches
>>     the&nb= sp;receiver, thereby maintaining measurement continuity= .
>>
>>
>>     Its&n= bsp;significance lies in providing a more pre= cise, traffic-
>>     agnostic,&nbs= p;and globally clock-synchronization-independent OAM
>= ;>     measurement triggering solutio= n for high-performance networks
>>  &nbs= p;  (such as data centers and telecom&nb= sp;core networks), effectively
>>   &nbs= p; enhancing the automation and timeliness of=  network performance
>>     mo= nitoring and fault localization.
>>
>>>>     This is an initial&= nbsp;version for discussion on the mailing li= st.
>>
>>
>>     We&= nbsp;will update it based on the discussion&n= bsp;progress!
>>
>>
>>    = ; Welcome more contribution and collaboration!
>>
>>
>>     Thanks!>>
> 
> -----------------------------------= -------------------------------------
> lizhiqiangyjy@chinamobi= le.com
> 
> _______________________________________= ________
> ippm mailing list -- ippm@ietf.o= rg
> To unsubscribe send an email to&n= bsp;ippm-leave@ietf.org


Subject=EF=BC=9ARe: [ippm] = Internet-Draftdraft-li-ippm-ioam-packet-triggered-reporting-00.txt is&= nbsp;now

Hi,

 From RFC9197:

 &nbs= p;  An IOAM-Namespace is identified by a=  16-bit namespace identifier
    (Na= mespace-ID).  The IOAM-Namespace field is inc= luded in all the
    IOAM-Option-Typ= es defined in this document and MUST be&= nbsp;included in
    all future IOAM= -Option-Types.

Since your draft defines a = ;new IOAM Option-Type, you must include that&= nbsp;
field. Also, the draft mentions a &= quot;2-bit Cycle ID field", while the header definition suggests otherwise (i.e., a&n= bsp;6-bit field). I would 
suggest at lea= st the following change:

# OLD

 =     0        &n= bsp;          1 &nbs= p;            &= nbsp;    2       &nb= sp;           3
=      0 1 2 3 4 5 6&n= bsp;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
    +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |&nb= sp;Cycle ID  |K|       &n= bsp;            = ;Reserved           =          |
  &nb= sp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= br/>
# NEW

     0  &nb= sp;            =     1        &n= bsp;          2 &nbs= p;            &= nbsp;    3
     0 1&n= bsp;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
  =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
    |       &= nbsp; Namespace-ID        &nbs= p; | X |K|        Re= served         |
 &nb= sp;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

... where X represents the Cycle-ID=  field.

If the need for a Namespace-= ID is unclear, then you may not need&nbs= p;IOAM at 
all.

Cheers,
Justin

On = 3/6/26 05:54, lizhiqiangyjy@chinamobile.com wrote:
>&= gt;     Hi all,
>>
>>&nbs= p;    We submitted a new document&n= bsp;to discuss a packet-triggered
>>  &n= bsp;  statistics reporting  extension for&nbs= p;In-situ Operations,
>>     Admini= stration, and Maintenance (IOAM).
>>
>><= br/>>>     The draft may be&n= bsp;found here:https://datatracker.ietf.org/doc/
>> &nb= sp;   draft-li-ippm-ioam-packet-triggered-reporting/ &l= t;https://
>>     datatracker.ietf.org/d= oc/draft-li-ippm-ioam-packet-triggered-
>>    = ; reporting/>
>>
>>
>>  &nb= sp;  The draft  defines an extension&nbs= p;mechanism for "In-situ OAM" (IOAM)
>= >     called "packet-triggered s= tatistical reporting."
>>
>>
>>&nbs= p;    Its core objective is to = ;address the challenge of how to more
>= ;>     reliably and promptly tri= gger and report statistical information
>>&nb= sp;    (such as packet and byte&nbs= p;counts) for each measurement interval in
>= ;>     periodic packet loss meas= urement.
>>
>>
>>    &nbs= p;The draft standardizes a 2-bit "Cycle = ID" field, which enables the
>> &nb= sp;   receiving node (the decapsulating = node) to automatically detect
>>   =   the sequential change in the Cycle&nbs= p;ID value within packets (0 =E2=86=92 1
= >>     =E2=86=92 2 =E2=86=92 = 3 =E2=86=92 0...) and thereby trigger the&nbs= p;reporting of statistics
>>    &nb= sp;for the previous measurement cycle.
>>
>>
>>     This approach = ;serves as an alternative or supplement to>>     traditional timer-based r= eporting methods.
>>
>>
>>  &n= bsp;  The mechanism also defines rules f= or generating "Keepalive"
>>   = ;  packets to ensure that during measure= ment intervals with no user
>>  &nb= sp;  data traffic, at least one packet&n= bsp;carrying the Cycle ID reaches
>> &nb= sp;   the receiver, thereby maintaining = measurement continuity.
>>
>>
>> &n= bsp;   Its significance lies in providin= g a more precise, traffic-
>>  &nbs= p;  agnostic, and globally clock-synchronization-i= ndependent OAM
>>     measurement&n= bsp;triggering solution for high-performance networks>>     (such as data cente= rs and telecom core networks), effectively
>= ;>     enhancing the automation = and timeliness of network performance
>> = ;    monitoring and fault localization.<= br/>>>
>>
>>     This&nb= sp;is an initial version for discussion on&nb= sp;the mailing list.
>>
>>
>> =     We will update it based on=  the discussion progress!
>>
>>
>= >     Welcome more contribution = and collaboration!
>>
>>
>>  &= nbsp;  Thanks!
>>
> 
> --------= ----------------------------------------------------------------
>&n= bsp;lizhiqiangyjy@chinamobile.com
> 
> ____________= ___________________________________
> ippm mailing li= st -- ippm@ietf.org
> To unsubscribe send&n= bsp;an email to ippm-leave@ietf.org


------=_Part_608987_378200506.1773540989614--