Re: [bmwg] matters arising Re: Minutes from IETF-109 Session

tom petch <ietfa@btconnect.com> Wed, 13 January 2021 09:58 UTC

Return-Path: <ietfa@btconnect.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 5BE753A108F for <bmwg@ietfa.amsl.com>; Wed, 13 Jan 2021 01:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.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 4__j6dY1p-oc for <bmwg@ietfa.amsl.com>; Wed, 13 Jan 2021 01:58:19 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10109.outbound.protection.outlook.com [40.107.1.109]) (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 A5BAC3A0CEB for <bmwg@ietf.org>; Wed, 13 Jan 2021 01:58:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GzRbgSH3kVEsDfv5CYlhvepExud4GwFKoFgFFCWZYKcmEobcZWD0tXfr1b+W9ba5NgtuQKFRiOhOmf1jb0dEXiUB/n/rF9CdM5DKrx7Xlr71Ngx60/zZgjrFhWHHkZKZGcsNu5D5YRkl1EXUcfUyIPvFXwPII9yofNR+nngmZXSmWH2sfX3Fii8ONQKr2sFc7ocweGdB4vcZHYJ6EYQqS6upK/pMnhT586GyndaoIsK3K+GzDSp6+sJKT92v5jrcwau3ii19j7J/Hwjzj6vcW0I4R68m+Z6r1boyffpXIWkDuYmOb+rqwhKBv+gEqLcQT6bwbmXzjVPWsy8RAJFQFw==
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=92B+LStyENBILlJ666TvLm2Oq86A3bVCUWnkyOv763s=; b=MtACzCZW6q+CJ4qZ6zBsDTcMXdwqcsmerH1IVHL5no7GffFN2wZhKSXJRvdTP4H6UhenBbrfagWhKX72U+0zB/26thioFzE7r90lDsfzWzLUwQikcFuSKakTiS3WT6mq0d+jjsGQNq93g8lUPCbpLSNObCvootEBdKGIuk0aJMUT22OsH1HopKBAjlwNVA63Sr1MxlSJdyyFQECW/21Cf8NkKVAqzK6aLHfTy8k2n4SdnYvP2qWnxhe0yFzEXvzk84oXacNfHIbiJqLfGTzEdjQcoruUcBcEhhfGsR0FLNyc4hVZzb15m8vGM3ZAH04ldYofEH8Ak4unu0nCvNbTAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=92B+LStyENBILlJ666TvLm2Oq86A3bVCUWnkyOv763s=; b=sJtq6jUzndDc+fERm0akbtUw0DzpSDz9HrNl8mIWp5ayQ7PsejvbtjpVxZY1tzHNAv26E5t6uaZ9Vbrv5T2cLmEfZ7n4GEfW8FTjKvkjyBXxKCOrtSO0kYUTjj0xs30rbt+XCdUjKfFdm66bKX0FTFxFc0volcsST3csOkKqUp4=
Received: from (2603:10a6:20b:95::29) by AM6PR07MB4085.eurprd07.prod.outlook.com (2603:10a6:209:32::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.4; Wed, 13 Jan 2021 09:58:03 +0000
Received: from AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::2c1e:7c35:41ed:9e88]) by AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::2c1e:7c35:41ed:9e88%7]) with mapi id 15.20.3763.009; Wed, 13 Jan 2021 09:58:03 +0000
From: tom petch <ietfa@btconnect.com>
To: Vladimir Vassilev <vladimir@lightside-instruments.com>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] matters arising Re: Minutes from IETF-109 Session
Thread-Index: AdbkZXK+6djssXPsTEOYFzSiPbaOigBQcya/AN8tTYAAGs7sTw==
Date: Wed, 13 Jan 2021 09:58:03 +0000
Message-ID: <AM6PR07MB5784EC2FBAA252C80E889517A2A90@AM6PR07MB5784.eurprd07.prod.outlook.com>
References: <4D7F4AD313D3FC43A053B309F97543CF0147686323@njmtexg5.research.att.com> <AM6PR07MB578490CD05CB228FA12D3D9DA2AE0@AM6PR07MB5784.eurprd07.prod.outlook.com>, <68aebc4d-1176-7bd6-3b99-9f5a7d232ee9@lightside-instruments.com>
In-Reply-To: <68aebc4d-1176-7bd6-3b99-9f5a7d232ee9@lightside-instruments.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: lightside-instruments.com; dkim=none (message not signed) header.d=none;lightside-instruments.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 119a2ca9-f174-48ac-2fbc-08d8b7a9b7e0
x-ms-traffictypediagnostic: AM6PR07MB4085:
x-microsoft-antispam-prvs: <AM6PR07MB4085096A6B4A5134DD50E21CA2A90@AM6PR07MB4085.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SzdJj8ZD2HeBPedmXiMaW3O2MkfWE1mxa8NMLFGtmyfxL7BUQq7R3e1SrHk9e0eJ5r5UeSObGL6SmvxZJtoDfkV3fXS/ptbPuCXm5jIfPASmw5UrIKPhAZ3FR8iz059t44HtWG+yXMX0RB3VPjc1D/+r33vnDxeLvm7n7gx6HOsfuwvctD75MG8/dk9VydDwHUiGb4d2Z8yLP4y1FHrZgfhKUcjdUVsHFuRfiULXNc29pfWBgAZHE3gon2J3s1arNS8fkiyomoJ40rN3nq8vm+kBLUfA2nCzRRbSEF830HOLL7hQnVs0doS2zQGLWw6JIPox2NxHj4r2VjorR3lQQx+EAVRULTRDOqzVUqKLAPeG1E2Vey2GrOrtUIG4Nozx0GQN7Vxjyp3J2lXrTqENKQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5784.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6506007)(76116006)(9686003)(55016002)(110136005)(83380400001)(66476007)(64756008)(66556008)(498600001)(2906002)(71200400001)(66946007)(91956017)(8676002)(66446008)(8936002)(7696005)(33656002)(5660300002)(26005)(186003)(52536014)(86362001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?Vy85SEcGLIHiT6G5LX990iCjjnxzqUAR6ndH9giLbivc+g90jFSrqnGHo4?= =?iso-8859-1?Q?qdRAw8dtZQH68hhANZhFub2ReAIO8W0oJ0Cah7YMEf38SFF7bYY2rPKLZv?= =?iso-8859-1?Q?NicmKJg+EJPlHS/nT7HN+5N6gWOUqEkNQodbAZKNiTuMVWttgZg96GlrBc?= =?iso-8859-1?Q?5It2wI+gzW/T+kBlfpOBtcyQqqoJ+VJjWDL127+K3wiaRPQG5rmFNHrkaQ?= =?iso-8859-1?Q?4HJefGksHWrPqKPJzozDXfkUMICtDBSnMy8WQHAz4S1qpihCgKrJJTE2Xo?= =?iso-8859-1?Q?0dDUIdNn4b2pZoZpqdlvChlxMwRVKjrNN0790t9qclfwRK5E1vR/+v04Hr?= =?iso-8859-1?Q?P21DWxC4MYZg/xB2HIdfzGX4P4+iV+SJNa3p2yPkkQTxXqKbbABFeqYjQT?= =?iso-8859-1?Q?2LplyS9tyEmhLPCoPEZAG0nxTrXRfW+yOUbn+RzFiT8cPJvmlSzDi0DxAS?= =?iso-8859-1?Q?hCvc2OyzcmRbkjjX6dFRvpVoKdCeuLpcdDX4uwF9yzJnj1L7swWE+inmyo?= =?iso-8859-1?Q?TuOlGr+N+rinYBJkGk7h8LHIP58WG5+81QLkiHQyefWhte8yS6jXLXrnfN?= =?iso-8859-1?Q?hWidI30fDgTuqJgSXm6JW7PuPErk1GrEDURGmUYlU8ctLhjVk0Pyg8jPv+?= =?iso-8859-1?Q?Bl9voxgVzf1+wmWmRevjccIrXusihs1fb60EjRVk6ay4K9yf6p+uBUYNAL?= =?iso-8859-1?Q?gXS8mTn/3xDaRzkmMw+WFmlC/9OZyWWTVSRk56vngLto6/BsCYSLpYQe8y?= =?iso-8859-1?Q?g8Ki8thQpneJmCIPUlYl5TWU/c+DIGTV4a3THvJlIvO8xmKwSFaEm1VWDx?= =?iso-8859-1?Q?eVwKQtfBLJ3o8IJNc6Zo9Aes+xKSlIsiJqbAbUzSBW3J0UfdB7JqyCWe5D?= =?iso-8859-1?Q?jIsvxeg/mZNWcYBj9Crxzy8hOO8T19txirLX45qHSYaRqQ3cM6FaHpqRkA?= =?iso-8859-1?Q?x0pLCNSzc4OSm32lJdVLWUYloebjQtanG4nGOEP8ytcuS9QwnUFUcXMyO1?= =?iso-8859-1?Q?vm79gWgxEbLz4FTPo=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5784.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 119a2ca9-f174-48ac-2fbc-08d8b7a9b7e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2021 09:58:03.2565 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 57I3tEnuUMz/U5R6bw7TDlzw6MvoY6rng6Jzgnf5ps4GnAanfma2UNrFG0nfR3ymkd35bX0r6OkwgomV4DngyQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4085
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/OXfqJlAm_DHbxENDRGlFcIQ3IWw>
Subject: Re: [bmwg] matters arising Re: Minutes from IETF-109 Session
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: Wed, 13 Jan 2021 09:58:28 -0000

From: Vladimir Vassilev <vladimir@lightside-instruments.com>
Sent: 12 January 2021 20:46

<tp>
inline which gets a bit messy:-(

Hi Tom,

Thanks for keeping an eye on the draft.

On 08/01/2021 11.21, tom petch wrote:
> <tp>
>
> No one raised hand that they have read above draft. '
>
> That is because the word 'yang' does not appear in the title!

What do you mean? The title is "A YANG Data Model for Network
Interconnect Tester Management".

<tp>
sloppy wording on my part - I meant the filename which is what shows up more readily in the I-D announcements; I used to be able to search the body of the announcements but my ISP stopped that   Not worth changing now I know.

>   No matter,
>
> NMDA support or lack thereof needs a mention in the Introduction

There are a few counters defined under
/if:interfaces-state/interface/statistics (which make the draft
dependent on a deprecated container as of RFC8343). My intention is to
remove them in the next version and copy the RFC8407 "NMDA support"
boilerplate text.

> There are about twenty Normative References missing such as
>
> IEEE 802-2014
> IEEE 802.1Q
> IEEE 802.1p
> RFC6991
> RFC8343
> RFC7224

OK. These 6 references will be added to the next version.
<tp>
I think that there are more than that for example from the required Security Guidelines:-)

> while all features should have a YANG Reference clause according to a recent YANG doctor review - I agree!

OK but what would be the reference for the "multi-stream" feature for
example or the rest of the features specified in the draft that do not
need external reference?

<tp>
Well when the YANG module is floating free in cyberspace, then there is nothing else, no draft, no RFC so if the I-D is the best reference, then that should be the reference in the form of RFC XXXX

> Why is data type 'string'?  Why not binary or hex-string?

Both 'binary' and 'hex-string' are alternatives that can work. With
binary one looses the human readable representation on the wire and the
ability to edit the configuration without specialized tools for a 1/3
compression gain. While hex-string adds 1/3 extra data in form of
columns separating each byte "01:02:03" which works fine for MAC
addresses but is standing a bit in the way for longer strings - frame
header specification etc.

<tp>
ok

can make this change once at a more mature point so I do not need to
change all the tools (here an example of a tool generating an RFC2544
testframe that can be directly reused with the configuration of the
generator):

  ./traffic-generator-make-testframe --frame-size=64
--dst-mac-address="12:34:56:78:9A:BC"
--src-mac-address="DE:F0:12:34:56:78" --src-ipv4-address="192.0.2.1"
--ipv4-ttl=10 --src-ipv4-udp-port=49184 --dst-ipv4-address="192.0.2.2"
--dst-ipv4-udp-port=7
  123456789ABCDEF01234567808004500002E000000000A112CBCC0000201C0000202C0200007001A0000000102030405060708090A0B0C0D0E0F10119CD50E0F

> I note that 'burst-data' is couched in terms of octets

Correct. The interframe-,interburst- and interstream- gaps are expressed
in octets.

<tp>
just a followup to my comment about string/hexstring so no need to change anything

> YANG 'augment' are usually constrained by 'when' clause. Here every YANG interface on the box will be augmented.

IMO this is the case when the augment only applies to a certain set of
interface types. However in the case of a generator/analyzer modules
that aim to be universal and applicable for all interfaces that send and
receive packets I do not see how we can do this.

<tp>
right but below you do seem to constrain the use to Ethernet so it is not all interfaces - there are other protocols in the world!  I would add a comment to the effect that all interfaces are augmented so it is clear that this is intentional

> YANG prefix must be unique across the entire spectrum of IETF work and ideally beyond that as well.  I find 'ta' and 'tg' too brief and think that they should have another two or three characters. 't(raffic)' embraces a lot of concepts!

While I am OK with changing the prefixes to a different/longer strings I
think we can do it later in the process. For me the cost will be going
through some working code in order to modify these particular bits.
Formally there is no requirement in RFC8407 for avoiding too short prefixes.


> 'The proposed model splits the design into 3 modules - 1) Traffic
>     Generator module (TG), 2) Traffic Analyzer module (TA).  '
> That would be one and two and ???

