Re: [bmwg] Proposal: Network Service Layer Abstract Model

"MORTON, ALFRED C (AL)" <> Wed, 15 November 2017 06:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2136A1274D0 for <>; Tue, 14 Nov 2017 22:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YJmRSmUqUxrl for <>; Tue, 14 Nov 2017 22:57:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 893F41270A0 for <>; Tue, 14 Nov 2017 22:57:24 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id vAF6twJ6038983; Wed, 15 Nov 2017 01:57:22 -0500
Received: from ( []) by with ESMTP id 2e8cjabw1f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 01:57:22 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id vAF6vLEh062431; Wed, 15 Nov 2017 00:57:21 -0600
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vAF6vH9B062411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Nov 2017 00:57:17 -0600
Received: from ( []) by (RSA Interceptor); Wed, 15 Nov 2017 06:57:10 GMT
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id vAF6vAJN006762; Wed, 15 Nov 2017 00:57:10 -0600
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vAF6v5bN006588; Wed, 15 Nov 2017 00:57:05 -0600
Received: from ( []) by (Postfix) with ESMTP id 6B152E4933; Wed, 15 Nov 2017 01:56:00 -0500 (EST)
Received: from ([fe80::b09c:ff13:4487:78b6]) by ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 01:57:04 -0500
From: "MORTON, ALFRED C (AL)" <>
To: Sean Wu <>, "" <>
Thread-Topic: Proposal: Network Service Layer Abstract Model
Thread-Index: AdNUR7L3YmkPAbcJRoOedNO277A/ywJlup+g
Date: Wed, 15 Nov 2017 06:57:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
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-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-15_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150098
Archived-At: <>
Subject: Re: [bmwg] Proposal: Network Service Layer Abstract Model
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Benchmarking Methodology Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Nov 2017 06:57:26 -0000

Hi Sean,
Thanks for preparing a draft to describe your proposal.


The Node, Topo, and INFRA portions of the model
might be useful in benchmarking. It seems to me
that we are already collecting most of this information
in the process of documenting the test config. so
the test can be repeated. However, there is much
more detailed information (beyond what is
mentioned here) that would need to be
modeled in a general (non-vendor specific) way,
to fully support benchmarking.  As mentioned in several
BMWG RFCs - Virtual network function benchmarking is a
critical need at this time, so any new model needs to
serve the non-physical testing scenarios as well, noting that
there is a vast expansion of configuration details
for VNFs and their Infrastructure.

(as a participant)

> -----Original Message-----
> From: bmwg [] On Behalf Of Sean Wu
> Sent: Thursday, November 02, 2017 10:49 PM
> To:
> Subject: [bmwg] Proposal: Network Service Layer Abstract Model
> Hello BMWG,
> Missed the submission deadline, sending out here for comments. Draft
> itself needs improvement in both content and format wise, and will be
> formally submitted once the portal reopens.
> Most of the past benchmarking methodology is for device level, or a
> given service, feature, or protocol. Sometimes, we call it black box or
> white box testing. With advanced intelligence built in the
> infrastructure, more and more underlying details are now taken care of
> by the device/controller, and users can focus on intent-based network
> solutions. As a result, we need a black network or white network level
> benchmark test.
> Network Service Layer Abstract Model (NSLAM) is a high level abstraction
> with four supporting pillars: infrastructure, services, capacity, and
> performance. A set of sufficient but not exhaustive metrics are selected
> to define characteristics of each layer. The capacity here refers to a
> collection of route/traffic profiles that define the requirements for
> the network services. We can use the same capacity requirements to
> benchmark alternative implementations using different products or
> protocols. Boundary has been blurred between layer 2 and layer 3 these
> days.
> Any comments/feedback would be appreciated. If you are interested to
> collaborate on this draft, I'll be more than happy to take some help.
> Thanks,
> Sean