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

From: "Sudhin" <[email-masked]>
Date: 1 Jul 2021 07:03:05 -0000

Hi All,

Thanks for the comments. Please see the reply inline.

Regards,
Sudhin

From: Murray Kucherawy via Datatracker &lt;[email-masked]&gt;
Sent: Thu, 01 Jul 2021 12:09:12
To: &quot;The IESG&quot; &lt;[email-masked]&gt;
Cc: [email-masked], [email-masked], [email-masked], Sarah Banks &lt;[email-masked]&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;

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jul 2021 00:54:54 -0700

On Thu, Jul 1, 2021 at 12:03 AM Sudhin <[email-masked]> wrote:

> Section 1.2 defines "All-Active Redundancy Mode", but it's not used
> anywhere in
> this document other than its own definition.  Similarly, "AA", "ES",
> "Ethernet
> Tag", "RT", and "Sub interface" don't appear anywhere else.  "Single-Active
> Redundancy Mode" could be folded into the definition of "SA", since the
> latter
> Sudhin>>>> Those terms are needed.
>

Where?

-MSK

---

From: "Sudhin" <[email-masked]>
Date: 1 Jul 2021 08:52:32 -0000

Hi Murray,

Most of the terms are used in test setup configuration. A couple of terms like like AA might not be used explicitly.&nbsp;

Regards,
Sudhin

From: &quot;Murray S. Kucherawy&quot; &lt;[email-masked]&gt;
Sent: Thu, 01 Jul 2021 13:25:07
To: Sudhin &lt;[email-masked]&gt;
Cc: The IESG &lt;[email-masked]&gt;, &quot;[email-masked]&quot; &lt;[email-masked]&gt;, &quot;[email-masked]&quot; &lt;[email-masked]&gt;, &quot;[email-masked]&quot; &lt;[email-masked]&gt;, Sarah Banks &lt;[email-masked]&gt;
Subject: Re: Murray Kucherawy&#39;s Discuss on draft-ietf-bmwg-evpntest-09: (with DISCUSS and COMMENT)
&nbsp;On Thu, Jul 1, 2021 at 12:03 AM Sudhin &lt;[email-masked]&gt; wrote:
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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jul 2021 02:14:19 -0700

On Thu, Jul 1, 2021 at 1:52 AM Sudhin <[email-masked]> wrote:

> Most of the terms are used in test setup configuration.
>

Just to be clear, this isn't part of my DISCUSS position so it's not
critical to resolve it.  I just think the document would be simpler with
unnecessary definitions removed.

Can you show me where any of the ones I listed, except for "SA", are
included in test setup configuration?

A couple of terms like like AA might not be used explicitly.

I don't understand why you would include a definition of "AA" if you don't
actually use it anywhere.

Specifically:

"All-Active Redundancy Mode" appears nowhere in the document other than its
own definition.  It may be an interesting or important concept, but it
appears to be unrelated to the rest of this document, and it would thus be
simpler to remove it.

Neither "AA" nor "All-Active" are present anywhere in the document other
than the Terminology section.  You could remove them and the document reads
the same way.

"Ethernet Segment" only appears in the Terminology section, as part of its
own definition or of other definitions.  "ES" appears nowhere.  They could
also be removed.

"RT" appears nowhere.  "Traffic generator" does, but not "RT".  Maybe you
should define "Traffic generator" instead of "RT"?

"Sub interface" doesn't appear anywhere.  Why does it need to be defined?

"Single-Active Redundancy Mode" defines itself, and then "SA" is introduced
as a short form for it and is actually used in several places.  I would
suggest replacing those two with this one:

SA: Single-Active Redundancy Mode. When a single PE (among all the PEs
   attached to an Ethernet segment) is the only PE allowed to forward
   traffic to/from a given Ethernet segment for a given VLAN, then that
   Ethernet segment is defined to be operating in Single-Active
   Redundancy Mode.