Early Review of draft-ietf-bmwg-sr-bench-meth-08
review-ietf-bmwg-sr-bench-meth-08-perfmetrdir-early-wu-2026-09-14-00

# Summary

The document defines a methodology for benchmarking Segment Routing (SR)
performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS).

## Has Issues:
I have some minor concerns about this document that I think should be resolved
before publication.

## Major comments

1. In the section 3 on reporting format, the measurement unit for some of
metrics have been specified such as throughput, however the measure unit for
all the other metrics are unspecified, suggest to add measurement unit for each
metric in section 4.

2. Section 4.3 said reporting format for latency is specified in section 3,
however I can not see latency parameter in section 3.

3. Similarly Section 4.4 said reporting format for frame loss is specified in
section 3, however I am unable to see frame loss parameter described in section
3.

4. For metrics defined in section 4, how is different from what has been
specified in RFC5695 and RFC 2544, it lacks clarity.

5. It will be more clear if there is mapping table between metric defined in
section 4 and parameters in the reporting format specified in section 3.

6. Section 2.3 said:
"Some Layer 2 technologies, like POS or Point-to-Point (PPP), have bit- or byte-
 stuffing, and [RFC4814] may help to calculate real performance more
 accurately or else a 1-2% error is expected."
which type of error do we expect here? Are there any other significant sources
of measurement errors?

## Minor comment

1. The procedure specified in section 4.1.1,4.1.2,4.1.3,4.1.4 looks same,
suggest to remove duplication, e.g., for procedure which is subsequent to
section 4.1.1,  we can say "same as section 4.1.1" 2. Move the following
paragraph to Discussion bullet "
      In the case of SR-MPLS, the SID list is PUSHed to the MPLS label
      stack.  It is similar to label Push or LSP Ingress forwarding
      operation, as per Section 6.1.1 of [RFC5695] and Section 26.1 of
      [RFC2544].

      In the case of SRv6, the received packet is encapsulated in an
      IPv6 outer header including the SRH as a Routing Extension Header.
      The Segment List in the SRH is composed of SIDs and the Source SR
      node sets the first SID of the SR Policy as the IPv6 Destination
      Address of the packet.  The RECOMMENDED headend behavior is
      H.Encaps, in case of interest for another behavior (H.Encaps.Red
      or H.Encaps.L2 or H.Encaps.L2.Red) it is OPTIONAL to test it with
      proper reporting.  Additionally, the router could be configured
      for NEXT-C-SID or REPLACE-C-SID compression.
"
3. s/Reporting parameter preserved from/Reporting parameter inherited from