Re: [bmwg] bmwg Digest, Vol 200, Issue 6
Sudhin <sudhinjacob@rediffmail.com> Thu, 17 June 2021 10:22 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 1D2683A1897 for <bmwg@ietfa.amsl.com>; Thu, 17 Jun 2021 03:22:25 -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=unavailable 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 2S6FLjTIs0z7 for <bmwg@ietfa.amsl.com>; Thu, 17 Jun 2021 03:22:20 -0700 (PDT)
Received: from rediffmail.com (f4mail-235-125.rediffmail.com [202.137.235.125]) (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 968213A1898 for <bmwg@ietf.org>; Thu, 17 Jun 2021 03:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rediffmail.com; s=mail; t=1623925335; bh=O+g3PzS9H8ApMeWf9DshcLqCRwqlU0NEM9P30ZBe1B8=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=Reijv9FbjsPj3ClP+kylPM/TvVoyKrXgzMC5pmkcpvvbV/nsyR8mj0oMh31o7LOrv +id7Gy3xwDZ+KXlAtZFMs3zCvtw8Yog6tRx4wbaAsllKng2wlu5euRCMX/rE1MFALi UFkCm+ryqaM1UuEbqcgLRnQAGY6bHAhX3G3b1YHE=
Received: (qmail 24351 invoked by uid 510); 17 Jun 2021 10:22:15 -0000
x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd;
X-OUT-VDRT-SpamState: 0\LEGIT
X-OUT-VDRT-SpamScore: 0
X-OUT-VDRT-SpamCause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefuddgvdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecufdftgfffkffhhfdpqfgfvfdfnecuuegrihhlohhuthemuceftddtnecunecujfgurhepffggvffkjghsuffhtgesrgdtreertddtjeenucfhrhhomhepfdfuuhguhhhinhdfuceoshhuughhihhnjhgrtghosgesrhgvughifhhfmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeejkeegueevffeghedvudfgfedthedtudejfedtheeufeeuveettddtjeekjeehjeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvtddvrdekfedrheelrdduudegnecuufhprghmkfhppfgvthifohhrkhepvddtvddrkeefrdehledruddugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht
X-Remote-IP: 202.83.59.114
X-REDF-OSEN: sudhinjacob@rediffmail.com
Date: Thu, 17 Jun 2021 10:22:14 -0000
MIME-Version: 1.0
To: "bmwg@ietf.org" <bmwg@ietf.org>
Received: from unknown 202.83.59.114 by rediffmail.com via HTTP; 17 Jun 2021 10:22:14 -0000
X-Senderscore: D=0&S=0
Message-ID: <1623870071.S.8707.15529.f5-147-235.1623925334.24220@webmail.rediffmail.com>
In-Reply-To: <mailman.45.1623870023.5395.bmwg@ietf.org>
Sender: sudhinjacob@rediffmail.com
From: Sudhin <sudhinjacob@rediffmail.com>
Cc: rtg-dir@ietf.org
Content-Type: multipart/alternative; boundary="=_e815f7a7c04732e26b76056bb8960dea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/nXORqTosm5b0pIdsDJ44LHImIH8>
Subject: Re: [bmwg] bmwg Digest, Vol 200, Issue 6
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, 17 Jun 2021 10:22:25 -0000
Hi Joel, Thank you for the comments. Appreciate it. Kindly find the answers inline and the modification will be done shortly, I will update the new version in a couple of days. Regards, Sudhin From: bmwg-request@ietf.org Sent: Thu, 17 Jun 2021 00:31:11 To: bmwg@ietf.org Subject: bmwg Digest, Vol 200, Issue 6 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 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. Rtgdir last call review of draft-ietf-bmwg-evpntest-08 (Joel Halpern via Datatracker) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Jun 2021 11:59:12 -0700 From: Joel Halpern via Datatracker <noreply@ietf.org> To: <rtg-dir@ietf.org> Cc: bmwg@ietf.org, draft-ietf-bmwg-evpntest.all@ietf.org, last-call@ietf.org Subject: [bmwg] Rtgdir last call review of draft-ietf-bmwg-evpntest-08 Message-ID: <162386995210.13675.8048702439794738383@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" Reviewer: Joel Halpern Review result: Has Issues I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-name-version.txt Reviewer: your-name Review Date: date IETF LC End Date: date-if-known Intended Status: copy-from-I-D Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Comments: N/A Minor Comments: Reading section 3.1 on the rate for learning addresses, I am left guessing how the procedure is to be performed. The text references RFC 2889 section 5.8, but only for the meaning for the terms. The test procedure is clearly different since that test relies on observing flooding. As best I can guess, the test assumes that there is an observable (Netconf ? YANG ?) variable that reports how many local MAC addresses the device under test has learned. It would be good to be more explicit about that, if possible pointing to the YANG module that defines the parameter to be observed. A similar clarification would be helpful on section 3.2 (on control plane MAC learning). It probably would be helpful if sections 3.3 and 3.4 then referenced sections 3.1 and 3.2 respectively for what is being observed. This probably applies to section 4 as well. If the same variables are to be used, then a simple reference to the earlier description would seem to suffice. Sudhin>>>> it must be generic because not all the evpn features are supported in Yang models and it is up to the user choice that is reason any specific ways to capture the data is omitted. I believe that section 3.8 on high availability is intended to cause a switch of traffic path from DUT to MHPE2. However, the text in that section never refers to MHPE 2. It refers to switch of routing processor. It is possible that this is intended to be a redundancy test within DUT. If so, it would help to be more explicit, since as far as I know we do not standardize that behavior. I am left puzzled as to the need for MHPE2 in these tests. I assume there is some obvious and simple reason for including it that I missed. Could you add an explanation? Sudhin>>> MHPE2 is very much needed in multi homing scenario, it plays as a standby role in testing, sure will add an explnation in the section "Test Setup Configuration". Nits: At the end of section 2, the text reads "The X is used as variable..." Could you change that to "The X below is used as a variable ..."? I spent some time looking backwards for the X. Sudhin >>>> Sure The equation at the end of section 3.9 (ARD / ND scaling) is somewhat misleading. It uses the same v1, v2, ..vn in successive lines to implicitly refer to the IPv4 measurements and the IPv6 measurements. It would be good to name these separately, as obviously the same calculation can not produce two different results. Sudhin>>> sure will change. ------------------------------ Subject: Digest Footer _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg ------------------------------ End of bmwg Digest, Vol 200, Issue 6 ************************************