[bmwg] Review for draft-vfv-bmwg-srmpls-bench-meth

Boris Khasanov <bhassanov@yandex-team.ru> Wed, 19 October 2022 14:34 UTC

Return-Path: <bhassanov@yandex-team.ru>
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 D0531C14CE46 for <bmwg@ietfa.amsl.com>; Wed, 19 Oct 2022 07:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.629
X-Spam-Level:
X-Spam-Status: No, score=-6.629 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, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex-team.ru
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PYcrNZxW0Aq for <bmwg@ietfa.amsl.com>; Wed, 19 Oct 2022 07:34:04 -0700 (PDT)
Received: from forwardcorp1a.mail.yandex.net (forwardcorp1a.mail.yandex.net [178.154.239.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8564AC14CE44 for <bmwg@ietf.org>; Wed, 19 Oct 2022 07:34:03 -0700 (PDT)
Received: from vla5-d6ec41cad181.qloud-c.yandex.net (vla5-d6ec41cad181.qloud-c.yandex.net [IPv6:2a02:6b8:c18:348f:0:640:d6ec:41ca]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTP id 151BC60055 for <bmwg@ietf.org>; Wed, 19 Oct 2022 17:34:01 +0300 (MSK)
Received: from mail.yandex-team.ru (mail.yandex-team.ru [2a02:6b8:b081:7226::1:e]) by vla5-d6ec41cad181.qloud-c.yandex.net (mxbackcorp/Yandex) with HTTP id qXijDA0474Y1-Y14uNdf5; Wed, 19 Oct 2022 17:34:01 +0300
X-Yandex-Fwd: 2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1666190041; bh=nn31rmLLwBf99C+FGNixlgifEcFBTFoEYbMgfsQvUSQ=; h=Date:Subject:To:From:Message-Id; b=pgiu8aIcv4do3hzuA7lTM2w/nCIj/HNwe25bcpVjHKgYm0pHGvud0BP/QpDSCCdiu bxZzzOlkurcImajfytz8NMZDDPK2qXpYBW8i8BXyNAuta5vPu5Ua9Cbn1yI55my/kH ex0RZk/nYLzKkIPPx58/ialSiLfHyasAp2ZXbZMQ=
Authentication-Results: vla5-d6ec41cad181.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru
Received: from qitgvz6tzqgj5t6m.vla.yp-c.yandex.net (qitgvz6tzqgj5t6m.vla.yp-c.yandex.net [2a02:6b8:c1f:6255:0:640:95c3:0]) by vla3-850de775f4df.qloud-c.yandex.net (mxbackcorp/Yandex) with HTTP id QXiuu903vGk1-9oSI6i43 for <bhassanov@yandex-team.ru>; Wed, 19 Oct 2022 17:33:51 +0300
Received: by qitgvz6tzqgj5t6m.vla.yp-c.yandex.net with HTTP; Wed, 19 Oct 2022 17:33:51 +0300
From: Boris Khasanov <bhassanov@yandex-team.ru>
To: "bmwg@ietf.org" <bmwg@ietf.org>
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Wed, 19 Oct 2022 17:34:01 +0300
Message-Id: <34621666176249@mail.yandex-team.ru>
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/V-yRWR2x7I2T3y3XA1aNS3E9kNE>
Subject: [bmwg] Review for draft-vfv-bmwg-srmpls-bench-meth
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 19 Oct 2022 14:34:08 -0000

Hi all,
Sorry for delay with the review which I promised at IETF-114 too. But better late than never.
 
I think that it is a right approach to mention that this draft is a complement to the RFC 5695 which have detailed methodology. More comments are below.
 
1) Item "2. SR-MPLS forwarding" has the following statement:  
"SR policy may be installed by PCEP [RFC8664], BGP [I-D.ietf-idr-segment-routing-te-policy], or via manual configuration on the router.  PCEP signaling can be the case of a controller-based deployment.  For all these reasons, SR Policies scale better than traditional TE mechanisms."
 
I would like to propose a slightly different version: "SR policy may be installed by PCEP [RFC8664], BGP [I-D.ietf-idr-segment-routing-te-policy], or via manual configuration on the router. PCEP  and BGP signaling  of SR Policies can be the case of a controller-based deployment. "
 
Obviously controller can communicate with a router for sending  SR Policy via both ways: PCEP and BGP SR Policy SAFI. Also  I think that a scalability topic for TE requires some more arguments for comparison and should be skipped  since this is out of scope of the draft. Also t SR Policy benchmarking methodology does require a separate draft, IMO.
 
2) item 3.2
"It is RECOMMENDED that at least one routing protocol (OSPF or ISIS or BGP) should be used for the construction of the simplest stack of 1 SID."
I understand that this was made similarly to the corresponding statement of RFC 5695. But  in current environment I would change RECOMMENDED to SHOULD. I seriously doubt that anyone nowadays/future will test SR performance without IGP.  
3)  3.3.  Frame Formats and Sizes
"RECOMMENDED frame sizes are the following:
   *  Ethernet Minimal: 64+n*4..."
I would add "where n =  #labels (SID Depth)"
 
4) 3.5.  Trial Duration
Wouldn't be better just use some static number for trial duration here?  RFC 5695 in the section 4.1.7 says: "
the test portion of each trial SHOULD be... no less than 200 seconds when a dynamic routing protocol..."
Why can't we say similarly like " Duration of each test trial SHOULD be not less than 250 seconds..."?

5) 
5.1.1.  Throughput for SR-MPLS PUSH, 
5.1.2.  Throughput for SR-MPLS NEXT,
5.1.3.  Throughput for SR-MPLS CONTINUE
etc.
I would add some more details for each test, like : " As in Section 6 of RFC 5695  the traffic is
 sent from test tool Tx  port(s) to the DUT at a constant load for a fixed-time interval, and is received from the DUT on test tool Rx port(s). 
If any frame loss is detected, then a new iteration is needed where the offered load is decreased and the sender will transmit
again.  An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss (No-Drop Rate - NDR).
Each iteration should involve varying the offered load of the traffic, while keeping the other parameters (test duration, number
of ports, number of addresses, frame size, etc.) constant, until the maximum rate at which none of the offered frames are dropped
is determined."
To make very short description of methodology, because currently it requires from the reader to go and read whole RFC 5695 and jump back and forth.
 
6) Item 5.6 Reset
I doubt that referal to the same section of RFC 5695 (6.5) is really helpful here, because RFC 5695 does not have enough details for reset operations. Instead I think that change RFC 6201 from OPTIONAL to SHOULD is needed. Also we need to explicitly clarify which label operations (PUSH, NEXT, CONT. or all of them ) have to be tested  with Reset.
 
Thank you.
 
SY,
Boris