Subject: [bmwg] [Technical Errata Reported] RFC8239 (6768)

From: RFC Errata System <[email-masked]>
Date: Wed, 1 Dec 2021 00:44:12 -0800 (PST)

The following errata report has been submitted for RFC8239,
"Data Center Benchmarking Methodology".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6768

--------------------------------------
Type: Technical
Reported by: Leonard Yu <[email-masked]>

Section: 3.2

Original Text
-------------
3) Measure maximum port pair buffer sizes.

      o  First iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 2 and port 3, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Second iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 4 and port 5, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Last iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port N-3 and port N-2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

Corrected Text
--------------
3) Measure maximum port pair buffer sizes.

      o  First iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 1 and port 2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Second iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port 3 and port 4, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

      o  Last iteration: Ingress port 1 sending line rate to egress
         port 2, ingress port 3 sending line rate to egress port 4, etc.
         Ingress port N-1 and port N will oversubscribe, at 1% of line
         rate, egress port N-3 and port N-2, respectively.  Measure the
         buffer size value by multiplying the number of extra frames
         sent by the frame size for each egress port.

Notes
-----
The oversubscribed ports are a pair of ingress and egress ports. The oversubscribed ports in the texts describing the first are port 2 & 3, which are incorrect, should be port 1 & 2. The oversubscribed ports in the texts describing the second are port 4 & 5, which are incorrect, should be port 3 & 4.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8239 (draft-ietf-bmwg-dcbench-methodology-18)
--------------------------------------
Title               : Data Center Benchmarking Methodology
Publication Date    : August 2017
Author(s)           : L. Avramov, J. Rapp
Category            : INFORMATIONAL
Source              : Benchmarking Methodology
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Dec 2021 15:28:44 -0500

Dear BMWG,

While trying to clean up my mailbox for the end of year, I realized that
this Errata had slipped through the cracks -- I believe that it is correct
and should be marked as "Verified", but would like another set of eyes (or
two!).

Please review and let me know...
W

On Wed, Dec 1, 2021 at 3:44 AM RFC Errata System <[email-masked]>
wrote:

> The oversubscribed ports are a pair of ingress and egress ports. The
> oversubscribed ports in the texts describing the first are port 2 & 3,
> which are incorrect, should be port 1 & 2. The oversubscribed ports in the
> texts describing the second are port 4 & 5, which are incorrect, should be
> port 3 & 4.
>
> Instructions:
> -------------

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 15 Dec 2021 20:55:42 +0000

Hi Warren, Thanks for following up on this!

Co-author Lucien and Errata reporter Leonard have been working together, both on and off-list, to determine the disposition of this Errata.  A big THANKS to you both!

Lucien indicated yesterday that they have agreed to prepare two clarifying paragraphs for a future version of RFC 8239. I think everyone involved (myself included) remembers the discussion of this topic during development, and now it appears that additional info might help keep questions from coming-up again.

So, assuming we verify the Errata, we are actually recognizing the need for additional clarifying text (not an error).  The current “open” status (while actively proceeding to resolution/agreement) works for me, until the two paragraphs are ready.

Lucien would like to quickly prepare RFC 8239bis for BMWG consideration in 2022, to incorporate this and any other Errata.

regards,
Al

From: Warren Kumari <[email-masked]>
Sent: Wednesday, December 15, 2021 3:29 PM
To: RFC Errata System <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; MORTON JR., AL <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Technical Errata Reported] RFC8239 (6768)

Dear BMWG,

While trying to clean up my mailbox for the end of year, I realized that this Errata had slipped through the cracks -- I believe that it is correct and should be marked as "Verified", but would like another set of eyes (or two!).

On Wed, Dec 1, 2021 at 3:44 AM RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
The following errata report has been submitted for RFC8239,
"Data Center Benchmarking Methodology".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6768<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6768__;!!BhdT!3MGoHan_emkRbK1UB0OhGgk4oMDYNi50wjsGI5DmHr5Zh_oCk9xfodZm3GzI$>

--------------------------------------
Type: Technical
Reported by: Leonard Yu <[email-masked]<mailto:[email-masked]>>

Section: 3.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Lucien <[email-masked]>
Date: Wed, 15 Dec 2021 13:20:37 -0800

Thank you Warren and Al,

You both beat me to update this thread.

We have been working with Leonard to clarify the RFC to help him implement
it and the original text is correct. The errata 6768 is incorrect (should
not be moved to Verified).
I would like to incorporate errata 5652 and also a more clear version of
the test section 3.2.3 in the RFC for future implementation (thank you
Leonard for raising this).
I will provide an updated text on this thread for 3.2.3 section meanwhile
once ready.

In addition I wanted to add that Leonard is working on implementing this
RFC and that Spirent
<https://www.spirent.com/assets/datasheet-rfc-8239-benchmarking> has
implemented it.

Thank you,
Lucien

On Wed, Dec 15, 2021 at 12:56 PM MORTON JR., AL <[email-masked]> wrote:

> Co-author Lucien and Errata reporter Leonard have been working together,
> both on and off-list, to determine the disposition of this Errata.  A big
> THANKS to you both!
>
>
>
> Lucien indicated yesterday that they have agreed to prepare two clarifying
> paragraphs for a future version of RFC 8239. I think everyone involved
> (myself included) remembers the discussion of this topic during
> development, and now it appears that additional info might help keep
> questions from coming-up again.
>
>
>
> So, assuming we verify the Errata, we are actually recognizing the need
> for additional clarifying text (not an error).  The current “open” status
> (while actively proceeding to resolution/agreement) works for me, until the
> two paragraphs are ready.
>
>
>
> Lucien would like to quickly prepare RFC 8239bis for BMWG consideration in
> 2022, to incorporate this and any other Errata.
>
>
>
> regards,
>
> Al
>
>
>
> *From:* Warren Kumari <[email-masked]>
> *Sent:* Wednesday, December 15, 2021 3:29 PM
> *To:* RFC Errata System <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> MORTON JR., AL <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Technical Errata Reported] RFC8239 (6768)
>
>
>
> Dear BMWG,
>
>
>
> On Wed, Dec 1, 2021 at 3:44 AM RFC Errata System <
> [email-masked]> wrote:
>
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6768__;!!BhdT!3MGoHan_emkRbK1UB0OhGgk4oMDYNi50wjsGI5DmHr5Zh_oCk9xfodZm3GzI$>
>