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

Vladimir Vassilev <vladimir@lightside-instruments.com> Sun, 17 November 2019 01:11 UTC

Return-Path: <vladimir@lightside-instruments.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 00A4D120812 for <bmwg@ietfa.amsl.com>; Sat, 16 Nov 2019 17:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.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 s3tKVLJGzX6C for <bmwg@ietfa.amsl.com>; Sat, 16 Nov 2019 17:11:45 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130082.outbound.protection.outlook.com [40.107.13.82]) (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 A5555120048 for <bmwg@ietf.org>; Sat, 16 Nov 2019 17:11:44 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kuOUtl7AeFhampS0bbZdTWaICGBGRXfwEw+981zVAZCWUEHlZEaLVisqwkiAeLyBmHD5Yco19DdDP0N8De026MFmR0BzyhlTmBTLf0yKDQ3sLJAbOvsZQCZQa4iEFa9UPvneee/jT4RB1Conguj9SK5o/KTk19WkatRX7d7It+kCdD3UgCiPgCi2kfKVOdKrdNX2BpvuAJV6ra087l66mhJyVtSGVGKMGfoLdL/pZHdM9T0KiqQem96BXJZ5NChwBzJts73Yok52yRDhJxGthA7sOkx73EKLUD30JXpt9yZVJdXtsO6H9UlnofWDrl/B9oJtl2qRRzCzRMiRzFMjpw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vOlgiyCflkOlkd4HymqhVfBXOrUzbwivA9r2LQMbJe0=; b=bSa3g5AWLoLhKDA54QPz8cTKZxyUgc2vyZfl+ldBFDixEtgPhFaaZpkhQhcjQQ9AxVj0cfhLs7Pye/8LJu1Yzv+36v+otsVeX1RiGiWuSMczCGKg6gnJfcPGmpBGO3oJKHaCDgXq1fDjNthjMC0j3Hm+CGWT+WArDG/P4GbEYGGV2TpG67euNv2uX4avUp8v6hU4PBIW0XcVLVHw0nyXG7RG09qcbTxXMzDSIHeiqhZJfNPB9/K8GdxiB3Ow0iAr/NraFjH794hOQWFSx3OxznOGpM0cLZXxJWe+fdRYAuPTG7vk/l3aKNCCXbt7mJSx8pnpvh7xmNPL679qIFELGQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vOlgiyCflkOlkd4HymqhVfBXOrUzbwivA9r2LQMbJe0=; b=O4JwmzGxkMie6UMdz5ds8phG1MxdP3QyzruMux5YgznYHZHm1aGbc6mlLbwA8AbvIhzdyPTHUAwdjgO2r41EIcYJUmujpyjW7YcLhIz8+lDWIcmEnkhQbgqyEtA7Kkpb+eu2irXI8MKYAMzx2eeYqyXm6z4yA9/lXtJdVic2+Ko=
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com (20.179.33.207) by AM0PR08MB3555.eurprd08.prod.outlook.com (20.177.108.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Sun, 17 Nov 2019 01:11:41 +0000
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641]) by AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641%3]) with mapi id 15.20.2451.029; Sun, 17 Nov 2019 01:11:41 +0000
From: Vladimir Vassilev <vladimir@lightside-instruments.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] Comments on: draft-vassilev-bmwg-network-interconnect-tester-02
Thread-Index: AdWcd6wKA6BeQni6Q+27XhUz10R+DwAbEYGA
Date: Sun, 17 Nov 2019 01:11:41 +0000
Message-ID: <855ccea4-1117-ab4b-861d-54bdf6ac414b@lightside-instruments.com>
References: <4D7F4AD313D3FC43A053B309F97543CFA6EF8E3D@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6EF8E3D@njmtexg5.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: SGBP274CA0002.SGPP274.PROD.OUTLOOK.COM (2603:1096:4:b0::14) To AM0PR08MB4369.eurprd08.prod.outlook.com (2603:10a6:208:13e::15)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=vladimir@lightside-instruments.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [118.200.2.43]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 069a8ee1-917e-4cc8-be22-08d76afb1a89
x-ms-traffictypediagnostic: AM0PR08MB3555:
x-microsoft-antispam-prvs: <AM0PR08MB3555DBE0044C27F46C391E779B720@AM0PR08MB3555.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02243C58C6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(346002)(376002)(39830400003)(199004)(189003)(6506007)(316002)(256004)(6486002)(66066001)(305945005)(508600001)(7736002)(71190400001)(99286004)(2906002)(76176011)(71200400001)(14454004)(6116002)(3846002)(52116002)(966005)(110136005)(31686004)(6246003)(229853002)(446003)(486006)(11346002)(66476007)(2616005)(476003)(86362001)(6306002)(66446008)(2501003)(186003)(64756008)(6436002)(66556008)(81156014)(81166006)(8676002)(5660300002)(26005)(25786009)(36756003)(66946007)(102836004)(31696002)(8936002)(6512007)(386003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3555; H:AM0PR08MB4369.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: lightside-instruments.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Q5Jh0JG+INxWJUQCUpqXgFqyeWqU1HklvgPALf4j8WnJpgI26Ibqc/r1Db0rvED/WuGVSZ2nP1nbtqo+bTNHkzx8MjRf2+GUb5VOQbi2R1zVoDVnGxqeoKQ4XskcwF3vd34BIhkrIwViyPo7N8zXkmqy7hloZ01Dzv1mvZiwkcrD2m9H99G1VI3ZvviOq2j4WMn3XaW4EjqeivDIp8GnyCU7PJ4WfpV/Y0oA/fPs7Gfdb0rIy1jZaDNfoRbxHq3baLlmQDl6rpA7js1StPC96FlzMk2xVmRaLpdwA1CpKPshegG093vt589OlVWyQpHRT2oWq9RgDuYlPFfm6TVPgx9lgstyFvd9jdm7VDfbSPZRxURooITEkPLRK5tt/A8cQ5o4brXdNzSBplKXEt/Ec0o07LtySmvF7QOEPw5TspUC4ODyKX5QaOdZb/HRJ6Bp
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <1B05FD179083F3458ED5E5E42BBAB400@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: lightside-instruments.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 069a8ee1-917e-4cc8-be22-08d76afb1a89
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 01:11:41.2943 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c0326317-f373-4461-a96f-7946e0abb603
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KAyb1BrQvM7W5+ax5q19l3Rh/ds40YHrxBKd7k/Ry5iPH8RcIxgLDGL0Z8nVbk1qoMC3mmWTzjET6TALNuBaMkPo0pe6m4Ugy6tdAj3TTADvkzwdTbLtoYqnw6ZhWe9n
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3555
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/Ot_JMyXUTok5VIrM4tEtqG9FjyI>
Subject: Re: [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: Sun, 17 Nov 2019 01:11:47 -0000

Hi Alfred,

On 16/11/2019 13.27, MORTON, ALFRED C (AL) wrote:
> Hi Vladimir,
>
> Thanks for your demo of the YANG control model today.
>
> I have the following comments on your draft.
>
> Al
> (As a Participant)
>
> BMWG,
>
> 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,
> Al
> 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).
> [acm]
> Where's the third module?


The third module was for management of internal interface loopback 
configurationĀ  (present in 00-01 versions). It was removed in the latest 
(-02) version since similar functionality is being standardized in 
ietf-if-extensions.yang part of draft-ietf-netmod-intf-ext-yang-08. I 
will remove of the bogus reference to a third module. Those interested 
in contributing to the standardization of the loopback management 
functionality can do it in draft-ietf-netmod-intf-ext-yang-08. Here is 
thread discussing the latest state and open issues 
https://mailarchive.ietf.org/arch/msg/netmod/Q_itNBOran0K_EHMf4BD0iTKMNA


>     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:
> [acm]
> run a spell check  s/conected/connected/


OK


>
>
>
> 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.
> [acm]
> 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.


Yes. A search algorithm would require multiple configuration 
transactions. I will add specific clarification.


>
> 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
> [acm]
> 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.


The design of the module allows augmentation from external modules 
adding more flexible specification of the traffic generation. That said 
the current design allows for unlimited flexibility where each frame can 
be specified as individual stream. This is not practical if one wants 
random size frame generation or a sweep over a broad range of values but 
it is 100% deterministic.


>
> ....
>
>      |  |  +--:(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}?
> [acm]
> How to control the range pf MAC addresses used for multi-frame?
> Also, what about multiple IP-layer flows?


Then one needs to specify multiple streams where each stream has frame 
specification with individual MAC or IP packet payload or augment the 
module adding more flexible templating options.


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


We can address these requirement by adding a template mechanism reusing 
the definition of a stream and specifying the logic of the generation of 
the payload of the frames. This is possible since none of the leafs 
(mac-address, frame-data etc.) are mandatory and the module can be 
augmented adding more flexible payload generation methods.

Vladimir

>
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg