[bmwg] Comments on draft-morton-bmwg-virtual-net-03

Barry Constantine <Barry.Constantine@jdsu.com> Tue, 31 March 2015 12:54 UTC

Return-Path: <Barry.Constantine@jdsu.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FEC1ACD07 for <bmwg@ietfa.amsl.com>; Tue, 31 Mar 2015 05:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.435
X-Spam-Level:
X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 0FcxbqDJ4ROQ for <bmwg@ietfa.amsl.com>; Tue, 31 Mar 2015 05:53:58 -0700 (PDT)
Received: from mx0b-00158d01.pphosted.com (mx0b-00158d01.pphosted.com [67.231.152.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72CF1ABD36 for <bmwg@ietf.org>; Tue, 31 Mar 2015 05:53:58 -0700 (PDT)
Received: from pps.filterd (m0043258.ppops.net [127.0.0.1]) by mx0b-00158d01.pphosted.com (8.14.5/8.14.5) with SMTP id t2VCmUS2008570 for <bmwg@ietf.org>; Tue, 31 Mar 2015 05:53:57 -0700
Received: from mx2.jdsu.com ([157.234.211.51]) by mx0b-00158d01.pphosted.com with ESMTP id 1tfd6428m6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <bmwg@ietf.org>; Tue, 31 Mar 2015 05:53:57 -0700
Received: from AMEXHTCA03.ds.jdsu.net (10.239.69.13) by mx2.jdsu.com (10.239.15.51) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 31 Mar 2015 05:53:45 -0700
Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXHTCA03.ds.jdsu.net ([fe80::24df:4228:5274:253d%14]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 05:53:56 -0700
From: Barry Constantine <Barry.Constantine@jdsu.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: Comments on draft-morton-bmwg-virtual-net-03
Thread-Index: AdBrrR4o20wTocK3SmS2JoJNH9+mYQ==
Date: Tue, 31 Mar 2015 12:53:55 +0000
Message-ID: <DE2AAE0A8826CF4ABC3A6CCB756356EB78EFBAC7@AMEXMB01.ds.jdsu.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.234.234.5]
Content-Type: multipart/alternative; boundary="_000_DE2AAE0A8826CF4ABC3A6CCB756356EB78EFBAC7AMEXMB01dsjdsun_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-31_03:2015-03-31,2015-03-31,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503310114
Archived-At: <http://mailarchive.ietf.org/arch/msg/bmwg/wVWdolvLZ-HsQHpjpO9P1PUtrPI>
Subject: [bmwg] Comments on draft-morton-bmwg-virtual-net-03
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 31 Mar 2015 12:54:01 -0000

Hi Al,

I read the draft in detail and first off, want to state that I fully support this work in BMWG.

Here are my first round of comments:

1. Section 2, paragraph 2.  I think it is also essential to benchmark a "bare metal" software network function so that the performance of a physcial device, software version on bare metal OS, and software version in VM can be compared

2. Section 3.2.

- It would be good to expand what is meant by Infrastructure Virtual Network.  Since the VM running on Hypervisor is a VNF, this was not clear

- "number of VNF components in the service function chain"  -->  Should this be more of a defintion of the service function chain itself, from which the number of components becomes apparent?  Service function chain would then be clearer with an example as well

3. Section 3.3, item #4

I am not sure if this is the spirit of this bullet, but what I have observed in VM based applications is the performance degradation when a VM is rotated as others are added.  I think it will be important to define a test which benchmarks the performance of say a switch under RFC 2544 conditions as new VMs are added by the Hypervisor.  This has to do with concurrency and capacity testing for which I have comments a few points below

4. Section 3.4,  I think it should be recommended that physical hardware based tester should be used as the first choice for the test traffic device and that a separate tester VNF can be used but with stronger language that this then requires that the tester VNF function be independently benchmarked against it's physical counterpart

5. Section 4.1, same as comment #1, add bare metal OS test of software network function

6. Section 4.2, paragraph 1.  I think an example of a performance results from internal OS would help here.  Did you have in mind network counters of dropped packets, etc?

7. Section 4.4.  This is my first exposure to the 3 x 3 matrix and I this is interesting.  I think what is needed is a section that describes a technique to document the concurrency of VNFs within a hardware platform and the performance / breaking points.

An example would be a firewall VNF benchmarked as a single instance and then how many Firewall VNF instances can exist concurrently within the given hardware platform before performance starts to degrade.

Then we would get into VNF functions A,B,C and how many of each can exist concurrently within a platform, so there might be a reporting matrix that shows functions A, B, C as columns and rows which show the various combinations of each that can be hosted with 100% performance for each combination (I hope this makes sense as this might be complicated to explain in an email).

Again, fully support this work and hope that these comments are helpful.

Regards,
Barry