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
- [bmwg] Comments on: draft-vassilev-bmwg-network-i… MORTON, ALFRED C (AL)
- Re: [bmwg] Comments on: draft-vassilev-bmwg-netwo… Vladimir Vassilev