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

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 01 July 2021 09:14 UTC

Return-Path: <superuser@gmail.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 61A483A1EFE; Thu, 1 Jul 2021 02:14:37 -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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L_Mgt0cErVkD; Thu, 1 Jul 2021 02:14:32 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2892A3A1EFF; Thu, 1 Jul 2021 02:14:32 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id m24so3188534vsq.7; Thu, 01 Jul 2021 02:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v4FQTzSMSym0YYOSpwQEeHlwXGbIy8Rbysz95LL8o6E=; b=hbiHzm3NNsV1qoZ5cc2TAEh/tGaJNrEHTFf380tA2FX/S+YGhZ0YgO9Z4kYNI65Pky NfztU4G3EktWXI9cJ820YGjMjVNzlJ3fGwKgP7gKeWsZ/w5nhfW5j6FJuqgfPLp1v+uv Qd9mk8LOVZmHT/Dz9urfhK1G3pfE65fCP22xuV7xyo8LWcWno/5lRNIw4k6AKS5PCZef a0SMJMcbOncPeixEb2G+50ibbgdL9D3c+VYWtKUjcaGgsyCBrEuo+rfbsj3eDU0D4qUv li+aJ1n5BKbEReJ5al1Z1H8MLqtaL7FSuhCDSE6g30rojWOSJWeH2IBSHsfJyxSXOk6M mY8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v4FQTzSMSym0YYOSpwQEeHlwXGbIy8Rbysz95LL8o6E=; b=sfM4jg/8QJD8yFA9dSZQrnAh6ASxqBi7zTDukxhz3klf/unXM15nVsUWBBraMAwc6z PIFjLijULcNlvhIEAKxf7U21eBo6ughg2HqAu10umIsuQmWoDs3m9hNnUmJUgznCvZvd ezXVXAuFScfVCWxyb1x05hOvJjuknfNrmtEyxX08os+9s7vIfiBUwgDMWTGhKbzo/zx4 a+uQ5StLcSXVlVEHJGQLGDJA7UocuRNUzH/aHBc7tHoWQH6l8DMvb1BdJKJO96DtNKUw 6oyJSzttq7uKAdl9qro/8h/01HdRyU7tjRA48Wiej7/frQ2S25LifhgolZFnmcjvKIdz wzZg==
X-Gm-Message-State: AOAM5339VKG77pDZCgWvV6EalcRsTb0qEzwk4Vvl2z5ghKvQ9a7UPWHN YaCAjU6oVIWIGbhob0ByKxxE90zilFJF2/h/fp0=
X-Google-Smtp-Source: ABdhPJxV0AsW9/Q2wMLw8otZwsTYEwh3wxVEnObw4SREgSIbF3Y3xEhIg7sr2qsHl6ldtqgTRU5aUG6K7TgRJ/gV748=
X-Received: by 2002:a67:1a45:: with SMTP id a66mr37360337vsa.15.1625130870720; Thu, 01 Jul 2021 02:14:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwYyYsJWxE4xSfwNfVLfOsq=L_qhLjbNagcTAj3VLXcShw@mail.gmail.com> <1625126107.S.5547.27006.f4-234-185.1625129552.26932@webmail.rediffmail.com>
In-Reply-To: <1625126107.S.5547.27006.f4-234-185.1625129552.26932@webmail.rediffmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 01 Jul 2021 02:14:19 -0700
Message-ID: <CAL0qLwbR=XOXLxoiebu5f+iJmrk6puiySUBpTk0L7hnuMie9kg@mail.gmail.com>
To: 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="000000000000434be105c60c44f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/yME9A4kzA7IkgSX0P1z3qJCMFu8>
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 09:14:37 -0000

On Thu, Jul 1, 2021 at 1:52 AM Sudhin <sudhinjacob@rediffmail.com> 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.