I will fix that.

<tp>
And section 7 which has loads of 'three's

> MAC-address implies, well MAC address only; seems a bit limiting or worth a mention in the Abstract/Introduction

I am lost here. Do you refer to the ethernet feature which enables
specification of parameters like src-mac-address, dst-mac-address
vlan-id etc.?

<tp>
I am unclear whether or not this applies to interfaces which run a protocol other than Ethernet, of which there are hundreds.  I think that this needs spelling out more clearly as part of the applicability

> 'statistics' would be better IMHO in a container of their own for this application rather than alongside every other interface statistic.

The original argument for placing some of the statistic counter
definitions ( e.g. tg:generated-pkts, tg:generated-octets) in the same
container as the rest of the generic interface counters
{if:out-unicast-pkts, if:out-broadcast-pkts, if:out-multicast-pkts} was
the strict synchronization requirements for the counters of such
instruments and  some anticipated complications associated with the
synchronization of separate containers.

I would like to keep this point open for discussion for now.

<tp>
ok

> vlan id has been defined by IEEE and it is different!

Correct. This is not a precedent for IETF (yang:mac-address is also
different). That said I am considering removing the VLAN fields from the
traffic-generator module all together. I find myself using the raw
frame-data leaf for specifying advanced testframe headers (that includes
VLAN tagged frames, alternative ipv4(udp) and ipv6(udp) header options).

<tp>
I recall an AD objecting to the redefinition of this term, especially as the IETF definition lost some of the semantics which the IEEE had taken care to specify - I have notes on it somewhere, I think that it was to do with the valid values of the range

>       when "ta:type = 'ta:ethernet'";
> is fragile - derived from or self is a more robust concepthea

OK. I can't see any disadvantage in that.

<tp>
again this comes from a YANG Doctor review of another I-D

> Security Considerations must conform to YANG GuidelinOK.
OK. I will add the RFC8407 boilerplate text and a few lines informing
the reader that a stateless traffic generator is controlled with the
model and the potential risks when used outside of test environments.


> her
>
> What language is used for Appendix A.1?

This should be considered pseudo code but is actually python which uses
command line syntax (based on the YANG modules) that expands to NETCONF
protocol PDUs to orchestrate the test network in the example. The
intention is to demonstrate how the generator can be programmed along
with the DUTs.

<tp>
Worth spelling out, the language that is,  as Python or pseudo-python or ..  Examples do get copied into running code by those who know no better.  

Tom Petch

/Vladimir


>
> Tom Petch