Re: [bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-evpntest-09: (with DISCUSS and COMMENT)

Sudhin <sudhinjacob@rediffmail.com> Thu, 01 July 2021 07:03 UTC

Return-Path: <sudhinjacob@rediffmail.com>
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 DAB0A3A1849 for <bmwg@ietfa.amsl.com>; Thu, 1 Jul 2021 00:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rediffmail.com
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 Bxg0bG-XaAg6 for <bmwg@ietfa.amsl.com>; Thu, 1 Jul 2021 00:03:14 -0700 (PDT)
Received: from rediffmail.com (f4mail-235-219.rediffmail.com [202.137.235.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254BB3A184A for <bmwg@ietf.org>; Thu, 1 Jul 2021 00:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rediffmail.com; s=mail; t=1625122985; bh=AmM5Mff25PtqplcaP424/iRTHb3/2QArmI81Df5hP3o=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=mSAy2dEm92WgQh+rQwkIkzSDirDD/u+4v9mChKHc5S8h1jdSDxvnucV06QJnW+Uaf VYKAE6TuzoVTaebDQOouYFvl81jXsBjDJw49yx/LK+IEvgW0ttC1EPvaeEsT2ThBY9 MhmMNVQTkJvD6KGMbbATFW1DCD1dybC+DTSeLfsQ=
Received: (qmail 4548 invoked by uid 510); 1 Jul 2021 07:03:05 -0000
x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd;
X-OUT-VDRT-SpamState: 0\LEGIT
X-OUT-VDRT-SpamScore: -100
X-OUT-VDRT-SpamCause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeihedgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucdftffgfffkhffhpdfqfgfvfdenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepffggvffkjghsuffhtgesrgdtreertddtjeenucfhrhhomhepfdfuuhguhhhinhdfuceoshhuughhihhnjhgrtghosgesrhgvughifhhfmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeejkeegueevffeghedvudfgfedthedtudejfedtheeufeeuveettddtjeekjeehjeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvtddvrdekfedrheelrddufeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth
X-Remote-IP: 202.83.59.138
X-REDF-OSEN: sudhinjacob@rediffmail.com
Date: Thu, 01 Jul 2021 07:03:05 -0000
MIME-Version: 1.0
To: "superuser@gmail.com" <superuser@gmail.com>
Received: from unknown 202.83.59.138 by rediffmail.com via HTTP; 01 Jul 2021 07:03:04 -0000
X-Senderscore: D=0&S=0
Message-ID: <1625121552.S.5935.4235.f4-234-159.1625122984.4283@webmail.rediffmail.com>
In-Reply-To: <162512154570.25081.5963216218579186608@ietfa.amsl.com>
Sender: sudhinjacob@rediffmail.com
From: Sudhin <sudhinjacob@rediffmail.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bmwg-evpntest@ietf.org" <draft-ietf-bmwg-evpntest@ietf.org>, "bmwg-chairs@ietf.org" <bmwg-chairs@ietf.org>, "bmwg@ietf.org" <bmwg@ietf.org>, Sarah Banks <sbanks@encrypted.net>
Content-Type: multipart/alternative; boundary="=_9d9ec035b305f659a08ef28f7c373e90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/Oi8beGK6zBMvggYxBF1IzKrp7vo>
Subject: Re: [bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-evpntest-09: (with DISCUSS and COMMENT)
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: Thu, 01 Jul 2021 07:03:19 -0000

Hi All,

Thanks for the comments. Please see the reply inline.

Regards,
Sudhin

From: Murray Kucherawy via Datatracker &lt;noreply@ietf.org&gt;
Sent: Thu, 01 Jul 2021 12:09:12
To: &quot;The IESG&quot; &lt;iesg@ietf.org&gt;
Cc: draft-ietf-bmwg-evpntest@ietf.org, bmwg-chairs@ietf.org, bmwg@ietf.org, Sarah Banks &lt;sbanks@encrypted.net&gt;
Subject: Murray Kucherawy&#39;s Discuss on draft-ietf-bmwg-evpntest-09: (with DISCUSS and COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-bmwg-evpntest-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-evpntest/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The tests in Sections 3.3, 3.4, 4.3, and 4.4 each define two distinct things to
be measured, but they appear to refer to themselves using a common name. &nbsp;Feels
like some text copy-paste happened here from previous sections, but wasn&#39;t
fully developed. &nbsp;For instance, Section 3.3 says:

Sudhin&gt;&gt;&gt; Test cases are same but the technologies are different one is EVPN and another is pub-evpn. This is highlighted in at section 4.

&nbsp; Measure the time taken for flushing these X MAC addresses. &nbsp;Measure
&nbsp; the time taken to relearn these X MAC in DUT. &nbsp;The test is repeated
&nbsp; for N times and the values are collected. &nbsp;The flush and the
&nbsp; relearning time is calculated by averaging the values obtained by N
&nbsp; samples. &nbsp;N is an arbitrary number to get a sufficient sample. &nbsp;The
&nbsp; time measured for each sample is denoted by T1,T2...Tn. &nbsp;The
&nbsp; measurement is carried out using external server which polls the DUT
&nbsp; using automated scripts which measures the MAC counter value with
&nbsp; timestamp.

&nbsp; Flush rate = (T1+T2+..Tn)/N

&nbsp; Relearning rate = (T1+T2+..Tn)/N

So you finish the definition appearing to define two distinct things using the
same arithmetic over a single time series. &nbsp;In other words, you call two
different time series by the same name, and then give an identical formal
definition for what are really two different measurements.

It seems to me what you actually meant was for these to be, maybe,
&quot;F1+F2+..+Fn&quot; for the flush rate and &quot;R1+R2+..+Rn&quot; for the relearning rate,
which makes it clear they are distinct quantities.

Sudhin&gt;&gt;&gt; This is sampling interval sure will change.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Martin and Eric&#39;s DISCUSS positions about how some of the tests are
characterized.

Like Eric, I found the number of typos, capitalization mistakes, and sentence
fragments to be distracting.

Though its coverage of the WG process was good, the shepherd writeup declares
the document status but avoided answering the other questions about its status
(e.g., &quot;Why is this the proper type of RFC?&quot;). &nbsp;This seems to be a common
omission, and I&#39;m starting to wonder if we should just drop it from the
template.

I think RFC 7432 and RFC 7623 should be normative, insofar as this document
doesn&#39;t really make sense unless one understands those first.

Sudhin&gt;&gt;&gt; Sure will add to it from the informational to normative.

Please use the correct boilerplate for BCP 14. &nbsp;(See RFC 8174, Section 2.)
However, I also note that the only place the key words are used is Section 7,
so it occurs to me you could avoid using BCP 14 altogether and basically say
the same thing with the same force.

Section 1.2 defines &quot;All-Active Redundancy Mode&quot;, but it&#39;s not used anywhere in
this document other than its own definition. &nbsp;Similarly, &quot;AA&quot;, &quot;ES&quot;, &quot;Ethernet
Tag&quot;, &quot;RT&quot;, and &quot;Sub interface&quot; don&#39;t appear anywhere else. &nbsp;&quot;Single-Active
Redundancy Mode&quot; could be folded into the definition of &quot;SA&quot;, since the latter
is actually used elsewhere.

Sudhin&gt;&gt;&gt;&gt; Those terms are needed.


&nbsp;