Subject: Re: [bmwg] bmwg Digest, Vol 199, Issue 15

From: "Sudhin" <[email-masked]>
Date: 25 May 2021 12:03:11 -0000

Dear All,

Thanks for the feedback. I will update with the comments soon. Please see my comments inline.

Regards,
Sudhin

From: [email-masked]
Sent: Tue, 25 May 2021 00:30:43
To: [email-masked]
Subject: bmwg Digest, Vol 199, Issue 15

Send bmwg mailing list submissions to
&nbsp;&nbsp;&nbsp;[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
&nbsp;&nbsp;&nbsp;https://www.ietf.org/mailman/listinfo/bmwg
or, via email, send a message with subject or body &#39;help&#39; to
&nbsp;&nbsp;&nbsp;[email-masked]

You can reach the person managing the list at
&nbsp;&nbsp;&nbsp;[email-masked]

When replying, please edit your Subject line so it is more specific
than &quot;Re: Contents of bmwg digest...&quot;

Today&#39;s Topics:

&nbsp; 1. draft-lencse-bmwg-benchmarking-stateful (Edwin Cordeiro)
&nbsp; 2. Genart last call review of draft-ietf-bmwg-evpntest-07
&nbsp; &nbsp; &nbsp;(Ines Robles via Datatracker)
&nbsp; 3. Tsvart last call review of draft-ietf-bmwg-evpntest-07
&nbsp; &nbsp; &nbsp;(Jana Iyengar via Datatracker)

----------------------------------------------------------------------

Message: 1
Date: Mon, 24 May 2021 13:51:44 +0200
From: Edwin Cordeiro &lt;[email-masked]&gt;
To: [email-masked], [email-masked]
Subject: [bmwg] draft-lencse-bmwg-benchmarking-stateful
Message-ID:
&nbsp;&nbsp;&nbsp;&lt;CAERpkxBMxSsMZhSPHrRAptZkxyFPmMZfj=[email-masked]&gt;
Content-Type: text/plain; charset=&quot;utf-8&quot;

Dear authors of draft-lencse-bmwg-benchmarking-stateful,

I agree with the motivation and ideas of the draft and I support its
adoption.

I recommend that the TCP considerations for such benchmarking methodology
should not be left for a future document, as TCP still is the most used
protocol. So, the details on TCP difficulties and an extension of this
benchmark to consider TCP, should be in the scope of this document.

Sudhin&gt;&gt;&gt; Appreciate your feedback. Since the test focus on the Mac addresses, the transport layer is beyond the scope of the draft.(payload can be udp or tcp)

Best regards,

Edwin Cordeiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: &lt;https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20210524/02bd5383/attachment.htm&gt;

------------------------------

Message: 2
Date: Mon, 24 May 2021 09:24:44 -0700
From: Ines Robles via Datatracker &lt;[email-masked]&gt;
To: &lt;[email-masked]&gt;
Cc: [email-masked], [email-masked],
&nbsp;&nbsp;&nbsp;[email-masked]
Subject: [bmwg] Genart last call review of draft-ietf-bmwg-evpntest-07
Message-ID: &lt;[email-masked]&gt;
Content-Type: text/plain; charset=&quot;utf-8&quot;

Reviewer: Ines Robles
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. &nbsp;Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

&lt;https://trac.ietf.org/trac/gen/wiki/GenArtfaq&gt;.

Document: draft-ietf-bmwg-evpntest-07
Reviewer: Ines Robles
Review Date: 2021-05-24
IETF LC End Date: 2021-05-24
IESG Telechat date: Not scheduled for a telechat

Summary:

This document defines methodologies for benchmarking Ethernet VPN (EVPN) and
Provider Backbone Bridging EVPN (PBB-EVPN) performance. This document is
Informational. No major issues found.

Major issues: None

Minor issues: None

Nits/editorial comments:
- Check punctuation, some sentences do not start with space after period. &nbsp;e.g.
page 16 &quot;... sample.The time ...&quot; - Some paragraphs do not start with
upper-case letter. e.g. page 10, &quot;confirm the DUT...&quot; - I would expand PBB-EVPN
the first time used. &nbsp;Perhaps in the introduction, &quot;Provider Backbone Bridging
EVPN (PBB-EVPN) is defined in RFC 7623, discussing how can be combined with
EVPNs to provide a new/combined solution....&quot;

Thank you for this document,

Ines

Sudhin&gt;&gt;&gt;&gt; Thank you for the feedback, sure page 10 and page 16 will be corrected.

------------------------------

Message: 3
Date: Mon, 24 May 2021 10:38:25 -0700
From: Jana Iyengar via Datatracker &lt;[email-masked]&gt;
To: &lt;[email-masked]&gt;
Cc: [email-masked], [email-masked],
&nbsp;&nbsp;&nbsp;[email-masked]
Subject: [bmwg] Tsvart last call review of draft-ietf-bmwg-evpntest-07
Message-ID: &lt;[email-masked]&gt;
Content-Type: text/plain; charset=&quot;utf-8&quot;

Reviewer: Jana Iyengar
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team&#39;s
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document&#39;s
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

The document seems fine overall. There are some minor grammar and consistency
things, but I expect that the RFC-editors will handle those.

The one thing that stuck out to me is the following: It helps in documents such
as this to be more precise about exactly what a measurement tool or tester
should consider success or failure. One piece of text where this precision
should be improved is in the Soak Test (both 3.12 and 4.11):
&nbsp;&quot;The CPU spike is determined as the CPU usage which shoots at 40 to 50
&nbsp;percent of the average usage.
&nbsp; &nbsp;The average value vary from device to device. &nbsp;Memory leak is determined
&nbsp; by increase usage of the memory for EVPN process. &nbsp;The expectation is
&nbsp; under steady state the memory usage for EVPN process should not
&nbsp; increase.&quot;
Perhaps something like the following for defining CPU spikes might be helpful:
&quot;A CPU spike is defined as a sudden increase and subsequent decrease in usage
from average usage to about 150% of average usage.&quot; Similarly, memory leak is
very weakly defined. Do you mean _any increase_ in memory usage, or is there a
threshold that you want to propose? Do you mean consistent increase over time?
Can you define a leak more precisely in the context of your test?

Sudhin&gt;&gt;&gt; Memory leak means there is change in memory usage for a particular process with respect to increase in time.
The expectation is process memory should be same in all the sampled time intervals. Sure I will provide more information.

------------------------------

Subject: Digest Footer

_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

------------------------------

End of bmwg Digest, Vol 199, Issue 15
*************************************

---

From: Sarah Banks <[email-masked]>
Date: Tue, 25 May 2021 09:25:48 -0700

Hi Sudhin,
   With the change in your email address, I wanted to confirm that you've seen the reviews and feedback that came in from Robert Sparks, Jana Iyengar, and Ines Robles? You'll find this too in the BMWG email archives (in the short term), and you should update your email address on the draft/datatracker at your earliest convenience as well, if you haven't done that yet.

Thank you,
Sarah

> On May 25, 2021, at 5:03 AM, Sudhin <sudhinjacob=[email-masked]> wrote:
> 
> Dear All,
> 
>    https://www.ietf.org/mailman/listinfo/bmwg <https://www.ietf.org/mailman/listinfo/bmwg==>
> or, via email, send a message with subject or body 'help' to
>    [email-masked]
> 
>    [email-masked]
> than "Re: Contents of bmwg digest..."
> 
> 
> Today's Topics:
> 
>   1. draft-lencse-bmwg-benchmarking-stateful (Edwin Cordeiro)
>   2. Genart last call review of draft-ietf-bmwg-evpntest-07
>      (Ines Robles via Datatracker)
>   3. Tsvart last call review of draft-ietf-bmwg-evpntest-07
>      (Jana Iyengar via Datatracker)
> 
> 
> From: Edwin Cordeiro <[email-masked]>
>    <CAERpkxBMxSsMZhSPHrRAptZkxyFPmMZfj=[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Sudhin>>> Appreciate your feedback. Since the test focus on the Mac addresses, the transport layer is beyond the scope of the draft.(payload can be udp or tcp)
> 
> Best regards,
> 
> Edwin Cordeiro
> URL: <https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20210524/02bd5383/attachment.htm <https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20210524/02bd5383/attachment.htm==>>
> 
> From: Ines Robles via Datatracker <[email-masked]>
> To: <[email-masked]>
>    [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Ines Robles
> Review result: Ready
> 
> by the IESG for the IETF Chair.  Please treat these comments just
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq==>>.
> 
> - Check punctuation, some sentences do not start with space after period.  e.g.
> page 16 "... sample.The time ..." - Some paragraphs do not start with
> upper-case letter. e.g. page 10, "confirm the DUT..." - I would expand PBB-EVPN
> the first time used.  Perhaps in the introduction, "Provider Backbone Bridging
> EVPNs to provide a new/combined solution...."
> 
> Sudhin>>>> Thank you for the feedback, sure page 10 and page 16 will be corrected.
> 
> 
> 
> 
> 
> From: Jana Iyengar via Datatracker <[email-masked]>
> To: <[email-masked]>
>    [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Jana Iyengar
> This document has been reviewed as part of the transport area review team's
> primarily for the transport area directors, but are copied to the document's
>  "The CPU spike is determined as the CPU usage which shoots at 40 to 50
>  percent of the average usage.
>    The average value vary from device to device.  Memory leak is determined
>   by increase usage of the memory for EVPN process.  The expectation is
>   under steady state the memory usage for EVPN process should not
>   increase."
> "A CPU spike is defined as a sudden increase and subsequent decrease in usage
> from average usage to about 150% of average usage." Similarly, memory leak is
> Sudhin>>> Memory leak means there is change in memory usage for a particular process with respect to increase in time.
> https://www.ietf.org/mailman/listinfo/bmwg <https://www.ietf.org/mailman/listinfo/bmwg==>
> 
>

---

From: "Sudhin" <[email-masked]>
Date: 26 May 2021 02:37:49 -0000

Hi Sarah,

I saw the comments and I had replied. I need to update the draft with my new email address. I will do it in the coming weekend.

Regards,
Sudhin

From: Sarah Banks &lt;[email-masked]&gt;
Sent: Tue, 25 May 2021 21:56:13
To: Sudhin &lt;[email-masked]&gt;
Cc: &quot;[email-masked]&quot; &lt;[email-masked]&gt;
Subject: Re: [bmwg] bmwg Digest, Vol 199, Issue 15

Hi Sudhin,&nbsp; &nbsp;With the change in your email address, I wanted to confirm that you&#39;ve seen the reviews and feedback that came in from Robert Sparks, Jana Iyengar, and Ines Robles? You&#39;ll find this too in the BMWG email archives (in the short term), and you should update your email address on the draft/datatracker at your earliest convenience as well, if you haven&#39;t done that yet.
&nbsp;
Thank you,
Sarah
&nbsp;&nbsp;On May 25, 2021, at 5:03 AM, Sudhin &lt;sudhinjacob=[email-masked]&gt; wrote:&nbsp;
Dear All,

Regards,
Sudhin

Today&#39;s Topics:

Message: 1

Best regards,

Edwin Cordeiro
-------------- next part --------------

Message: 2

Reviewer: Ines Robles
Review result: Ready

Summary:

Major issues: None

Minor issues: None

Nits/editorial comments:

Ines

Message: 3

Reviewer: Jana Iyengar

Subject: Digest Footer