[ippm] Re: Request to review draft-gandhi-ippm-stamp-ber

[Rakesh Gandhi <[e-mail]>]

Thanks Ruediger.

Yes, for now, the computation aspect such as (BER = total bit errors
divided by total bits received) is kept outside but we could add/refine
metrics as work progresses in the WG.

Thanks,
Rakesh



On Tue, May 27, 2025 at 8:50 AM <[e-mail]> wrote:

> Hi Rakesh,
>
>
>
> thanks, looks good now. I didn’t dig deeply into the IPPM framework and
> don’t know, whether that’s a requirement...I’d personally however prefer
> you to come up by a formal BER metric specification (the draft by now
> defines, what is measured and how - the metric, its singletons, samples and
> statistics should allow for results comparable by different
> implementations).
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Rakesh Gandhi (rgandhi) <[e-mail]>
> *Gesendet:* Dienstag, 27. Mai 2025 13:15
> *An:* Geib, Rüdiger <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* Re: Request to review draft-gandhi-ippm-stamp-ber
>
>
>
> *Thanks **Ruediger **for the Suggestion.*
>
>
>
> *Weh have added it in the updated draft attached.*
>
>
>
> *Also attaching the diff file with the changes for your review.*
>
>
>
> *Btw, the replies are inline and highlighted in this color below. *
>
>
>
> *Thanks,*
>
> *Rakesh*
>
>
>
>
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Tuesday, May 27, 2025 at 3:07 AM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *AW: Request to review draft-gandhi-ippm-stamp-ber
>
> Hi Rakesh,
>
>
>
> thanks. I failed to detect <RG> marked text. The draft adds text related
> to some of my comments, however.
>
>
>
> Another thought, which you may discuss, if you prefer not to implement:
>
> If any some checksum and/or auth mechanism would cover all fields apart
> from the Extra Padding Data, then
>
>    - Bit Pattern in Padding Data is covered by checksum/auth and any
>    (unwanted) bit error in these fields is detected
>    - Extra Padding Data captures BER, and comparison with Bit Pattern in
>    Padding Data if checksum/auth provide valid results.
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Rakesh Gandhi (rgandhi) <[e-mail]>
> *Gesendet:* Dienstag, 27. Mai 2025 03:50
> *An:* Geib, Rüdiger <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* Re: Request to review draft-gandhi-ippm-stamp-ber
>
>
>
> Hi Ruediger,
>
>
>
> Thank you for your excellent suggestions.
>
> Attaching the updated draft for your review.
>
> Please see replies inline with some text proposal to be added with <RG>…
>
>
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Monday, April 28, 2025 at 2:59 AM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *AW: Request to review draft-gandhi-ippm-stamp-ber
>
> Hi Rakesh,
>
>
>
> thanks. My personal preferences marked [Rudi].
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Rakesh Gandhi (rgandhi) <[e-mail]>
> *Gesendet:* Freitag, 25. April 2025 22:14
> *An:* Geib, Rüdiger <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* Re: Request to review draft-gandhi-ippm-stamp-ber
>
>
>
> Thank you Ruediger for your thoughts on the
> draft.
>
>
>
>
> Please see relies inline with <RG>…
>
>
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Friday, April 25, 2025 at 3:15 AM
> *To: *Rakesh Gandhi (rgandhi) <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *AW: Request to review draft-gandhi-ippm-stamp-ber
>
> Hi Rakesh,
>
>
>
> after brief reading, I think the basic motivation of the draft seems
> alright. Thoughts:
>
>    - The draft should add a BER metric definition, as is available for
>    other IPPM metrics.
>
>
>
> <RG> Yes, that’s a good idea. We could add examples such as:
>
>
>
> (1) Total Bits transmitted and reveived in each direction in a given
> interval.
>
> (2) Bit Error rare in each direction in a given interval
>
> (3) Number packets transmitted vs. Received with Bit errors in each
> direction in a given interval.
>
>
>
> [Rudi]: all sound, please provide text. If there’s ever to be a IPPM BER
> YANG standard model, the metrics occurring there must be defined.
>
>
>
>
>
> *<RG> How about following text?*
>
> *6.  Data Model Parameters*
>
>
>
> *   The configuration data model for bit error detection and bit error*
>
> *   rate measurement using STAMP MUST allow to set the following*
>
> *   parameters:*
>
>
>
> *      - Padding data size*
>
>
>
> *      - Padding bit pattern*
>
>
>
> *      - Transmit interval for the STAMP test packets*
>
>
>
> *      - Computation interval as a multiple of transmit interval for*
>
> *      reporting bit error rate*
>
>
>
> *   The operational data model for bit error detection and bit error rate*
>
> *   measurement using STAMP MUST allow to telemetry the following*
>
> *   parameters:*
>
>
>
> *      - Number of total packets received in the computation interval*
>
>
>
> *      - Number of total packets received with bit errors in the*
>
> *      computation interval*
>
>
>
> *      - Number of total bits in the padding TLV of all received packets*
>
> *      in the computation interval*
>
>
>
> *      - Number of total bit error count in the padding TLV of all*
>
> *      received packets in the computation interval*
>
>
>
>
>
>    - *The draft should provide some more discussion on parametrization.
>    If all L1/L2/L3 headers and non-bit-pattern fields are larger than the
>    measurement bit-pattern, it is more likely that a bit-error hits one of
>    these non-measurement fields. *
>
>
>
> *<RG> Yes, we can add some text on this. *
>
> *<RG> Note that it does not currently detect bit errors in the headers and
> base STAMP packet to keep the solution simple.*
>
> *[Rudi] sure. Still, please inform the reader about some basic
> capabilities and useful parametrisations.*
>
>
>
> *<RG> How about following text?*
>
> *  Note that the procedure and extensions defined in this document do*
>
> *   not detect bit errors in the base STAMP packets, packet headers, or*
>
> *   STAMP TLVs other than the "Extra Padding Data" TLV.  It is possible*
>
> *   that bit errors impact those non-measurement fields of the STAMP test*
>
> *   packets.  Bit errors in those fields result in the failure of*
>
> *   validity checks.  The corrupted STAMP test packets are discarded,*
>
> *   reported using a different measurement metric, and not included in*
>
> *   the bit error rate measurement.*
>
>
>
> *   The integrity of those fields can be verified using the HMAC*
>
> *   mechanisms defined in [RFC8762] and [RFC8972] (which exclude the*
>
> *   "Extra Padding Data" TLV).*
>
>
>
> *   The size of the non-measurement fields in the received STAMP test*
>
> *   packet is excluded from the bit error rate measurement.*
>
>
>
>
>
>    - I also missed a discussion, whether and if yes how the "Bit Pattern
>    in Padding Data" bit pattern is protected against bit errors or how these
>    are detected, if they occurred.
>
>
>
> <RG> Yes, we can add some text on this.
>
> <RG> One option is to configure the pattern on the Reflector.
>
> <RG> Another option is to declare the measurement invalid as most of the
> data in the packet would be detected as bit errors if the pattern had a bit
> error.
>
>
>
> [Rudi] Maybe having one or a set of pre-defined standard-patterns or a
> mechanism supporting these as an option is a good way to proceed.
>
>
>
> *<RG> How about the following text?*
>
> *   It is possible that the bit pattern in the "Bit Pattern in Padding*
>
> *   Data" STAMP TLV itself may contain bit errors.  This can result in a*
>
> *   measurement error due to a mismatch between the bit pattern and the*
>
> *   extra padding data.  One way to avoid this issue is for the Session-*
>
> *   Reflector to use the local configuration or the default value of*
>
> *   0xFF00 as the bit pattern.*
>
>
>
> *Thanks,*
>
> *Rakesh*
>
>
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* Rakesh Gandhi (rgandhi) <rgandhi=[e-mail]>
> *Gesendet:* Donnerstag, 24. April 2025 23:29
> *An:* IETF IPPM WG ([e-mail]) <[e-mail]>
> *Cc:* [e-mail]
> *Betreff:* [ippm] Request to review draft-gandhi-ippm-stamp-ber
>
>
>
> Hi IPPM WG,
>
> We have introduced a new draft on using STAMP for Bit Error Detection.
>
> We would greatly appreciate your thoughts and any suggestions you may
> have.
>
> Thanks,
>
> Rakesh (for authors)
>
>
>
>
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Wednesday, April 16, 2025 at 2:47 PM
> *To: *Peter Schoenmaker <[e-mail]>, Rakesh Gandhi (rgandhi) <
> [e-mail]>
> *Subject: *New Version Notification for draft-gandhi-ippm-stamp-ber-00.txt
>
> A new version of Internet-Draft draft-gandhi-ippm-stamp-ber-00.txt has been
> successfully submitted by Rakesh Gandhi and posted to the
> IETF repository.
>
> Name:     draft-gandhi-ippm-stamp-ber
> Revision: 00
> Title:    Simple Two-Way Active Measurement Protocol (STAMP) Extensions
> for Bit Error Detection and Bit Error Rate Measurement
> Date:     2025-04-16
> Group:    Individual Submission
> Pages:    10
> URL:
> https://www.ietf.org/archive/id/draft-gandhi-ippm-stamp-ber-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-ber/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-stamp-ber
>
>
> Abstract:
>
>    The Simple Two-Way Active Measurement Protocol (STAMP), as defined in
>    RFC 8762, along with its optional extensions specified in RFC 8972,
>    can be utilized for active measurement.  This document further
>    augments the STAMP extensions specified in RFC 8972 to enable the
>    detection of bit errors and the measurement of the bit error rate
>    (BER) within the "Extra Padding Data" of STAMP packets.
>
>
>
> The IETF Secretariat
> _______________________________________________
> ippm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>