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

[Lucien <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> *Sent:* Wednesday, December 15, 2021 3:29 PM
> *To:* RFC Errata System <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> MORTON JR., AL <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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!).
>
>
>
> Please review and let me know...
>
> W
>
>
>
> On Wed, Dec 1, 2021 at 3:44 AM RFC Errata System <
> [e-mail]> 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 <[e-mail]>
>
> 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
>
>
>
>
> --
>
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra
>