[bmwg] Comments on: draft-vassilev-bmwg-network-interconnect-tester-02

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sat, 16 November 2019 12:27 UTC

Return-Path: <acm@research.att.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 00433120145 for <bmwg@ietfa.amsl.com>; Sat, 16 Nov 2019 04:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3kho1QeVjhxf for <bmwg@ietfa.amsl.com>; Sat, 16 Nov 2019 04:27:41 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com []) (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 370F2120127 for <bmwg@ietf.org>; Sat, 16 Nov 2019 04:27:41 -0800 (PST)
Received: from pps.filterd (m0049462.ppops.net []) by m0049462.ppops.net-00191d01. ( with SMTP id xAGCPWCs007320; Sat, 16 Nov 2019 07:27:39 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com []) by m0049462.ppops.net-00191d01. with ESMTP id 2wab8wdde9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Nov 2019 07:27:39 -0500
Received: from enaf.dadc.sbc.com (localhost []) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xAGCRcUE065835; Sat, 16 Nov 2019 06:27:38 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com []) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xAGCRSJf065302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Nov 2019 06:27:29 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com []) by zlp30496.vci.att.com (Service) with ESMTP id 99C54400AF90; Sat, 16 Nov 2019 12:27:28 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown []) by zlp30496.vci.att.com (Service) with ESMTP id 7B572400AE34; Sat, 16 Nov 2019 12:27:28 +0000 (GMT)
Received: from sldc.sbc.com (localhost []) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAGCRQaq010558; Sat, 16 Nov 2019 06:27:28 -0600
Received: from mail-green.research.att.com (mail-green.research.att.com []) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAGCRK9h010086; Sat, 16 Nov 2019 06:27:21 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com []) by mail-green.research.att.com (Postfix) with ESMTP id 21D0AE1D4B; Sat, 16 Nov 2019 07:23:43 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sat, 16 Nov 2019 07:27:05 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Vladimir Vassilev <vladimir@transpacket.com>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: Comments on: draft-vassilev-bmwg-network-interconnect-tester-02
Thread-Index: AdWcd6wKA6BeQni6Q+27XhUz10R+Dw==
Date: Sat, 16 Nov 2019 12:27:18 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6EF8E3D@njmtexg5.research.att.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-16_03:2019-11-15,2019-11-16 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 priorityscore=1501 phishscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 malwarescore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911160115
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/fPo68ghtZjEoN65pSasEeOSJ8Zc>
Subject: [bmwg] Comments on: draft-vassilev-bmwg-network-interconnect-tester-02
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: Sat, 16 Nov 2019 12:27:43 -0000

Hi Vladimir,

Thanks for your demo of the YANG control model today.

I have the following comments on your draft.

(As a Participant)


Vladimir has transported equipment to the IETF-106 Hackathon.
He will be available to demo the implementation of his draft

on Sunday, before 1400 local time, and again

at the Hack Demo Happy Hour, on Monday beginning at 1810.

Both locations are the Moor/Morrison Room.

Hope to see you there,
bmwg co-chair


1.3.  Solution

   The proposed model splits the design into 3 modules - 1) Traffic
   Generator module (TG), 2) Traffic Analyzer module (TA). 
Where's the third module?

   The modules
   are implemented as augmentations of the ietf-interfaces module adding
   configuration and state data that models the functionality of a
   tester.  The TA and TG modules concept is illustrated with the
   following diagram of a tester with two interfaces (named e0 and e1)
   conected in a loop with single DUT:
run a spell check  s/conected/connected/

2.  Using the network interconnect tester model

   Basic example of how the model can be used in transactional network
   test API to control the testers part of a network and report countrer
   statistics and timing measurement data is presented in Appendix A.
   One of the examples demonstrates the use of the [RFC2544] defined
   testframe packet.
It would be good to mention that the cases below assume that the 
search algorithm logic operates to control the generator and analyzer
for each trial  ->> unless they have an automated capability.

3.  Traffic Generator Module Tree Diagram

module: ietf-traffic-generator
  augment /if:interfaces/if:interface:
    +--rw traffic-generator {egress-direction}?
    |  +--rw (type)?
    |  |  +--:(single-stream)
    |  |  |  +--rw frame-size          uint32
Frame size can be variable - RFC2544's authors did not include this 
possibility but it is widely used. See RFC 6985, where we tried to 
make this testing more repeatable.


    |  |  +--:(multi-stream)
    |  |     +--rw streams
    |  |        +--rw stream* [id]
    |  |           +--rw id                   uint32
    |  |           +--rw frame-size           uint32
    |  |           +--rw (frame-data-type)?
    |  |           |  +--:(raw-frame-data)
    |  |           |     +--rw frame-data?    string
    |  |           +--rw interframe-gap       uint32
    |  |           +--rw interburst-gap?      uint32
    |  |           +--rw frames-per-burst?    uint32
    |  |           +--rw frames-per-stream    uint32
    |  |           +--rw interstream-gap      uint32
    |  |           +--rw src-mac-address?     yang:mac-address {ethernet}?
    |  |           +--rw dst-mac-address?     yang:mac-address {ethernet}?
How to control the range pf MAC addresses used for multi-frame?
Also, what about multiple IP-layer flows?

    |  |           +--rw ether-type?          uint16 {ethernet}?
    |  |           +--rw vlan {ethernet-vlan,ethernet}?
    |  |              +--rw id      uint16
    |  |              +--rw tpid?   uint16
    |  |              +--rw pcp?    uint8
    |  |              +--rw cfi?    uint8
As discussed in-person, lists of frame sizes, number of flows, etc. work
well for the case of Automated test tools.