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

Sarah Banks <sbanks@encrypted.net> Tue, 25 May 2021 16:25 UTC

Return-Path: <sbanks@encrypted.net>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E770A3A13EE for <bmwg@ietfa.amsl.com>; Tue, 25 May 2021 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfFcZFHMTRAF for <bmwg@ietfa.amsl.com>; Tue, 25 May 2021 09:25:53 -0700 (PDT)
Received: from xyz.hosed.xyz (xyz.hosed.xyz [71.114.67.91]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9770A3A1471 for <bmwg@ietf.org>; Tue, 25 May 2021 09:25:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xyz.hosed.xyz (Postfix) with ESMTP id C934C13C1D86; Tue, 25 May 2021 12:25:49 -0400 (EDT)
X-Virus-Scanned: Debian amavisd-new at xyz.hosed.xyz
Received: from xyz.hosed.xyz ([127.0.0.1]) by localhost (xyz.hosed.xyz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZicyJo2Pv9hb; Tue, 25 May 2021 12:25:49 -0400 (EDT)
Received: from [172.16.12.111] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by xyz.hosed.xyz (Postfix) with ESMTPSA id 4367013C09A8; Tue, 25 May 2021 12:25:49 -0400 (EDT)
From: Sarah Banks <sbanks@encrypted.net>
Message-Id: <4C5B873B-3737-4CDA-8C53-9464EC059536@encrypted.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94A1A5B4-9FF8-4460-9A51-42BE51A21C3B"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 25 May 2021 09:25:48 -0700
In-Reply-To: <1621882843.S.9349.2850.f4-234-197.1621944191.18932@webmail.rediffmail.com>
Cc: "bmwg@ietf.org" <bmwg@ietf.org>
To: Sudhin <sudhinjacob=40rediffmail.com@dmarc.ietf.org>
References: <1621882843.S.9349.2850.f4-234-197.1621944191.18932@webmail.rediffmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/rXX1JFSQsBHV_NZyxC_9ge0lQhg>
Subject: Re: [bmwg] bmwg Digest, Vol 199, Issue 15
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 16:25:58 -0000

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=40rediffmail.com@dmarc.ietf.org> wrote:
> 
> Dear All,
> 
> Thanks for the feedback. I will update with the comments soon. Please see my comments inline.
> 
> Regards,
> Sudhin
> 
> From: bmwg-request@ietf.org
> Sent: Tue, 25 May 2021 00:30:43
> To: bmwg@ietf.org
> Subject: bmwg Digest, Vol 199, Issue 15
> 
> Send bmwg mailing list submissions to
>    bmwg@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    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
>    bmwg-request@ietf.org
> 
> You can reach the person managing the list at
>    bmwg-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> 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)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 24 May 2021 13:51:44 +0200
> From: Edwin Cordeiro <edwin@scordeiro.net>
> To: draft-lencse-bmwg-benchmarking-stateful@ietf.org, bmwg@ietf.org
> Subject: [bmwg] draft-lencse-bmwg-benchmarking-stateful
> Message-ID:
>    <CAERpkxBMxSsMZhSPHrRAptZkxyFPmMZfj=O29aSzC-Op9Kb5QA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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>>> 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: <https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20210524/02bd5383/attachment.htm <https://mailarchive.ietf.org/arch/browse/bmwg/attachments/20210524/02bd5383/attachment.htm==>>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 24 May 2021 09:24:44 -0700
> From: Ines Robles via Datatracker <noreply@ietf.org>
> To: <gen-art@ietf.org>
> Cc: bmwg@ietf.org, draft-ietf-bmwg-evpntest.all@ietf.org,
>    last-call@ietf.org
> Subject: [bmwg] Genart last call review of draft-ietf-bmwg-evpntest-07
> Message-ID: <162187348479.26422.14629939836393101285@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq==>>.
> 
> 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.  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
> EVPN (PBB-EVPN) is defined in RFC 7623, discussing how can be combined with
> EVPNs to provide a new/combined solution...."
> 
> Thank you for this document,
> 
> Ines
> 
> Sudhin>>>> 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 <noreply@ietf.org>
> To: <tsv-art@ietf.org>
> Cc: bmwg@ietf.org, draft-ietf-bmwg-evpntest.all@ietf.org,
>    last-call@ietf.org
> Subject: [bmwg] Tsvart last call review of draft-ietf-bmwg-evpntest-07
> Message-ID: <162187790509.16740.4321707014094930863@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Reviewer: Jana Iyengar
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document'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
> tsv-art@ietf.org 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):
>  "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."
> Perhaps something like the following for defining CPU spikes might be helpful:
> "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
> 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>>> 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
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg <https://www.ietf.org/mailman/listinfo/bmwg==>
> 
> 
> ------------------------------
> 
> End of bmwg Digest, Vol 199, Issue 15
> *************************************
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg