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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 28, 2025 at 2:59 AM
To: Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Gesendet: Freitag, 25. April 2025 22:14
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Friday, April 25, 2025 at 3:15 AM
To: Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:rgandhi=[e-mail]>>
Gesendet: Donnerstag, 24. April 2025 23:29
An: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 16, 2025 at 2:47 PM
To: Peter Schoenmaker <[e-mail]<mailto:[e-mail]>>, Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[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