From nobody Tue Apr 1 08:08:28 2014 Return-Path: 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 A75141A07AB for ; Tue, 1 Apr 2014 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.784 X-Spam-Level: * X-Spam-Status: No, score=1.784 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 WkPsMy20GBtm for ; Tue, 1 Apr 2014 08:08:22 -0700 (PDT) Received: from mail.veryxtech.com (mail.veryxtech.com [203.196.171.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6A1A087B for ; Tue, 1 Apr 2014 08:08:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.veryxtech.com (Postfix) with ESMTP id 098DF3740DC; Tue, 1 Apr 2014 20:38:04 +0530 (IST) X-Virus-Scanned: amavisd-new at veryxtech.com Received: from mail.veryxtech.com ([127.0.0.1]) by localhost (mail.veryxtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXb7Wn7kGdeR; Tue, 1 Apr 2014 20:37:59 +0530 (IST) Received: from LT015PC (unknown [192.168.12.89]) by mail.veryxtech.com (Postfix) with ESMTPSA id 69C523740D1; Tue, 1 Apr 2014 20:37:59 +0530 (IST) From: "Bhuvan \(Veryx Technologies\)" To: Date: Tue, 1 Apr 2014 20:37:58 +0530 Message-ID: <005301cf4dbc$2b3d6cf0$81b846d0$@veryxtech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CF4DEA.44F5A8F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9Nt0tUG/JO2aV0SZ6M+QWpGFq4dw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/1-VjFFeI7GQDEe0Zx7SbhOZ9QDM Cc: 'Anton Basil' , 'Vishwas Manral' Subject: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:08:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CF4DEA.44F5A8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, SDN is gaining lot of traction in the industry among vendors and service providers. We clearly see a need for test methodologies to measure the performance of SDN based network. Keeping this viewpoint, we have drafted a benchmarking methodology for OpenFlow SDN controller performance. http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-00 We would love to hear any comments and queries on the same. Thanks, Authors ------=_NextPart_000_0054_01CF4DEA.44F5A8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

SDN is gaining lot of = traction in the industry among vendors and service = providers.

We clearly see a need for test methodologies to measure the =
performance of SDN based network.
 
Keeping this viewpoint, we have drafted a benchmarking methodology =
for OpenFlow SDN controller =
performance.
 
http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-ben=
chmarking-00
 

We would love to hear any comments and = queries on the same.

 

Thanks,

Authors

------=_NextPart_000_0054_01CF4DEA.44F5A8F0-- From nobody Thu Apr 3 09:48:02 2014 Return-Path: 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 B8CE71A0279 for ; Thu, 3 Apr 2014 09:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 lN1lTODXYjEk for ; Thu, 3 Apr 2014 09:47:51 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 73B491A01FA for ; Thu, 3 Apr 2014 09:47:51 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 788872850E for ; Thu, 3 Apr 2014 16:47:46 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 613AE28509 for ; Thu, 3 Apr 2014 16:47:46 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 5571DFE07A for ; Thu, 3 Apr 2014 16:47:46 +0000 (GMT) Received: from USMBX2.msg.corp.akamai.com ([169.254.1.234]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 3 Apr 2014 12:47:45 -0400 From: "Banks, Sarah" To: "bmwg@ietf.org" Date: Thu, 3 Apr 2014 12:47:44 -0400 Thread-Topic: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance Thread-Index: Ac9PXHB4kYKV7EMQR5mpjNGdJEEmbg== Message-ID: References: <005301cf4dbc$2b3d6cf0$81b846d0$@veryxtech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/ruBgTZu-X8U1F_5pKjtlOIt-h3g Subject: [bmwg] FW: Benchmarking Methodology for OpenFlow SDN Controller Performance X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:47:57 -0000 SGVsbG8gQk1XRywNCglJIHNlbnQgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgb24gdGhlIHRocmVh ZCBoZXJlIHByaXZhdGVseSBhbmQgZm9yZ290IHRvDQpjYyBibXdnLiBUaGUgYXV0aG9ycyBoYXZl IGFza2VkIG1lIHRvIHNlbmQgdGhlc2UgY29tbWVudHMgdG8gdGhlIGxpc3QuDQpIZXJlIGlzIHRo ZSBvcmlnaW5hbCBlbWFpbC4NCg0KVGhhbmtzDQpTYXJhaA0KDQpPbiA0LzEvMTQsIDU6MjcgUE0s ICJCYW5rcywgU2FyYWgiIDxzYmFua3NAYWthbWFpLmNvbT4gd3JvdGU6DQoNCj5BdXRob3JzLA0K Pg0KPglUaGFua3MgZm9yIHlvdXIgZHJhZnQhIFNETiBpcyBpbnRlcmVzdGluZywgYW5kIGhhcyBj b21lIHVwIGluIHNvbWUNCj5oYWxsd2F5IGNvbnZlcnNhdGlvbnMgLSBpdCdzIG5pY2UgdG8gc2Vl IGEgZHJhZnQgb24gaXQuIEkndmUgcmV2aWV3ZWQgdGhlDQo+ZG9jLCBhbmQgSSdsbCB0cnkgbm90 IHRvIHRha2UgYSBzdGFuY2UsIGJ1dCByYXRoZXIsIGFkZHJlc3MgaXNzdWVzIHRoYXQgSQ0KPnNl ZSB0aGF0IGFyZSBlaXRoZXIgdGVjaG5pY2FsbHkgd3Jvbmcgb3IgbGVhZCB0byB0aGUgcG90ZW50 aWFsIHRvIGJlDQo+d3JvbmcsIG9yIG1ha2UgdGhlIGRyYWZ0IG1vcmUgcmVhZGFibGUuIEknbGwg cG9pbnQgb3V0IHRoYXQgeW91ciBkcmFmdA0KPmNvdWxkIHVzZSBhbiBFZGl0b3IncyBleWUgLSB0 aGVyZSBhcmUgZ3JhbW1hdGljYWwgaXNzdWVzIHRocm91Z2hvdXQuIEknbQ0KPmhhcHB5IHRvIGhl bHAgaWYgeW91IG5lZWQsIHBsZWFzZSBsZXQgbWUga25vdy4NCj4NCj4JSSBsaWtlIHRvIHJldmll dyBzZWN0aW9uIGJ5IHNlY3Rpb24uIEkgaG9wZSB0aGF0IGFwcHJvYWNoIHdvcmtzIGZvciB5b3Uu DQo+SGVyZSBnb2VzLiA6KQ0KPg0KPglPdmVyYWxsLCBJIGxpa2UgdGhhdCB5b3VyIGFwcHJvYWNo IGlzIHZlcnkgc3RyYWlnaHQgZm9yd2FyZCwgYnV0IEkgZmluZA0KPnRoYXQgdGhlIGRvY3VtZW50 IHN1ZmZlcnMgZnJvbSBhIHRydWUgaW50cm9kdWN0aW9uLiBJbmRlZWQsIHlvdXINCj5BcHBlbmRp Y2VzIHJlYWQgdmVyeSBuaWNlbHksIGFuZCBJIGZvdW5kIG15c2VsZiB0aGlua2luZyB0aGF0IHRo aXMNCj5pbmZvcm1hdGlvbiB3b3VsZCBoYXZlIGJlZW4gbmljZSBhdCB0aGUgdG9wIG9mIHRoZSBo b3VyIC0gYXQgdGhlIGJlZ2lubmluZw0KPm9mIHRoZSBkb2N1bWVudC4gUGxlYXNlIGNvbnNpZGVy IHJlbG9jYXRpbmcgdGhpcyBpbmZvcm1hdGlvbi4gTm90IGV2ZXJ5b25lDQo+aXMgYW4gU0ROIGd1 cnUsIGFuZCBub3QgZXZlcnlvbmUgdGFrZXMgYW4gaWRlbnRpY2FsIGFwcHJvYWNoIC0gbGV2ZWwN Cj5zZXR0aW5nIHdoZXJlIHlvdSdyZSBjb21pbmcgZnJvbSBhbmQgeW91ciBzY29wZSB3aWxsIG1h a2UgY29uc3VtaW5nIHRoZQ0KPnJlc3Qgb2YgdGhlIGRvY3VtZW50IChob3BlZnVsbHkpIGVhc2ll ci4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+DQo+CUxldCBtZSBnbyBzZWN0aW9uIGJ5IHNlY3Rp b24gbm93Lg0KPg0KPkluIFNlY3Rpb24gNS4xIC0gWW91IG1lbnRpb24gdGhhdCB0aGUgc3dpdGNo ZXMgbmVlZCBub3QgYmUgcGh5c2ljYWwNCj5zd2l0Y2hlcywgYnV0IGVtdWxhdGVkL3NpbXVsYXRl ZCBieSBzb2Z0d2FyZSBvciB0ZXN0IHRvb2xzIGluc3RlYWQgLSB0aGUNCj5sYXN0IHNlbnRlbmNl IG9mIHRoaXMgcGFyYWdyYXBoIHNheXMgdGhhdCB5b3UgIk1VU1QgaW5kaWNhdGUgdGhlIG51bWJl ciBvZg0KPnN3aXRjaGVzIGFuZCBob3N0cy4uLiIgLSBjb25zaWRlciByZWZlcmVuY2luZyB0aGUg ZW11bGF0ZWQvc2ltdWxhdGVkDQo+bnVtYmVyIHRvby4gQSBxdWljayByZWFkIG1pZ2h0IGxlYXZl IG9wZW4gdGhlIGlkZWEgdGhhdCBvbmx5IHBoeXNpY2FsDQo+c3dpdGNoZXMgdXNlZCBiZSBub3Rl ZC9saXN0ZWQuDQo+DQo+U2VjdGlvbiA1LjMgcmVmZXJzIHRvIHRoZSBhYmlsaXR5IHRvIGhhdmUg ZGlmZmVyaW5nIHdheXMgdG8gc2V0dXAgY2hhbm5lbHMNCj5hbmQgY29ubmVjdGlvbiB0eXBlLCB5 ZXQgb25seSBsZXZlcmFnZXMgc29tZSAoYXMgeWV0IHVuZGVmaW5lZCkgY2hhbm5lbA0KPnNldHVw IG1vZGVzLiBXaHk/IFdoeSBhcmUgYWxsIG9mIHRoZSBtZXRob2RzL21vZGVzIG5vdCBhcHBsaWNh YmxlIG9yIGJlaW5nDQo+dXNlZD8NCj4NCj5TZWN0aW9uIDUuMy4xLjI6IEluIGFjdGl2ZS1wYXNz aXZlIG1vZGUsIHlvdSBzdGF0ZSwgIkFueSBhc3luY2hyb25vdXMNCj5jb21tdW5pY2F0aW9ucyBm cm9tIHRoZSBzd2l0Y2ggaGF2ZSB0byBiZSBzZW50IG9uIHRoZSBhY3RpdmUgY2hhbm5lbC4iDQo+ V2hpbGUgSSBzdXNwZWN0IHlvdSBkb24ndCBtZWFuIHRoaXMgaW4gYSBub3JtYXRpdmUgd2F5LCBp dCBiZWdzIHRoZQ0KPnF1ZXN0aW9uIC0gd2h5Pw0KPg0KPlNlY3Rpb24gNS4zLjEuMyAtIHdoeSBj YWxsIHRoaXMgb3V0IGlmIHlvdSBhcmVuJ3QgZ29pbmcgdG8gcmVxdWlyZSB0aGF0DQo+dGhlaXIg dXNlIGJlIG5vdGVkIGluIHRoZSB0ZXN0IHJlc3VsdHM/DQo+DQo+U2VjdGlvbiA1LjMuMiAtIFdo YXQgaXMgY29udHJvbGxlciB0ZWFtaW5nPyAoT0ssIEkga25vdyB3aGF0IGl0IGlzLCBidXQNCj55 b3UncmUgdXNpbmcgYSB0ZXJtIG5vdCB5ZXQgZGVmaW5lZC4gUGxlYXNlIGRlZmluZS4pDQo+DQo+ U2VjdGlvbiA1LjMuMiAtIFdoeSBhcmUgeW91IHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIFRDUCBo ZXJlLCBvdmVyIHRoZQ0KPmFsdGVybmF0aXZlcz8gQmUgc3BlY2lmaWMuDQo+DQo+SW4gZ2VuZXJh bCwgeW91IGRvbid0IHRha2UgYSBzdGFuY2Ugb24gdGhlIG51bWJlciBvZiB0aW1lcyBhIHRlc3Qg c2hvdWxkDQo+YmUgcnVuLCBub3IgdGhlIGFtb3VudCBvZiB0aW1lIHRvIHdhaXQvcGF1c2UgYmV0 d2VlbiB0ZXN0cy4gV291bGQgeW91DQo+Y29uc2lkZXIgYWRkaW5nIHZhbHVlcyB0byB5b3VyIHJl Y29tbWVuZGF0aW9ucz8NCj4gDQo+WW91ciByZXBvcnRpbmcgZm9ybWF0IGlzIHJlcGVhdGVkIG92 ZXIgYW5kIG92ZXIgLSBJJ20gYSBmYW4gb2Ygc3RhdGUgaXQNCj5vbmNlLCBhbmQgbW9kaWZ5IGl0 IHdoZW4gbmVlZGVkLiA6KSBKdXN0IGEgdGhvdWdodC4NCj4NCj5TZWN0aW9uIDkgLSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAtIHRvIG15IGV5ZSwgaXQncyB1bmFjY2VwdGFibGUgdG8NCj5zdGF0 ZSB0aGF0IHRoZXJlIG1pZ2h0IGJlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoZSBzZWN1 cml0eQ0KPmNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGFuZCB0aGVuIHN0YXRlIHRoYXQgdGhleSdy ZSBvdXQgb2Ygc2NvcGUuIEkNCj5kaXNhZ3JlZS4gVGhleSBhcmUgaW4gc2NvcGUuIFdoYXQgYXJl IHRoZSBpc3N1ZXM/IEl0J3MgYSBub3J0aCBib3VuZA0KPmludGVyZmFjZSBpbiB0aGUgbGFiLiBX aGF0J3MgdXA/DQo+DQo+SXMgQXBwZW5kaXggQSAoU2VjdGlvbiAxMCkgYSBzYW1wbGUgdGVzdCBy ZXBvcnQ/IFRoZXJlJ3Mgbm8gaW5mb3JtYXRpb24NCj5hYm91dCB0aGUgc2V0dXAvdG9wb2xvZ3kg b2YgdGhlIHNldHVwLiBJZiB0aGlzIGlzbid0IHdoYXQgQXBwIEEgaXMNCj5pbnRlbmRlZCB0byBi ZSwgY29uc2lkZXIgYWRkaW5nIGEgc2FtcGxlIHRlc3QgcmVwb3J0LiBJJ2QgYXJndWUgaXQgbWln aHQNCj5ub3QgbGl2ZSBhcyBhbiBhcHBlbmRpeCwgZWl0aGVyLiA6KQ0KPg0KPkluIHRoYXQgdmVp biwgQXBwZW5kaXggQSBoYXMgbm8gcXVhbnRpZmljYXRpb24gYWJvdXQgV0hBVCBpdCBpcyAtIHdo YXQgaXMNCj5pdD8gV2h5IGFyZSB0aGVyZSBOYXM/IDopIFBsZWFzZSBjbGFyaWZ5Lg0KDQo= From nobody Fri Apr 4 02:08:48 2014 Return-Path: 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 0DFA91A03A7 for ; Fri, 4 Apr 2014 02:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 OFVhoe72sT7b for ; Fri, 4 Apr 2014 02:08:43 -0700 (PDT) Received: from mail.veryxtech.com (mail.veryxtech.com [203.196.171.45]) by ietfa.amsl.com (Postfix) with ESMTP id A89851A0118 for ; Fri, 4 Apr 2014 02:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.veryxtech.com (Postfix) with ESMTP id 804E0374115; Fri, 4 Apr 2014 14:38:30 +0530 (IST) X-Virus-Scanned: amavisd-new at veryxtech.com Received: from mail.veryxtech.com ([127.0.0.1]) by localhost (mail.veryxtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOzpi4DZ+iMQ; Fri, 4 Apr 2014 14:38:26 +0530 (IST) Received: from LT015PC (unknown [192.168.12.89]) by mail.veryxtech.com (Postfix) with ESMTPSA id 283023740DC; Fri, 4 Apr 2014 14:38:26 +0530 (IST) From: "Bhuvan \(Veryx Technologies\)" To: References: <005301cf4dbc$2b3d6cf0$81b846d0$@veryxtech.com> In-Reply-To: Date: Fri, 4 Apr 2014 14:38:25 +0530 Message-ID: <002101cf4fe5$6ff0c970$4fd25c50$@veryxtech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CF5013.89B00A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXPaoW5vgIcGvekrE1V8ZKk97NUgEDBZmTmmYbNnCAAVvEUIABvwEA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/Q6mHNIaYrUXKp_CVGs-y4g9kVtM Cc: vishwas manral , 'Anton Basil' Subject: [bmwg] FW: Benchmarking Methodology for OpenFlow SDN Controller Performance X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:08:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CF5013.89B00A50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello BMWG, =20 I am forwarding our response that we have provided to Sarah.=20 =20 Thanks, Bhuvan =20 From: Bhuvan (Veryx Technologies) = [mailto:bhuvaneswaran.vengainathan@veryxtech.com]=20 Sent: Thursday, April 03, 2014 12:13 PM To: Banks, Sarah (sbanks@akamai.com) Cc: 'Anton Basil'; vishwas manral (vishwas@ionosnetworks.com) Subject: RE: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller = Performance =20 Hello Sarah, =20 We have gone through your comments and they are good. Please find below our responses to your comments with tag [Authors]. =20 Also I would like to check with you if we can forward your comments to = the mailing list to generate more discussion around this. =20 Best regards, Bhuvan =20 -----Original Message----- From: Bhuvan (Veryx Technologies) = [mailto:bhuvaneswaran.vengainathan@veryxtech.com]=20 Sent: Wednesday, April 02, 2014 3:10 PM To: 'Banks, Sarah' Cc: 'anton.basil@veryxtech.com'; 'vishwas@ionosnetworks.com' Subject: RE: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller = Performance =20 Hello Sarah, =20 Thanks for taking time to review this draft and provide your comments. We will go over all your comments and provide our response shortly. =20 Best regards, Bhuvan =20 -----Original Message----- From: Banks, Sarah [mailto:sbanks@akamai.com] Sent: Wednesday, April 02, 2014 5:58 AM To: Bhuvan (Veryx Technologies); anton.basil@veryxtech.com; = vishwas@ionosnetworks.com Subject: Re: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller = Performance =20 Authors, =20 Thanks for your draft! SDN is interesting, and has come = up in some hallway conversations - it's nice to see a draft on it. I've = reviewed the doc, and I'll try not to take a stance, but rather, address = issues that I see that are either technically wrong or lead to the = potential to be wrong, or make the draft more readable. I'll point out = that your draft could use an Editor's eye - there are grammatical issues = throughout. I'm happy to help if you need, please let me know. =20 [Authors] Sure. We would love to take your help in addressing them in = the draft. =20 I like to review section by section. I hope that = approach works for you. Here goes. :) =20 Overall, I like that your approach is very straight = forward, but I find that the document suffers from a true introduction. = Indeed, your Appendices read very nicely, and I found myself thinking = that this information would have been nice at the top of the hour - at = the beginning of the document. Please consider relocating this = information. Not everyone is an SDN guru, and not everyone takes an = identical approach - level setting where you're coming from and your = scope will make consuming the rest of the document (hopefully) easier. = Does this make sense? =20 [Authors] Yes. We do agree your point. We will move the appendix B = (OpenFlow Protocol Overview) information after the scope section. =20 Let me go section by section now. =20 In Section 5.1 - You mention that the switches need not be physical = switches, but emulated/simulated by software or test tools instead - the = last sentence of this paragraph says that you "MUST indicate the number = of switches and hosts..." - consider referencing the emulated/simulated = number too. A quick read might leave open the idea that only physical = switches used be noted/listed. =20 [Authors] We will reword this sentence to reflect the emulated/simulated = entities too.=20 =20 Section 5.3 refers to the ability to have differing ways to setup = channels and connection type, yet only leverages some (as yet undefined) = channel setup modes. Why? Why are all of the methods/modes not = applicable or being used? =20 [Authors] Though we have described all the methods/modes that are = applicable, our intent is to recommend the methods/modes that are = supported by controllers available in the market. Performance = measurement over other methods/modes is mentioned as optional, depending = on the support available on the controller =20 Section 5.3.1.2: In active-passive mode, you state, "Any asynchronous = communications from the switch have to be sent on the active channel." While I suspect you don't mean this in a normative way, it begs the = question - why? =20 [Authors] We think we can remove this sentence from the draft, as in = one of the test we have mentioned that to initiate communication on the = passive channel as well. =20 Section 5.3.1.3 - why call this out if you aren't going to require that = their use be noted in the test results? =20 [Authors] We did mention their use in Section 5.3.2. So we think of = having this section in the draft. Please let us know your thoughts. =20 Section 5.3.2 - What is controller teaming? (OK, I know what it is, but = you're using a term not yet defined. Please define.) =20 [Authors] Sure. We will define this in the terminology section. =20 Section 5.3.2 - Why are you recommending the use of TCP here, over the = alternatives? Be specific. =20 [Authors] Since TCP is being supported by all OpenFlow implementations, = we have recommended TCP over others. =20 In general, you don't take a stance on the number of times a test should = be run, nor the amount of time to wait/pause between tests. Would you = consider adding values to your recommendations? =20 [Authors] We could certainly look at recommending values for parameters = like =E2=80=98number of times a test should be run=E2=80=99. But for = others, we may not be able to define/recommend values, as these = parameters may vary on implementation to implementation. =20 Your reporting format is repeated over and over - I'm a fan of state it = once, and modify it when needed. :) Just a thought. =20 [Authors] This is a good suggestion. We can remove this portion wherever = repeated in this draft. =20 Section 9 - Security Considerations - to my eye, it's unacceptable to = state that there might be security considerations in the security = considerations section, and then state that they're out of scope. I = disagree. They are in scope. What are the issues? It's a north bound = interface in the lab. What's up? =20 [Authors] Fine. We will review this section and add specific issues. =20 Is Appendix A (Section 10) a sample test report? There's no information = about the setup/topology of the setup. If this isn't what App A is = intended to be, consider adding a sample test report. I'd argue it might = not live as an appendix, either. :) =20 In that vein, Appendix A has no quantification about WHAT it is - what = is it? Why are there Nas? :) Please clarify. =20 [Authors] We have missed to provide the required descriptions to this = section. We shall add a few lines of description that would clarify the = section=E2=80=99s purpose. =20 Thanks Sarah BMWG Co-Chair =20 =20 On 4/1/14, 8:07 AM, "Bhuvan (Veryx Technologies)" < = bhuvaneswaran.vengainathan@veryxtech.com> wrote: =20 >Hi folks, >=20 >SDN is gaining lot of traction in the industry among vendors and=20 >service providers. >We clearly see a need for test methodologies to measure the performance = >of SDN based network. Keeping this viewpoint, we have drafted a=20 >benchmarking methodology for OpenFlow SDN controller performance. > = = http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking >-00 We would love to hear any comments and queries on the same. >=20 >Thanks, >Authors >=20 =20 ------=_NextPart_000_0022_01CF5013.89B00A50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello BMWG,

 

I am forwarding our = response that we have provided to Sarah.

 

Thanks,

Bhuvan

 

From:= = Bhuvan (Veryx Technologies) = [mailto:bhuvaneswaran.vengainathan@veryxtech.com]
Sent: = Thursday, April 03, 2014 12:13 PM
To: Banks, Sarah = (sbanks@akamai.com)
Cc: 'Anton Basil'; vishwas manral = (vishwas@ionosnetworks.com)
Subject: RE: [bmwg] Benchmarking = Methodology for OpenFlow SDN Controller = Performance

 

Hello = Sarah,

 

We have gone through your comments and they are = good.

Please find below our = responses to your comments with tag [Authors].

 

Also I would like to check with you if we can = forward your comments to the mailing list to generate more discussion = around this.

 

Best = regards,

Bhuvan

 

-----Original Message-----
From: Bhuvan (Veryx = Technologies) [mailto:bhuvaneswaran.vengainathan@veryxtech.com] =
Sent: Wednesday, April 02, 2014 3:10 PM
To: 'Banks, Sarah'
Cc: = 'anton.basil@veryxtech.com'; 'vishwas@ionosnetworks.com'
Subject: RE: = [bmwg] Benchmarking Methodology for OpenFlow SDN Controller = Performance

 

Hello = Sarah,

 

Thanks for taking time to review this draft and = provide your comments.

We will go = over all your comments and provide our response = shortly.

 

Best regards,

Bhuvan

 

-----Original Message-----

From: Banks, Sarah = [mailto:sbanks@akamai.com]

Sent: = Wednesday, April 02, 2014 5:58 AM

To: Bhuvan (Veryx Technologies); = anton.basil@veryxtech.com; vishwas@ionosnetworks.com

Subject: Re: [bmwg] Benchmarking Methodology for = OpenFlow SDN Controller Performance

 

Authors,

 

        &nbs= p;       Thanks for your draft! SDN is = interesting, and has come up in some hallway conversations - it's nice = to see a draft on it. I've reviewed the doc, and I'll try not to take a = stance, but rather, address issues that I see that are either = technically wrong or lead to the potential to be wrong, or make the = draft more readable. I'll point out that your draft could use an = Editor's eye - there are grammatical issues throughout. I'm happy to = help if you need, please let me know.

 

[Authors] = Sure. We would love to take your help in addressing them in the = draft.

 

        &nbs= p;       I like to review section by = section. I hope that approach works for you.

Here goes. :)

 

        &nbs= p;       Overall, I like that your = approach is very straight forward, but I find that the document suffers = from a true introduction. Indeed, your Appendices read very nicely, and = I found myself thinking that this information would have been nice at = the top of the hour - at the beginning of the document. Please consider = relocating this information. Not everyone is an SDN guru, and not = everyone takes an identical approach - level setting where you're coming = from and your scope will make consuming the rest of the document = (hopefully) easier. Does this make sense?

 

[Authors] = Yes. We do agree your = point. We will move the appendix B (OpenFlow Protocol Overview) = information after the scope section.

 

        &nbs= p;       Let me go section by section = now.

 

In Section 5.1 - You mention that the switches need = not be physical switches, but emulated/simulated by software or test = tools instead - the last sentence of this paragraph says that you = "MUST indicate the number of switches and hosts..." - consider = referencing the emulated/simulated number too. A quick read might leave = open the idea that only physical switches used be = noted/listed.

 

[Authors] = We will reword this sentence to reflect the = emulated/simulated entities too.

 

Section 5.3 refers to the ability to have differing = ways to setup channels and connection type, yet only leverages some (as = yet undefined) channel setup modes. Why? Why are all of the = methods/modes not applicable or being used?

 

[Authors] = Though we have described all the methods/modes that are = applicable, our intent is to recommend the methods/modes that are = supported by controllers available in the market. Performance = measurement over other methods/modes is mentioned as optional, depending = on the support available on the controller

 

Section 5.3.1.2: In active-passive mode, you state, = "Any asynchronous communications from the switch have to be sent on = the active channel."

While I = suspect you don't mean this in a normative way, it begs the question - = why?

 

[Authors] =  We think we can = remove this sentence from the draft, as in one of the test we have = mentioned that to initiate communication on the passive channel as = well.

 

Section 5.3.1.3 - why call this out if you aren't = going to require that their use be noted in the test = results?

 

[Authors] = We did mention their use in Section 5.3.2. So we think of = having this section in the draft. Please let us know your = thoughts.

 

Section 5.3.2 - What is controller teaming? (OK, I = know what it is, but you're using a term not yet defined. Please = define.)

 

[Authors] = Sure. We will = define this in the terminology section.

 

Section 5.3.2 - Why are you recommending the use of = TCP here, over the alternatives? Be specific.

 

[Authors] = Since TCP is being supported by all OpenFlow implementations, = we have recommended TCP over others.

 

In general, you don't take a stance on the number = of times a test should be run, nor the amount of time to wait/pause = between tests. Would you consider adding values to your = recommendations?

 

[Authors] = We could certainly look at recommending values for parameters = like =E2=80=98number of times a test should be run=E2=80=99. But for = others, we may not be able to define/recommend values, as these = parameters may vary on implementation to = implementation.

 

Your reporting format is repeated over and over - = I'm a fan of state it once, and modify it when needed. :) Just a = thought.

 

[Authors] = This is a good suggestion. We can remove this portion = wherever repeated in this draft.

 

Section 9 - Security Considerations - to my eye, = it's unacceptable to state that there might be security considerations = in the security considerations section, and then state that they're out = of scope. I disagree. They are in scope. What are the issues? It's a = north bound interface in the lab. What's up?

 

[Authors] = Fine. We will = review this section and add specific issues.

 

Is Appendix A (Section 10) a sample test report? = There's no information about the setup/topology of the setup. If this = isn't what App A is intended to be, consider adding a sample test = report. I'd argue it might not live as an appendix, either. = :)

 

In that vein, Appendix A has no quantification = about WHAT it is - what is it? Why are there Nas? :) Please = clarify.

 

[Authors] = We have missed to provide the required descriptions to this = section. We shall add a few lines of description that would clarify the = section=E2=80=99s purpose.

 

Thanks

Sarah

BMWG = Co-Chair

 

 

On = 4/1/14, 8:07 AM, "Bhuvan (Veryx = Technologies)"

<bhuvaneswaran.vengainathan@v= eryxtech.com> wrote:

 

>Hi = folks,

>

>SDN is gaining lot of traction in the industry = among vendors and

>service = providers.

>We clearly see a = need for test methodologies to measure the performance

>of SDN based network. Keeping this viewpoint, = we have drafted a

>benchmarking methodology for OpenFlow SDN = controller performance.

>http://tools.ietf.org/html/d= raft-bhuvan-bmwg-of-controller-benchmarking

>-00  We would love to hear any comments = and queries on the same.

> =

>Thanks,

>Authors

> 

 

------=_NextPart_000_0022_01CF5013.89B00A50-- From nobody Fri Apr 4 13:29:38 2014 Return-Path: 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 C7A971A041A for ; Fri, 4 Apr 2014 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 bdkRJMfmCmAK for ; Fri, 4 Apr 2014 13:29:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id F32C51A034F for ; Fri, 4 Apr 2014 13:29:31 -0700 (PDT) Received: from BN1PR06MB102.namprd06.prod.outlook.com (10.255.204.15) by BN1PR06MB168.namprd06.prod.outlook.com (10.242.215.27) with Microsoft SMTP Server (TLS) id 15.0.908.10; Fri, 4 Apr 2014 20:29:26 +0000 Received: from BN1PR06MB104.namprd06.prod.outlook.com (10.255.204.18) by BN1PR06MB102.namprd06.prod.outlook.com (10.255.204.15) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 4 Apr 2014 20:29:19 +0000 Received: from BN1PR06MB104.namprd06.prod.outlook.com ([169.254.7.35]) by BN1PR06MB104.namprd06.prod.outlook.com ([169.254.7.35]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 20:29:18 +0000 From: Dean Lee To: "Fernando Calabria (fcalabri)" , "bmwg@ietf.org" Thread-Topic: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: AQHPP7FW7+nKNwmN106DcSP9VNyO9JsBlFgA Date: Fri, 4 Apr 2014 20:29:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [173.60.125.201] x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(377454003)(24454002)(479174003)(51704005)(76786001)(65816001)(2656002)(76796001)(80022001)(31966008)(77096001)(85306002)(83506001)(69226001)(81542001)(76482001)(76176001)(74502001)(99396002)(56776001)(66066001)(54356001)(63696002)(20776003)(83322001)(19580395003)(19580405001)(81342001)(83072002)(49866001)(85852003)(97186001)(4396001)(81686001)(50986001)(59766001)(95416001)(56816005)(90146001)(92566001)(47736001)(92726001)(80976001)(77982001)(74366001)(93136001)(74876001)(93516002)(46102001)(81816001)(47976001)(94946001)(51856001)(74706001)(95666003)(47446002)(54316002)(74662001)(53806001)(99286001)(97336001)(87936001)(87266001)(79102001)(86362001)(94316002)(36756003)(98676001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR06MB102; H:BN1PR06MB104.namprd06.prod.outlook.com; FPR:FC02D1A5.AC32D78B.E1DDAFF3.86E9814D.2039B; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ixiacom.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <1841E1398F9EE24EBC61B8669D035CE8@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BN1PR06MB104.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 173.60.125.201 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BN1PR06MB102.namprd06.prod.outlook.com X-OriginatorOrg: ixiacom.com Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/3-2q0XCJ6W_gCK24iiSM9u5Bxvg Subject: Re: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:29:37 -0000 SGkgRmVybmFuZG8sDQoNClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4NCg0KV2UgZGlkbuKAmXQg c3BlY2lmeSBjbGVhcmx5IGhvdyB0byBjYXB0dXJlIHRoZSBhcnJpdmFsIHRpbWUgKFR1cChEVVQs UnQtQSkpDQpvZiBhZHZlcnRpc2VkIHJvdXRlcyBhdCBEVVQgYmVjYXVzZSB0aGVyZSBhcmUgbXVs dGlwbGUgb3B0aW9ucyB0byBhY2hpZXZlDQp0aGUgc2FtZSByZXN1bHQuIFdlIGxpa2UgdG8gbGVh dmUgaXQgdG8gcmVhZGVycyBhbmQgaW1wbGVtZW50ZXJzIHRvIGNob29zZQ0KdGhlIHN1aXRhYmxl IHRlc3QgdG9vbHMuIFRvIG15IGJlc3Qga25vd2xlZGdlLCB0aGVyZSBhcmUgZmV3IG9wdGlvbnMg dG8NCmNhcHR1cmUgdGhlIGFycml2YWwgdGltZSAoVHVwKERVVCxSdC1BKSk6DQoNCiogRFVU4oCZ cyBsb2cgZmlsZSAtIGFzIHlvdSBpbmRpY2F0ZWQgaW4gdGhlIGZlZWRiYWNrLCB0aGlzIG9wdGlv biBkb2VzbuKAmXQNCm9mZmVyIHRoZSBiZXN0IHRpbWluZyByZXNvbHV0aW9uIGFuZCB0aGUgZW11 bGF0b3IgbmVlZHMgdG8gYmUgc3luY2hyb25pemVkDQp3aXRoIHRoZSB0aW1lIGJhc2Ugb2YgRFVU LiBUaGlzIG9wdGlvbiBpcyBub3Qgc2NhbGFibGUgdG8gZGVhbCB3aXRoIGxhcmdlDQphbW91bnQg b2Ygcm91dGVzLg0KDQoqIEV4dGVybmFsIGFuYWx5emVyIC0gdGhpcyBvcHRpb24gcmVxdWlyZXMg YW4gZXh0ZXJuYWwgYW5hbHl6ZXIgdG8gY2FwdHVyZQ0KTkxSSSBwYWNrZXRzIGJldHdlZW4gdGhl IGVtdWxhdG9yIGFuZCBEVVQuIFRoZSBwYWNrZXRzIGNhcHR1cmluZyBjYW4gYmUNCmRvbmUgd2l0 aCBhIFRBUCBkZXZpY2Ugb3Igc3BhbiBwb3J0IG9mIERVVCBpZiBhcHBsaWNhYmxlLiBUaGUgdGlt ZSBiYXNlIG9mDQphbmFseXplciBhbmQgZW11bGF0b3IgbmVlZHMgdG8gYmUgc3luY2hyb25pemVk Lg0KDQoqIEh5YnJpZCBlbXVsYXRvciBhbmQgYW5hbHl6ZXIgLSBzb21lIG1vZGVybiB0ZXN0IHRv b2xzIGhhdmUgdGhlDQpjYXBhYmlsaXR5IHRvIGNhcHR1cmUgYW5kIHRpbWVzdGFtcCBldmVyeSBO TFJJIHBhY2tldHMgbGVhdmluZyBhbmQNCmFycml2aW5nIGF0IHRoZSBlbXVsYXRvciBwb3J0cy4g VGhlIHRpbWVzdGFtcHMgb2YgdGhlc2UgTkxSSSBwYWNrZXRzIHdpbGwNCmJlIGFsbW9zdCBpZGVu dGljYWwgdG8gKFR1cChEVVQsUnQtQSkpIGlmIHRoZSBjYWJsZSBkaXN0YW5jZSBiZXR3ZWVuIHRo ZQ0KZW11bGF0b3IgYW5kIERVVCBpcyByZWxhdGl2ZWx5IHNob3J0Lg0KDQoNCkRlYW4NCg0KDQoN Cg0KT24gMy8xNC8xNCwgMTE6MTUgQU0sICJGZXJuYW5kbyBDYWxhYnJpYSAoZmNhbGFicmkpIiA8 ZmNhbGFicmlAY2lzY28uY29tPg0Kd3JvdGU6DQoNCj5IaSB0aGVyZSwgIEkgaG9wZSBldmVyeW9u ZSBpcyBkb2luZyBvayBhbmQgeW91IGhhZCBhIGdvb2QgcHJvZHVjdGl2ZSAgdGltZQ0KPkAgTG9u ZG9uIMWgDQo+DQo+QWZ0ZXIgcmVhZGluZyB0aGUgZG9jLCBJIGZpbmQgdGhlIG1ldGhvZG9sb2d5 IGFzIHdlbGwgYXMgdGhlIG92ZXJhbGwgIFRlc3QNCj5Db3ZlcmFnZSB2ZXJ5IHdlbGwgbGFpZCBv dXQuDQo+DQo+SSBwZXJzb25hbGx5IHNlZSBzb21lIHJvb20gZm9yIGZ1cnRoZXIgaW1wcm92ZW1l bnQgLyBleHBhbnNpb24gaW4gc29tZSBvZg0KPnRoZSBzcGVjaWZpYyBwcm9jZWR1cmVzLCAgZm9y IGV4YW1wbGU6DQo+DQo+NS4xLjEgUklCLUlOIENvbnZlcmdlbmNlLi4gIFN0ZXAgwrNGwrINCj4N Cj5SZWNvcmQgdGhlIHRpbWUgd2hlbiB0aGUgcm91dGUgQSBmcm9tIFBlZXIteCBpcyByZWNlaXZl ZCBhdA0KPiAgICAgICAgICB0aGUgRFVULg0KPg0KPg0KPlRoZSBhdXRob3JzIG1heSB3YW50IHRv IGV4cGFuZCBoZXJlIGFuZCBkZXNjcmliZWQgaG93IMWSZXhhY3RsecK5IHRoZSB0ZXN0ZXINCj4g Y2FuICBtZWFzdXJlIHRoaXMgc3BlY2lmaWMgdGltZS4NCj4NCj5JIHdvdWxkIGV4cGVjdCB0aGF0 IGl0IGlzIG5vdCBieSAgcmVseWluZyBpbiBhbnkgc29ydCBvZiDFkmRlYnVnc8K5IC8gbG9ncyAs DQo+bm9yIGZvciBhIHNpbmdsZSAgcHJlZml4IGFuZCBldmVuIHdvcnN0IGZvciB0aGUgY2FzZSBv ZiBtdWx0aXBsZSBvbmVzLg0KPg0KPkEgIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gIGhhdmUgYSDC s1RBUMKyIG9yIGEgU25pZmZlciBhbmQgbWFrZSBub3RlIG9mIHRoZQ0KPmV4YWN0IHRpbWUgdGhl IFVQREFURSBjYXJyeWluZyB0aGUgY29ycmVzcG9uZGluZyAgTkxSSSBtYWtlcyBpdCB0byB0aGUN Cj7Cs3dpcmXCsiANCj4NCj5UaGlzIGNvbW1lbnQgYWxzbyBhcHBsaWVzICB0byA1LjEuMiBwb2lu dCDCs0nCsiBhbmQgdG8gIG90aGVyIFRlc3QgQ2FzZXMgYXMNCj53ZWxsLg0KPg0KPg0KPlJnZHMg DQo+DQo+RmVybmFuZG8NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmJtd2cgbWFpbGluZyBsaXN0 DQo+Ym13Z0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Ym13Zw0KDQo= From nobody Fri Apr 4 14:34:40 2014 Return-Path: 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 EF23B1A010B for ; Fri, 4 Apr 2014 14:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 R2-UFj4LiTiv for ; Fri, 4 Apr 2014 14:34:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A41B41A00EC for ; Fri, 4 Apr 2014 14:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3930; q=dns/txt; s=iport; t=1396647268; x=1397856868; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KEsqIJQZunyhSjf91MC8A1O7FRsGG5wd7TZHNwL98DQ=; b=lWL62A6x4wWEx8E2O/FuOyIqqQj5BQkBS1ryyEZvWFfN5YGFiHw9DPKC ntKjkqbVEkENAYwXFbmJVPR0Fq+TZKdiLJawmVqaoTY6ju6vXpM1EFg8s l++tvNpENcg6C/LPKO+6OUqLueASQ4jNb39tkCGAo5el6wcyzX44fIEhU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0GAA4lP1OtJV2b/2dsb2JhbABZgwY7V4JASrlNhzcZgQsWdIImAQEEAQEBCRcROhsCAQYCDgwCJgICAiULFRACBAESh3kNkTecGKJKEwSBKYgdhFchOoJvgUkEmFuSP4Mwgis X-IronPort-AV: E=Sophos;i="4.97,797,1389744000"; d="scan'208";a="315336315" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 04 Apr 2014 21:34:28 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s34LYR9h021199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 21:34:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 16:34:27 -0500 From: "Fernando Calabria (fcalabri)" To: Dean Lee , "bmwg@ietf.org" Thread-Topic: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: AQHPP7FW7+nKNwmN106DcSP9VNyO9JsBlFgAgACpGYA= Date: Fri, 4 Apr 2014 21:34:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.211.189] Content-Type: text/plain; charset="utf-8" Content-ID: <90A1DA48A0E2914BABAD37E091AC0670@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/zybtTJDct6a_FlalQjQ43nUwc_I Subject: Re: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 21:34:39 -0000 VGhpcyBpcyBncmVhdCwgZG9u4oCZdCB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgbWF5IGJl bmVmaXQgd2l0aCBhDQpwYXJhZ3JhcGggZGVzY3JpYmluZyB0aGVzZSBvcHRpb25zICBhbmQgdGhl IHBvc3NpYmxlIHRyYWRlLW9mZiBvZiBlYWNoDQphcHByb2FjaCAvIHRlY2huaXF1ZSA/DQoNCg0K UmdkcyANCg0KRmVybmFuZG8gDQoNCg0KDQoNCk9uIDQvNC8xNCwgNToyOSBQTSwgIkRlYW4gTGVl IiA8ZGxlZUBpeGlhY29tLmNvbT4gd3JvdGU6DQoNCj5IaSBGZXJuYW5kbywNCj4NCj5UaGFua3Mg Zm9yIHlvdXIgZmVlZGJhY2suDQo+DQo+V2UgZGlkbuKAmXQgc3BlY2lmeSBjbGVhcmx5IGhvdyB0 byBjYXB0dXJlIHRoZSBhcnJpdmFsIHRpbWUgKFR1cChEVVQsUnQtQSkpDQo+b2YgYWR2ZXJ0aXNl ZCByb3V0ZXMgYXQgRFVUIGJlY2F1c2UgdGhlcmUgYXJlIG11bHRpcGxlIG9wdGlvbnMgdG8gYWNo aWV2ZQ0KPnRoZSBzYW1lIHJlc3VsdC4gV2UgbGlrZSB0byBsZWF2ZSBpdCB0byByZWFkZXJzIGFu ZCBpbXBsZW1lbnRlcnMgdG8gY2hvb3NlDQo+dGhlIHN1aXRhYmxlIHRlc3QgdG9vbHMuIFRvIG15 IGJlc3Qga25vd2xlZGdlLCB0aGVyZSBhcmUgZmV3IG9wdGlvbnMgdG8NCj5jYXB0dXJlIHRoZSBh cnJpdmFsIHRpbWUgKFR1cChEVVQsUnQtQSkpOg0KPg0KPiogRFVU4oCZcyBsb2cgZmlsZSAtIGFz IHlvdSBpbmRpY2F0ZWQgaW4gdGhlIGZlZWRiYWNrLCB0aGlzIG9wdGlvbiBkb2VzbuKAmXQNCj5v ZmZlciB0aGUgYmVzdCB0aW1pbmcgcmVzb2x1dGlvbiBhbmQgdGhlIGVtdWxhdG9yIG5lZWRzIHRv IGJlIHN5bmNocm9uaXplZA0KPndpdGggdGhlIHRpbWUgYmFzZSBvZiBEVVQuIFRoaXMgb3B0aW9u IGlzIG5vdCBzY2FsYWJsZSB0byBkZWFsIHdpdGggbGFyZ2UNCj5hbW91bnQgb2Ygcm91dGVzLg0K Pg0KPiogRXh0ZXJuYWwgYW5hbHl6ZXIgLSB0aGlzIG9wdGlvbiByZXF1aXJlcyBhbiBleHRlcm5h bCBhbmFseXplciB0byBjYXB0dXJlDQo+TkxSSSBwYWNrZXRzIGJldHdlZW4gdGhlIGVtdWxhdG9y IGFuZCBEVVQuIFRoZSBwYWNrZXRzIGNhcHR1cmluZyBjYW4gYmUNCj5kb25lIHdpdGggYSBUQVAg ZGV2aWNlIG9yIHNwYW4gcG9ydCBvZiBEVVQgaWYgYXBwbGljYWJsZS4gVGhlIHRpbWUgYmFzZSBv Zg0KPmFuYWx5emVyIGFuZCBlbXVsYXRvciBuZWVkcyB0byBiZSBzeW5jaHJvbml6ZWQuDQo+DQo+ KiBIeWJyaWQgZW11bGF0b3IgYW5kIGFuYWx5emVyIC0gc29tZSBtb2Rlcm4gdGVzdCB0b29scyBo YXZlIHRoZQ0KPmNhcGFiaWxpdHkgdG8gY2FwdHVyZSBhbmQgdGltZXN0YW1wIGV2ZXJ5IE5MUkkg cGFja2V0cyBsZWF2aW5nIGFuZA0KPmFycml2aW5nIGF0IHRoZSBlbXVsYXRvciBwb3J0cy4gVGhl IHRpbWVzdGFtcHMgb2YgdGhlc2UgTkxSSSBwYWNrZXRzIHdpbGwNCj5iZSBhbG1vc3QgaWRlbnRp Y2FsIHRvIChUdXAoRFVULFJ0LUEpKSBpZiB0aGUgY2FibGUgZGlzdGFuY2UgYmV0d2VlbiB0aGUN Cj5lbXVsYXRvciBhbmQgRFVUIGlzIHJlbGF0aXZlbHkgc2hvcnQuDQo+DQo+DQo+RGVhbg0KPg0K Pg0KPg0KPg0KPk9uIDMvMTQvMTQsIDExOjE1IEFNLCAiRmVybmFuZG8gQ2FsYWJyaWEgKGZjYWxh YnJpKSIgPGZjYWxhYnJpQGNpc2NvLmNvbT4NCj53cm90ZToNCj4NCj4+SGkgdGhlcmUsICBJIGhv cGUgZXZlcnlvbmUgaXMgZG9pbmcgb2sgYW5kIHlvdSBoYWQgYSBnb29kIHByb2R1Y3RpdmUNCj4+ dGltZQ0KPj5AIExvbmRvbiDFoA0KPj4NCj4+QWZ0ZXIgcmVhZGluZyB0aGUgZG9jLCBJIGZpbmQg dGhlIG1ldGhvZG9sb2d5IGFzIHdlbGwgYXMgdGhlIG92ZXJhbGwNCj4+VGVzdA0KPj5Db3ZlcmFn ZSB2ZXJ5IHdlbGwgbGFpZCBvdXQuDQo+Pg0KPj5JIHBlcnNvbmFsbHkgc2VlIHNvbWUgcm9vbSBm b3IgZnVydGhlciBpbXByb3ZlbWVudCAvIGV4cGFuc2lvbiBpbiBzb21lIG9mDQo+PnRoZSBzcGVj aWZpYyBwcm9jZWR1cmVzLCAgZm9yIGV4YW1wbGU6DQo+Pg0KPj41LjEuMSBSSUItSU4gQ29udmVy Z2VuY2UuLiAgU3RlcCDCs0bCsg0KPj4NCj4+UmVjb3JkIHRoZSB0aW1lIHdoZW4gdGhlIHJvdXRl IEEgZnJvbSBQZWVyLXggaXMgcmVjZWl2ZWQgYXQNCj4+ICAgICAgICAgIHRoZSBEVVQuDQo+Pg0K Pj4NCj4+VGhlIGF1dGhvcnMgbWF5IHdhbnQgdG8gZXhwYW5kIGhlcmUgYW5kIGRlc2NyaWJlZCBo b3cgxZJleGFjdGx5wrkgdGhlDQo+PnRlc3Rlcg0KPj4gY2FuICBtZWFzdXJlIHRoaXMgc3BlY2lm aWMgdGltZS4NCj4+DQo+Pkkgd291bGQgZXhwZWN0IHRoYXQgaXQgaXMgbm90IGJ5ICByZWx5aW5n IGluIGFueSBzb3J0IG9mIMWSZGVidWdzwrkgLyBsb2dzDQo+PiwNCj4+bm9yIGZvciBhIHNpbmds ZSAgcHJlZml4IGFuZCBldmVuIHdvcnN0IGZvciB0aGUgY2FzZSBvZiBtdWx0aXBsZSBvbmVzLg0K Pj4NCj4+QSAgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byAgaGF2ZSBhIMKzVEFQwrIgb3IgYSBTbmlm ZmVyIGFuZCBtYWtlIG5vdGUgb2YgdGhlDQo+PmV4YWN0IHRpbWUgdGhlIFVQREFURSBjYXJyeWlu ZyB0aGUgY29ycmVzcG9uZGluZyAgTkxSSSBtYWtlcyBpdCB0byB0aGUNCj4+wrN3aXJlwrIgDQo+ Pg0KPj5UaGlzIGNvbW1lbnQgYWxzbyBhcHBsaWVzICB0byA1LjEuMiBwb2ludCDCs0nCsiBhbmQg dG8gIG90aGVyIFRlc3QgQ2FzZXMgYXMNCj4+d2VsbC4NCj4+DQo+Pg0KPj5SZ2RzIA0KPj4NCj4+ RmVybmFuZG8NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PmJtd2cgbWFpbGlu ZyBsaXN0DQo+PmJtd2dAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ibXdnDQo+DQoNCg== From nobody Sat Apr 5 09:29:16 2014 Return-Path: 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 DDC9C1A01A6 for ; Sat, 5 Apr 2014 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OzBwmBTVqFbd for ; Sat, 5 Apr 2014 09:29:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 98E471A0219 for ; Sat, 5 Apr 2014 09:29:08 -0700 (PDT) Received: from BN1PR06MB102.namprd06.prod.outlook.com (10.255.204.15) by BN1PR06MB024.namprd06.prod.outlook.com (10.242.209.148) with Microsoft SMTP Server (TLS) id 15.0.908.10; Sat, 5 Apr 2014 16:29:02 +0000 Received: from BN1PR06MB104.namprd06.prod.outlook.com (10.255.204.18) by BN1PR06MB102.namprd06.prod.outlook.com (10.255.204.15) with Microsoft SMTP Server (TLS) id 15.0.913.9; Sat, 5 Apr 2014 16:28:59 +0000 Received: from BN1PR06MB104.namprd06.prod.outlook.com ([169.254.7.35]) by BN1PR06MB104.namprd06.prod.outlook.com ([169.254.7.35]) with mapi id 15.00.0913.002; Sat, 5 Apr 2014 16:28:58 +0000 From: Dean Lee To: "Fernando Calabria (fcalabri)" , "bmwg@ietf.org" Thread-Topic: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: AQHPP7FW7+nKNwmN106DcSP9VNyO9JsBlFgAgACpGYCAAKYYAA== Date: Sat, 5 Apr 2014 16:28:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [173.60.125.201] x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(377454003)(24454002)(479174003)(51704005)(81542001)(76796001)(76786001)(81342001)(19580405001)(69226001)(83506001)(85306002)(63696002)(76482001)(20776003)(54356001)(76176001)(31966008)(2656002)(65816001)(77096001)(66066001)(80022001)(19580395003)(83322001)(81686001)(59766001)(85852003)(49866001)(83072002)(99396002)(50986001)(97186001)(56776001)(92566001)(47736001)(80976001)(92726001)(77982001)(74366001)(93136001)(74876001)(93516002)(46102001)(81816001)(47976001)(94946001)(74662001)(54316002)(53806001)(97336001)(74502001)(87266001)(56816005)(90146001)(95416001)(79102001)(99286001)(87936001)(94316002)(98676001)(86362001)(47446002)(51856001)(95666003)(74706001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR06MB102; H:BN1PR06MB104.namprd06.prod.outlook.com; FPR:FC02D1A5.ACE2D78B.31D1A3CB.86E9824D.20447; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ixiacom.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BN1PR06MB104.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 173.60.125.201 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BN1PR06MB102.namprd06.prod.outlook.com X-OriginatorOrg: ixiacom.com Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/Kcs6xoDIZzHnzeqDs4f5xO4MReY Subject: Re: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 16:29:14 -0000 SGkgIEZlcm5hbmRvLA0KDQpXZSBpbml0aWFsbHkgZG9u4oCZdCB3YW50IHRvIG1ha2UgdGhlIGJl bmNobWFyayBkcmFmdCB0aWVkIHdpdGggc3BlY2lmaWMgc2V0DQpvZiB0ZXN0IHRvb2xzIG9yIHRl c3QgY2FwYWJpbGl0aWVzLiBPdXIgaW50ZW50aW9uIHdhcyB0byBtYWtlIGl0IGdlbmVyaWMNCmZv ciB0aGUgdGVzdCBtZXRob2RvbG9neSBhbmQgYWxsb3cgdGhlIHJlYWRlcnMgdG8gY2hvb3NlIHRo ZSB0b29sIHNldHMgdG8NCmJlc3QgZml0IHRoZWlyIHRlc3QgZW52aXJvbm1lbnRzLiBJIHRob3Vn aHQgdGhpcyBoYXMgYmVlbiB0aGUgZ3VpZGFuY2UNCmZyb20gQk1XRy4gSSB3aWxsIGRpc2N1c3Mg d2l0aCBvdGhlciBhdXRob3JzIHRvIHNlZSBpZiB0aGV5IGFncmVlIHRvIGFkZA0KcGFyYWdyYXBo IHRvIGRlc2NyaWJlIHRoZSBwb3NzaWJsZSB0ZXN0IHRvb2wgc2V0dXAuDQoNCkRlYW4NCg0KDQoN Cg0KDQoNCk9uIDQvNC8xNCwgMjozNCBQTSwgIkZlcm5hbmRvIENhbGFicmlhIChmY2FsYWJyaSki IDxmY2FsYWJyaUBjaXNjby5jb20+DQp3cm90ZToNCg0KPlRoaXMgaXMgZ3JlYXQsIGRvbuKAmXQg eW91IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IG1heSBiZW5lZml0IHdpdGggYQ0KPnBhcmFncmFw aCBkZXNjcmliaW5nIHRoZXNlIG9wdGlvbnMgIGFuZCB0aGUgcG9zc2libGUgdHJhZGUtb2ZmIG9m IGVhY2gNCj5hcHByb2FjaCAvIHRlY2huaXF1ZSA/DQo+DQo+DQo+UmdkcyANCj4NCj5GZXJuYW5k byANCj4NCj4NCj4NCj4NCj5PbiA0LzQvMTQsIDU6MjkgUE0sICJEZWFuIExlZSIgPGRsZWVAaXhp YWNvbS5jb20+IHdyb3RlOg0KPg0KPj5IaSBGZXJuYW5kbywNCj4+DQo+PlRoYW5rcyBmb3IgeW91 ciBmZWVkYmFjay4NCj4+DQo+PldlIGRpZG7igJl0IHNwZWNpZnkgY2xlYXJseSBob3cgdG8gY2Fw dHVyZSB0aGUgYXJyaXZhbCB0aW1lIChUdXAoRFVULFJ0LUEpKQ0KPj5vZiBhZHZlcnRpc2VkIHJv dXRlcyBhdCBEVVQgYmVjYXVzZSB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9ucyB0byBhY2hpZXZl DQo+PnRoZSBzYW1lIHJlc3VsdC4gV2UgbGlrZSB0byBsZWF2ZSBpdCB0byByZWFkZXJzIGFuZCBp bXBsZW1lbnRlcnMgdG8NCj4+Y2hvb3NlDQo+PnRoZSBzdWl0YWJsZSB0ZXN0IHRvb2xzLiBUbyBt eSBiZXN0IGtub3dsZWRnZSwgdGhlcmUgYXJlIGZldyBvcHRpb25zIHRvDQo+PmNhcHR1cmUgdGhl IGFycml2YWwgdGltZSAoVHVwKERVVCxSdC1BKSk6DQo+Pg0KPj4qIERVVOKAmXMgbG9nIGZpbGUg LSBhcyB5b3UgaW5kaWNhdGVkIGluIHRoZSBmZWVkYmFjaywgdGhpcyBvcHRpb24gZG9lc27igJl0 DQo+Pm9mZmVyIHRoZSBiZXN0IHRpbWluZyByZXNvbHV0aW9uIGFuZCB0aGUgZW11bGF0b3IgbmVl ZHMgdG8gYmUNCj4+c3luY2hyb25pemVkDQo+PndpdGggdGhlIHRpbWUgYmFzZSBvZiBEVVQuIFRo aXMgb3B0aW9uIGlzIG5vdCBzY2FsYWJsZSB0byBkZWFsIHdpdGggbGFyZ2UNCj4+YW1vdW50IG9m IHJvdXRlcy4NCj4+DQo+PiogRXh0ZXJuYWwgYW5hbHl6ZXIgLSB0aGlzIG9wdGlvbiByZXF1aXJl cyBhbiBleHRlcm5hbCBhbmFseXplciB0bw0KPj5jYXB0dXJlDQo+Pk5MUkkgcGFja2V0cyBiZXR3 ZWVuIHRoZSBlbXVsYXRvciBhbmQgRFVULiBUaGUgcGFja2V0cyBjYXB0dXJpbmcgY2FuIGJlDQo+ PmRvbmUgd2l0aCBhIFRBUCBkZXZpY2Ugb3Igc3BhbiBwb3J0IG9mIERVVCBpZiBhcHBsaWNhYmxl LiBUaGUgdGltZSBiYXNlDQo+Pm9mDQo+PmFuYWx5emVyIGFuZCBlbXVsYXRvciBuZWVkcyB0byBi ZSBzeW5jaHJvbml6ZWQuDQo+Pg0KPj4qIEh5YnJpZCBlbXVsYXRvciBhbmQgYW5hbHl6ZXIgLSBz b21lIG1vZGVybiB0ZXN0IHRvb2xzIGhhdmUgdGhlDQo+PmNhcGFiaWxpdHkgdG8gY2FwdHVyZSBh bmQgdGltZXN0YW1wIGV2ZXJ5IE5MUkkgcGFja2V0cyBsZWF2aW5nIGFuZA0KPj5hcnJpdmluZyBh dCB0aGUgZW11bGF0b3IgcG9ydHMuIFRoZSB0aW1lc3RhbXBzIG9mIHRoZXNlIE5MUkkgcGFja2V0 cyB3aWxsDQo+PmJlIGFsbW9zdCBpZGVudGljYWwgdG8gKFR1cChEVVQsUnQtQSkpIGlmIHRoZSBj YWJsZSBkaXN0YW5jZSBiZXR3ZWVuIHRoZQ0KPj5lbXVsYXRvciBhbmQgRFVUIGlzIHJlbGF0aXZl bHkgc2hvcnQuDQo+Pg0KPj4NCj4+RGVhbg0KPj4NCj4+DQo+Pg0KPj4NCj4+T24gMy8xNC8xNCwg MTE6MTUgQU0sICJGZXJuYW5kbyBDYWxhYnJpYSAoZmNhbGFicmkpIiA8ZmNhbGFicmlAY2lzY28u Y29tPg0KPj53cm90ZToNCj4+DQo+Pj5IaSB0aGVyZSwgIEkgaG9wZSBldmVyeW9uZSBpcyBkb2lu ZyBvayBhbmQgeW91IGhhZCBhIGdvb2QgcHJvZHVjdGl2ZQ0KPj4+dGltZQ0KPj4+QCBMb25kb24g xaANCj4+Pg0KPj4+QWZ0ZXIgcmVhZGluZyB0aGUgZG9jLCBJIGZpbmQgdGhlIG1ldGhvZG9sb2d5 IGFzIHdlbGwgYXMgdGhlIG92ZXJhbGwNCj4+PlRlc3QNCj4+PkNvdmVyYWdlIHZlcnkgd2VsbCBs YWlkIG91dC4NCj4+Pg0KPj4+SSBwZXJzb25hbGx5IHNlZSBzb21lIHJvb20gZm9yIGZ1cnRoZXIg aW1wcm92ZW1lbnQgLyBleHBhbnNpb24gaW4gc29tZQ0KPj4+b2YNCj4+PnRoZSBzcGVjaWZpYyBw cm9jZWR1cmVzLCAgZm9yIGV4YW1wbGU6DQo+Pj4NCj4+PjUuMS4xIFJJQi1JTiBDb252ZXJnZW5j ZS4uICBTdGVwIMKzRsKyDQo+Pj4NCj4+PlJlY29yZCB0aGUgdGltZSB3aGVuIHRoZSByb3V0ZSBB IGZyb20gUGVlci14IGlzIHJlY2VpdmVkIGF0DQo+Pj4gICAgICAgICAgdGhlIERVVC4NCj4+Pg0K Pj4+DQo+Pj5UaGUgYXV0aG9ycyBtYXkgd2FudCB0byBleHBhbmQgaGVyZSBhbmQgZGVzY3JpYmVk IGhvdyDFkmV4YWN0bHnCuSB0aGUNCj4+PnRlc3Rlcg0KPj4+IGNhbiAgbWVhc3VyZSB0aGlzIHNw ZWNpZmljIHRpbWUuDQo+Pj4NCj4+Pkkgd291bGQgZXhwZWN0IHRoYXQgaXQgaXMgbm90IGJ5ICBy ZWx5aW5nIGluIGFueSBzb3J0IG9mIMWSZGVidWdzwrkgLyBsb2dzDQo+Pj4sDQo+Pj5ub3IgZm9y IGEgc2luZ2xlICBwcmVmaXggYW5kIGV2ZW4gd29yc3QgZm9yIHRoZSBjYXNlIG9mIG11bHRpcGxl IG9uZXMuDQo+Pj4NCj4+PkEgIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gIGhhdmUgYSDCs1RBUMKy IG9yIGEgU25pZmZlciBhbmQgbWFrZSBub3RlIG9mDQo+Pj50aGUNCj4+PmV4YWN0IHRpbWUgdGhl IFVQREFURSBjYXJyeWluZyB0aGUgY29ycmVzcG9uZGluZyAgTkxSSSBtYWtlcyBpdCB0byB0aGUN Cj4+PsKzd2lyZcKyIA0KPj4+DQo+Pj5UaGlzIGNvbW1lbnQgYWxzbyBhcHBsaWVzICB0byA1LjEu MiBwb2ludCDCs0nCsiBhbmQgdG8gIG90aGVyIFRlc3QgQ2FzZXMNCj4+PmFzDQo+Pj53ZWxsLg0K Pj4+DQo+Pj4NCj4+PlJnZHMgDQo+Pj4NCj4+PkZlcm5hbmRvDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5ibXdnIG1haWxpbmcgbGlzdA0KPj4+Ym13Z0Bp ZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ibXdnDQo+ Pg0KPg0KDQo= From nobody Sat Apr 5 13:04:44 2014 Return-Path: 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 1B2471A02C1 for ; Sat, 5 Apr 2014 13:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 JsbfU9zX5oav for ; Sat, 5 Apr 2014 13:04:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id C22391A02C2 for ; Sat, 5 Apr 2014 13:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1396728273; x=1397937873; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lD3BVTlZbvd5itkZneJaLgZDhX5wNER8wJ6Aavu2BYA=; b=DRkfTIuI0d1PjJ7+30Utd6GxjZS6XtPyDbL70XOYOqgmmetmCXFvtabv FvuTf5wFa21WNZmxWC/ThxqYatYGYQHJ6eTMSW2c/mARl7G0UYhNAIN5U xxtYqdhDYGuwKfy+VyHqAP9y0shArjQoighstZJaeRXQreHiVklOahYSB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwGAFFgQFOtJV2b/2dsb2JhbABYgwY7V4JASrlRhzcZfBZ0giUBAQEEAQEBCRcROhsCAQYCDgoCAiYCAgIlCxUQAgQBEod5DY96nBiiJxMEgSmIHYRXITqCb4FJBJhbkj+DMIIr X-IronPort-AV: E=Sophos;i="4.97,801,1389744000"; d="scan'208";a="33315366" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 05 Apr 2014 20:04:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s35K4WOX017666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Apr 2014 20:04:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.133]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 5 Apr 2014 15:04:32 -0500 From: "Fernando Calabria (fcalabri)" To: Dean Lee , "bmwg@ietf.org" Thread-Topic: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: AQHPP7FW7+nKNwmN106DcSP9VNyO9JsBlFgAgACpGYCAAKYYAIAA0x8A Date: Sat, 5 Apr 2014 20:04:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.211.189] Content-Type: text/plain; charset="utf-8" Content-ID: <499B56D42F2AAB4485C7C315BB61EAF4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/ja2doU6xzvFGQIrK9pNAPIov8pI Subject: Re: [bmwg] Comments on draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:04:42 -0000 SGkgdGhlcmUgLCANCg0KSSBwZXJzb25hbGx5IGRvbuKAmXQgIHRoaW5rIHUgbmVlZCB0byBkaXNj dXNzIHRoZSB0ZXN0IHRvb2wgeCBzYXksIGp1c3QNCnJlY29tbWVuZCBzb21lIGdlbmVyaWMgbWV0 aG9kb2xvZ2llcyBhbmQgcG9pbnQgb3V0IHRoZSBwcm9zIGFuZCBjb25zIG9mDQplYWNoLCBsaWtl IHlvdSBkZXNjcmliZWQgaW4geW91ciBvcmlnaW5hbCByZXBseQ0KDQpSZ2RzIA0KDQpGZXJuYW5k byANCg0KIA0KDQoNCg0KDQoNCk9uIDQvNS8xNCwgMToyOCBQTSwgIkRlYW4gTGVlIiA8ZGxlZUBp eGlhY29tLmNvbT4gd3JvdGU6DQoNCj5IaSAgRmVybmFuZG8sDQo+DQo+V2UgaW5pdGlhbGx5IGRv buKAmXQgd2FudCB0byBtYWtlIHRoZSBiZW5jaG1hcmsgZHJhZnQgdGllZCB3aXRoIHNwZWNpZmlj IHNldA0KPm9mIHRlc3QgdG9vbHMgb3IgdGVzdCBjYXBhYmlsaXRpZXMuIE91ciBpbnRlbnRpb24g d2FzIHRvIG1ha2UgaXQgZ2VuZXJpYw0KPmZvciB0aGUgdGVzdCBtZXRob2RvbG9neSBhbmQgYWxs b3cgdGhlIHJlYWRlcnMgdG8gY2hvb3NlIHRoZSB0b29sIHNldHMgdG8NCj5iZXN0IGZpdCB0aGVp ciB0ZXN0IGVudmlyb25tZW50cy4gSSB0aG91Z2h0IHRoaXMgaGFzIGJlZW4gdGhlIGd1aWRhbmNl DQo+ZnJvbSBCTVdHLiBJIHdpbGwgZGlzY3VzcyB3aXRoIG90aGVyIGF1dGhvcnMgdG8gc2VlIGlm IHRoZXkgYWdyZWUgdG8gYWRkDQo+cGFyYWdyYXBoIHRvIGRlc2NyaWJlIHRoZSBwb3NzaWJsZSB0 ZXN0IHRvb2wgc2V0dXAuDQo+DQo+RGVhbg0KPg0KPg0KPg0KPg0KPg0KPg0KPk9uIDQvNC8xNCwg MjozNCBQTSwgIkZlcm5hbmRvIENhbGFicmlhIChmY2FsYWJyaSkiIDxmY2FsYWJyaUBjaXNjby5j b20+DQo+d3JvdGU6DQo+DQo+PlRoaXMgaXMgZ3JlYXQsIGRvbuKAmXQgeW91IHRoaW5rIHRoYXQg dGhlIGRvY3VtZW50IG1heSBiZW5lZml0IHdpdGggYQ0KPj5wYXJhZ3JhcGggZGVzY3JpYmluZyB0 aGVzZSBvcHRpb25zICBhbmQgdGhlIHBvc3NpYmxlIHRyYWRlLW9mZiBvZiBlYWNoDQo+PmFwcHJv YWNoIC8gdGVjaG5pcXVlID8NCj4+DQo+Pg0KPj5SZ2RzIA0KPj4NCj4+RmVybmFuZG8gDQo+Pg0K Pj4NCj4+DQo+Pg0KPj5PbiA0LzQvMTQsIDU6MjkgUE0sICJEZWFuIExlZSIgPGRsZWVAaXhpYWNv bS5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIEZlcm5hbmRvLA0KPj4+DQo+Pj5UaGFua3MgZm9yIHlv dXIgZmVlZGJhY2suDQo+Pj4NCj4+PldlIGRpZG7igJl0IHNwZWNpZnkgY2xlYXJseSBob3cgdG8g Y2FwdHVyZSB0aGUgYXJyaXZhbCB0aW1lDQo+Pj4oVHVwKERVVCxSdC1BKSkNCj4+Pm9mIGFkdmVy dGlzZWQgcm91dGVzIGF0IERVVCBiZWNhdXNlIHRoZXJlIGFyZSBtdWx0aXBsZSBvcHRpb25zIHRv DQo+Pj5hY2hpZXZlDQo+Pj50aGUgc2FtZSByZXN1bHQuIFdlIGxpa2UgdG8gbGVhdmUgaXQgdG8g cmVhZGVycyBhbmQgaW1wbGVtZW50ZXJzIHRvDQo+Pj5jaG9vc2UNCj4+PnRoZSBzdWl0YWJsZSB0 ZXN0IHRvb2xzLiBUbyBteSBiZXN0IGtub3dsZWRnZSwgdGhlcmUgYXJlIGZldyBvcHRpb25zIHRv DQo+Pj5jYXB0dXJlIHRoZSBhcnJpdmFsIHRpbWUgKFR1cChEVVQsUnQtQSkpOg0KPj4+DQo+Pj4q IERVVOKAmXMgbG9nIGZpbGUgLSBhcyB5b3UgaW5kaWNhdGVkIGluIHRoZSBmZWVkYmFjaywgdGhp cyBvcHRpb24gZG9lc27igJl0DQo+Pj5vZmZlciB0aGUgYmVzdCB0aW1pbmcgcmVzb2x1dGlvbiBh bmQgdGhlIGVtdWxhdG9yIG5lZWRzIHRvIGJlDQo+Pj5zeW5jaHJvbml6ZWQNCj4+PndpdGggdGhl IHRpbWUgYmFzZSBvZiBEVVQuIFRoaXMgb3B0aW9uIGlzIG5vdCBzY2FsYWJsZSB0byBkZWFsIHdp dGgNCj4+PmxhcmdlDQo+Pj5hbW91bnQgb2Ygcm91dGVzLg0KPj4+DQo+Pj4qIEV4dGVybmFsIGFu YWx5emVyIC0gdGhpcyBvcHRpb24gcmVxdWlyZXMgYW4gZXh0ZXJuYWwgYW5hbHl6ZXIgdG8NCj4+ PmNhcHR1cmUNCj4+Pk5MUkkgcGFja2V0cyBiZXR3ZWVuIHRoZSBlbXVsYXRvciBhbmQgRFVULiBU aGUgcGFja2V0cyBjYXB0dXJpbmcgY2FuIGJlDQo+Pj5kb25lIHdpdGggYSBUQVAgZGV2aWNlIG9y IHNwYW4gcG9ydCBvZiBEVVQgaWYgYXBwbGljYWJsZS4gVGhlIHRpbWUgYmFzZQ0KPj4+b2YNCj4+ PmFuYWx5emVyIGFuZCBlbXVsYXRvciBuZWVkcyB0byBiZSBzeW5jaHJvbml6ZWQuDQo+Pj4NCj4+ PiogSHlicmlkIGVtdWxhdG9yIGFuZCBhbmFseXplciAtIHNvbWUgbW9kZXJuIHRlc3QgdG9vbHMg aGF2ZSB0aGUNCj4+PmNhcGFiaWxpdHkgdG8gY2FwdHVyZSBhbmQgdGltZXN0YW1wIGV2ZXJ5IE5M UkkgcGFja2V0cyBsZWF2aW5nIGFuZA0KPj4+YXJyaXZpbmcgYXQgdGhlIGVtdWxhdG9yIHBvcnRz LiBUaGUgdGltZXN0YW1wcyBvZiB0aGVzZSBOTFJJIHBhY2tldHMNCj4+PndpbGwNCj4+PmJlIGFs bW9zdCBpZGVudGljYWwgdG8gKFR1cChEVVQsUnQtQSkpIGlmIHRoZSBjYWJsZSBkaXN0YW5jZSBi ZXR3ZWVuIHRoZQ0KPj4+ZW11bGF0b3IgYW5kIERVVCBpcyByZWxhdGl2ZWx5IHNob3J0Lg0KPj4+ DQo+Pj4NCj4+PkRlYW4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+T24gMy8xNC8xNCwgMTE6MTUg QU0sICJGZXJuYW5kbyBDYWxhYnJpYSAoZmNhbGFicmkpIg0KPj4+PGZjYWxhYnJpQGNpc2NvLmNv bT4NCj4+Pndyb3RlOg0KPj4+DQo+Pj4+SGkgdGhlcmUsICBJIGhvcGUgZXZlcnlvbmUgaXMgZG9p bmcgb2sgYW5kIHlvdSBoYWQgYSBnb29kIHByb2R1Y3RpdmUNCj4+Pj50aW1lDQo+Pj4+QCBMb25k b24gxaANCj4+Pj4NCj4+Pj5BZnRlciByZWFkaW5nIHRoZSBkb2MsIEkgZmluZCB0aGUgbWV0aG9k b2xvZ3kgYXMgd2VsbCBhcyB0aGUgb3ZlcmFsbA0KPj4+PlRlc3QNCj4+Pj5Db3ZlcmFnZSB2ZXJ5 IHdlbGwgbGFpZCBvdXQuDQo+Pj4+DQo+Pj4+SSBwZXJzb25hbGx5IHNlZSBzb21lIHJvb20gZm9y IGZ1cnRoZXIgaW1wcm92ZW1lbnQgLyBleHBhbnNpb24gaW4gc29tZQ0KPj4+Pm9mDQo+Pj4+dGhl IHNwZWNpZmljIHByb2NlZHVyZXMsICBmb3IgZXhhbXBsZToNCj4+Pj4NCj4+Pj41LjEuMSBSSUIt SU4gQ29udmVyZ2VuY2UuLiAgU3RlcCDCs0bCsg0KPj4+Pg0KPj4+PlJlY29yZCB0aGUgdGltZSB3 aGVuIHRoZSByb3V0ZSBBIGZyb20gUGVlci14IGlzIHJlY2VpdmVkIGF0DQo+Pj4+ICAgICAgICAg IHRoZSBEVVQuDQo+Pj4+DQo+Pj4+DQo+Pj4+VGhlIGF1dGhvcnMgbWF5IHdhbnQgdG8gZXhwYW5k IGhlcmUgYW5kIGRlc2NyaWJlZCBob3cgxZJleGFjdGx5wrkgdGhlDQo+Pj4+dGVzdGVyDQo+Pj4+ IGNhbiAgbWVhc3VyZSB0aGlzIHNwZWNpZmljIHRpbWUuDQo+Pj4+DQo+Pj4+SSB3b3VsZCBleHBl Y3QgdGhhdCBpdCBpcyBub3QgYnkgIHJlbHlpbmcgaW4gYW55IHNvcnQgb2YgxZJkZWJ1Z3PCuSAv DQo+Pj4+bG9ncw0KPj4+PiwNCj4+Pj5ub3IgZm9yIGEgc2luZ2xlICBwcmVmaXggYW5kIGV2ZW4g d29yc3QgZm9yIHRoZSBjYXNlIG9mIG11bHRpcGxlIG9uZXMuDQo+Pj4+DQo+Pj4+QSAgc3VnZ2Vz dGlvbiB3b3VsZCBiZSB0byAgaGF2ZSBhIMKzVEFQwrIgb3IgYSBTbmlmZmVyIGFuZCBtYWtlIG5v dGUgb2YNCj4+Pj50aGUNCj4+Pj5leGFjdCB0aW1lIHRoZSBVUERBVEUgY2FycnlpbmcgdGhlIGNv cnJlc3BvbmRpbmcgIE5MUkkgbWFrZXMgaXQgdG8gdGhlDQo+Pj4+wrN3aXJlwrIgDQo+Pj4+DQo+ Pj4+VGhpcyBjb21tZW50IGFsc28gYXBwbGllcyAgdG8gNS4xLjIgcG9pbnQgwrNJwrIgYW5kIHRv ICBvdGhlciBUZXN0IENhc2VzDQo+Pj4+YXMNCj4+Pj53ZWxsLg0KPj4+Pg0KPj4+Pg0KPj4+PlJn ZHMgDQo+Pj4+DQo+Pj4+RmVybmFuZG8NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PmJtd2cgbWFpbGluZyBsaXN0DQo+Pj4+Ym13Z0Bp ZXRmLm9yZw0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYm13Zw0K Pj4+DQo+Pg0KPg0KDQo= From nobody Mon Apr 7 08:06:30 2014 Return-Path: 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 5C50A1A0796 for ; Mon, 7 Apr 2014 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.4 X-Spam-Level: ** X-Spam-Status: No, score=2.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 xZiu42f16L8f for ; Mon, 7 Apr 2014 08:06:21 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 787E51A0795 for ; Mon, 7 Apr 2014 08:06:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8F80120F3F for ; Mon, 7 Apr 2014 11:06:12 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 07 Apr 2014 11:06:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=iEFsxZOIvYxfZpBAhnmhoAVaqTw=; b=ZfwQj+zcllqSgiIIlhooSTn+8YVE a3Bq3VtIf4xaBxWck4Q6yZ/GFCbPm2L+AHYpRoOtYq65IWZhOfVwkfWw32xHCZfd 6AWzXvQO0uXBzIGAdMZxAs08aOJSl4nxECUgZrSXP7HLcBfIVLDG9DBx9Mzz8dND DcSkUMd0LBbzous= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 74340F00A6A; Mon, 7 Apr 2014 11:06:12 -0400 (EDT) Message-Id: <1396883172.2235.103678713.65DD6B82@webmail.messagingengine.com> X-Sasl-Enc: GXc+JOfzT/KWAWp6uzcs2e6eeVlFS6eQoz+QBHlj5zfn 1396883172 From: William Cerveny To: bmwg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-3bcd941f Date: Mon, 07 Apr 2014 11:06:12 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/U1QFrgbBhzTRWfmPIfex7gkEboI Subject: [bmwg] My comments on draft-ietf-bmwg-sip-bench-meth-09 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:06:27 -0000 Below are my high level comments on draft-ietf-bmwg-sip-bench-meth-09 denoted by /* comment */ ; I'm sending more detailed (mostly grammatical comments) directly to the authors. I've identified the section and general line number in which the comment is made. Of note, I had trouble following the variables in the pseudocode, but I may not have been following close enough attention to the code. Bill Cerveny desktop-10-36:scratch wcerveny$ cat grep-output-meth-2014-04-17.txt 1. Abstract: 30- objective comparison of the capacity of SIP devices. Test setup 31- parameters and a methodology are necessary because SIP allows a wide 32- range of configuration and operational conditions that can influence 33:/* In my opinion, sentence beginning with "A standard terminology ..." 34: is an assumed and I'm not sure it should be in the abstract */ 35- performance benchmark measurements. A standard terminology and 36- methodology will ensure that benchmarks have consistent definition 37- and were obtained following the same procedures. -- 2. Introduction: -- 200- only. 201- 202- The device-under-test (DUT) is a SIP server, which may be any SIP 203:/* Capitalization in "Benchmarks can be ..." is inconsistant */ 204- conforming [RFC3261] device. Benchmarks can be obtained and compared 205- for different types of devices such as SIP Proxy Server, Session 206- Border Controllers (SBC), SIP registrars and SIP proxy server paired -- -- 208- 209- The test cases provide metrics for benchmarking the maximum 'SIP 210- Registration Rate' and maximum 'SIP Session Establishment Rate' that 211:/* Is "extended period" defined? */ 212- the DUT can sustain over an extended period of time without failures. 213- Some cases are included to cover Encrypted SIP. The test topologies 214- that can be used are described in the Test Setup section. Topologies -- -- 219- 220- SIP permits a wide range of configuration options that are explained 221- in Section 4 and Section 2 of [I-D.sip-bench-term]. Benchmark values 222:/* Is associated media defined */ 223- could possibly be impacted by Associated Media. The selected values 224- for Session Duration and Media Streams per Session enable benchmark 225- -- 3. Benchmarking Topologies -- 259- 260- There are two test topologies; one in which the DUT does not process 261- the media (Figure 1) and the other in which it does process media 262:/* EA defined? */ 263- (Figure 2). In both cases, the tester or EA sends traffic into the 264- DUT and absorbs traffic from the DUT. The diagrams in Figure 1 and 265- Figure 2 represent the logical flow of information and do not dictate -- 4.3 Associated Media -- 346-4.3. Associated Media 347- 348- Some tests require Associated Media to be present for each SIP 349:/* Is this redundant? */ 350- session. The test topologies to be used when benchmarking DUT 351- performance for Associated Media are shown in Figure 1 and Figure 2. 352- -- 4.6 Session Duration -- 370- 371- The value of the DUT's performance benchmarks may vary with the 372- duration of SIP sessions. Session Duration MUST be reported with 373:/* I'm not sure if this sentence ("A Session Duration ...") is properly 374-formed (it might be), but I had difficulty following the logic of the 375:sentence */ 376- benchmarking results. A Session Duration of zero seconds indicates 377- transmission of a BYE immediately following successful SIP 378- establishment indicate by receipt of a 200 OK. An infinite Session -- 4.8 Benchmarking algorithm -- 409- 410- During the Candidate Identification phase, the test runs until n 411- sessions have been attempted, at session attempt rates, r, which vary 412:/* Upper case N and lower case n are different variables?? Same with "R" */ 413- according to the algorithm below, where n is also a parameter of test 414- and is a relatively large number, but an order of magnitude smaller 415- than N. If no errors occur during the time it takes to attempt n -- -- 415- than N. If no errors occur during the time it takes to attempt n 416- sessions, we increment r according to the algorithm. If errors are 417- encountered during the test, we decrement r according to the 418:/* sentence "The algorithm provides ..." needs clarification 419:Is the word "how" unnecessary? */ 420- algorithm. The algorithm provides a variable, G, that allows us to 421- control how the accuracy, in sessions per second, that we require of 422- the test. -- -- 422- the test. 423- 424- After this candidate rate has been discovered, the test enters the 425:/* Is N consistent with N in pseudocode? */ 426- Steady State phase. In the Steady State phase, N session Attempts 427- are made at the candidate rate. The goal is to find a rate at which 428- the DUT can process calls "forever" with no errors and the test -- -- 432- the steady-state phase is entered again until a final (new) steady- 433- state rate is achieved. 434- 435:/* Would this process be clearer if presented as a list? */ 436- The iterative process itself is defined as follows: A starting rate 437- of r = 100 sessions per second is used and we place calls at that 438- rate until n = 5000 calls have been placed. If all n calls are -- -- 436- The iterative process itself is defined as follows: A starting rate 437- of r = 100 sessions per second is used and we place calls at that 438- rate until n = 5000 calls have been placed. If all n calls are 439:/* sps defined? This said, it's easy to figure out */ 440- successful, the rate is increased to 150 sps and again we place calls 441- at that rate until n = 5000 calls have been placed. The attempt rate 442- is continuously ramped up until a failure is encountered before n = -- -- 449- between the rate at which failures occurred and the last successful 450- rate. Continuing in this way, an attempt rate without errors is 451- found. The tester can specify a margin of error using the parameter G, 452:/* units? */ 453- measured in units of sessions per second. 454- 455- The pseudo-code corresponding to the description above follows. -- -- 478- G := 5 ; granularity of results - the margin of error in 479- ; sps 480- C := 0.05 ; calibration amount: How much to back down if we 481:/* using "s" before definition, in my opinion; consider "found candidate rate 482:s but cannot send at s" (Still not right, though ... */ 483- ; have found candidate s but cannot send at rate s 484- ; for time T without failures 485- -- -- 487- ; ---- Initialization of flags, candidate values and upper bounds 488- 489- f := false ; indicates a success after the upper limit 490:/* Capital F never used in pseudocode */ 491- F := false ; indicates that test is done 492- c := 0 ; indicates that we have found an upper limit 493- -- -- 499- ; characteristics until n 500- ; requests have been sent 501- if (all requests succeeded) { 502:/* undefined variable r'? does this matter? */ 503- r' := r ; save candidate value of metric 504- if ( c == 0 ) { -- 6.3 Session Establishment Rate with Media not on DUT -- 649- be recorded using any pertinent parameters as shown in the 650- reporting format of Section 5.1. 651- 652:/* Long sentence in general, but minimally last part of sentence doesn't 653:conclude */ 654- Expected Results: Session Establishment Rate results obtained with 655- Associated Media with any number of media streams per SIP session 656- are expected to be identical to the Session Establishment Rate From nobody Mon Apr 7 11:12:29 2014 Return-Path: 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 E4DCF1A047A for ; Mon, 7 Apr 2014 11:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 WT_Wktt5x0Gg for ; Mon, 7 Apr 2014 11:12:21 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C91A0811 for ; Mon, 7 Apr 2014 11:12:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3746E20BE7 for ; Mon, 7 Apr 2014 14:12:12 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Mon, 07 Apr 2014 14:12:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=KAhT3Z3GADjRI+X0OiMCPkIUeXE=; b=u5Cfonu4nhH49yeAbKd32twkMZxH ohwZyY3v1ik/mHVPb0JYymMs8BcTAxX/2WWQ5/5lEOKDBY9mRYKCIBvCX8nnWAVR zmWcqC9p3fQu/3UV96pUom85vZOOqJ+vC5bTeTPGHJYnAUSm54A3rV8aoU8gb4Vm MgqowTr7sSqaamQ= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 0FFA6F00A6A; Mon, 7 Apr 2014 14:12:12 -0400 (EDT) Message-Id: <1396894332.21912.103764125.7550637A@webmail.messagingengine.com> X-Sasl-Enc: WGD3iYAL3s+ybi1gA2Alce2aw0OmBYkaPBm+/nNX87aK 1396894332 From: William Cerveny To: bmwg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-3bcd941f Date: Mon, 07 Apr 2014 14:12:12 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/K3K5e7wzXiZ8cVgmc1Ze8kIyNzw Subject: [bmwg] Comments on draft-ietf-bmwg-sip-bench-term-09 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:12:26 -0000 My general comments about draft-ietf-bmwg-sip-bench-term-09 1) Where the term has an associated acronym, include that acronym in the definition title ... this is done in some cases, but not in others 2) Replace instances of "work item" with "document" 3) In section "3.4.2 Registration Rates", the document says: This benchmark is obtained with zero failures in which 100% of the registrations attempted by the EA are successfully completed by the DUT. Is "zero failures" redundant in the above text since 100% success would imply "zero failures"? I've sent smaller comments directly to the authors. Regards, Bill Cerveny From nobody Tue Apr 8 02:01:02 2014 Return-Path: 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 E2E721A01BB for ; Tue, 8 Apr 2014 02:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tVzyTZ6IKr1Z for ; Tue, 8 Apr 2014 02:00:55 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id DCF6E1A01C3 for ; Tue, 8 Apr 2014 02:00:36 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id DBCB2120484; Tue, 8 Apr 2014 05:06:30 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 2D51FE15D2; Tue, 8 Apr 2014 05:00:28 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 8 Apr 2014 05:00:30 -0400 From: "MORTON, ALFRED C (AL)" To: RFC Errata System , "cpopovic@cisco.com" , "ahamza@cisco.com" , "gunter@cisco.com" , "diego@fastsoft.com" , "joelja@bogus.com" Date: Tue, 8 Apr 2014 04:59:36 -0400 Thread-Topic: [Editorial Errata Reported] RFC5180 (3953) Thread-Index: Ac9S9KwKMP6LiLYtQFmUwLkSoPf8DAAFDHIT Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD0E@njfpsrvexg8.research.att.com> References: <20140408063433.766E818000C@rfc-editor.org> In-Reply-To: <20140408063433.766E818000C@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/fXZXvlY1zR2VBB4WKMv3xfRdQhs Cc: "fernando@gont.com.ar" , "bmwg@ietf.org" Subject: Re: [bmwg] [Editorial Errata Reported] RFC5180 (3953) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:01:01 -0000 Do Authors agree with this editorial change? Al co-chair bmwg ________________________________________ From: RFC Errata System [rfc-editor@rfc-editor.org] Sent: Tuesday, April 08, 2014 2:34 AM To: cpopovic@cisco.com; ahamza@cisco.com; gunter@cisco.com; diego@fastsoft.= com; bclaise@cisco.com; joelja@bogus.com; sbanks@akamai.com; MORTON, ALFRED= C (AL) Cc: fernando@gont.com.ar; bmwg@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5180 (3953) The following errata report has been submitted for RFC5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5180&eid=3D3953 -------------------------------------- Type: Editorial Reported by: Fernando Gont Section: 3 Original Text ------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 6 as possible. Corrected Text -------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 7 as possible. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5180 (draft-ietf-bmwg-ipv6-meth-05) -------------------------------------- Title : IPv6 Benchmarking Methodology for Network Interconnec= t Devices Publication Date : May 2008 Author(s) : C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin Category : INFORMATIONAL Source : Benchmarking Methodology Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 8 02:04:35 2014 Return-Path: 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 1800A1A01C2 for ; Tue, 8 Apr 2014 02:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 m7vtE33mn8Bw for ; Tue, 8 Apr 2014 02:04:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE26A1A01B5 for ; Tue, 8 Apr 2014 02:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2512; q=dns/txt; s=iport; t=1396947864; x=1398157464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+YwhkouLoYURfhK6IBwHAfJpp5HaWV/G/bpsflwk6Os=; b=Ci1wRBUqL9XQVvMv6D2q7FxmQeGWtQU612DgHgOzPBB5OGUuNq4cCWVu KCKV0I8O3qOR+Gu85UcEjr9+cybR9o96BwjLn4/TlC8335VdY0fgdUFYh zjYRW0vNBGbBQ0MuY6G3t6/K+aYYKNuZyu0GGRGZ4lc2Ai+mQP92Hzas4 Q=; X-IronPort-AV: E=Sophos;i="4.97,816,1389744000"; d="scan'208";a="316103779" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2014 09:04:24 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3894NCB000910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 09:04:23 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 04:04:23 -0500 From: "Gunter Van de Velde (gvandeve)" To: "MORTON, ALFRED C (AL)" , RFC Errata System , "cpopovic@cisco.com" , "Ahmed Hamza (ahamza)" , "gunter@cisco.com" , "diego@fastsoft.com" , "joelja@bogus.com" Thread-Topic: [Editorial Errata Reported] RFC5180 (3953) Thread-Index: AQHPUvSlNB9qEJ/dP0ut7AaBMeKfAZsHv6MA//+tJOA= Date: Tue, 8 Apr 2014 09:04:23 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241138EABC@xmb-aln-x12.cisco.com> References: <20140408063433.766E818000C@rfc-editor.org> <2845723087023D4CB5114223779FA9C80178E0CD0E@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CD0E@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.84.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/EtyIlpW1G3ga6bbh3FQrLpMY2Lo Cc: "fernando@gont.com.ar" , "bmwg@ietf.org" Subject: Re: [bmwg] [Editorial Errata Reported] RFC5180 (3953) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:04:34 -0000 Yes, small typo indeed.=20 Section 6 speaks about filters and section 7 about benchmark tests. G/ -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: 08 April 2014 11:00 To: RFC Errata System; cpopovic@cisco.com; Ahmed Hamza (ahamza); gunter@cis= co.com; diego@fastsoft.com; joelja@bogus.com Cc: fernando@gont.com.ar; bmwg@ietf.org Subject: RE: [Editorial Errata Reported] RFC5180 (3953) Do Authors agree with this editorial change? Al co-chair bmwg ________________________________________ From: RFC Errata System [rfc-editor@rfc-editor.org] Sent: Tuesday, April 08, 2014 2:34 AM To: cpopovic@cisco.com; ahamza@cisco.com; gunter@cisco.com; diego@fastsoft.= com; bclaise@cisco.com; joelja@bogus.com; sbanks@akamai.com; MORTON, ALFRED= C (AL) Cc: fernando@gont.com.ar; bmwg@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5180 (3953) The following errata report has been submitted for RFC5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5180&eid=3D3953 -------------------------------------- Type: Editorial Reported by: Fernando Gont Section: 3 Original Text ------------- Nevertheless, for each evaluated device, it is recommended to perform as ma= ny of the applicable tests described in Section 6 as possible. Corrected Text -------------- Nevertheless, for each evaluated device, it is recommended to perform as ma= ny of the applicable tests described in Section 7 as possible. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary. -------------------------------------- RFC5180 (draft-ietf-bmwg-ipv6-meth-05) -------------------------------------- Title : IPv6 Benchmarking Methodology for Network Interconnec= t Devices Publication Date : May 2008 Author(s) : C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin Category : INFORMATIONAL Source : Benchmarking Methodology Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 8 07:41:16 2014 Return-Path: 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 25D311A0437 for ; Tue, 8 Apr 2014 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 yVf0HUvrBgl4 for ; Tue, 8 Apr 2014 07:41:05 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4AC1A0410 for ; Tue, 8 Apr 2014 07:41:05 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 7242055467C; Tue, 8 Apr 2014 10:47:18 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 0989EF0271; Tue, 8 Apr 2014 10:41:04 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 8 Apr 2014 10:41:03 -0400 From: "MORTON, ALFRED C (AL)" To: "Gunter Van de Velde (gvandeve)" , RFC Errata System , "cpopovic@cisco.com" , "Ahmed Hamza (ahamza)" , "gunter@cisco.com" , "diego@fastsoft.com" , "joelja@bogus.com" Date: Tue, 8 Apr 2014 10:39:37 -0400 Thread-Topic: [Editorial Errata Reported] RFC5180 (3953) Thread-Index: AQHPUvSlNB9qEJ/dP0ut7AaBMeKfAZsHv6MA//+tJOCAAF4LOg== Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD11@njfpsrvexg8.research.att.com> References: <20140408063433.766E818000C@rfc-editor.org> <2845723087023D4CB5114223779FA9C80178E0CD0E@njfpsrvexg8.research.att.com>, <67832B1175062E48926BF3CB27C49B241138EABC@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B241138EABC@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/a5JjYIeE8Exd04D3uENRl1VRPHI Cc: "fernando@gont.com.ar" , "bmwg@ietf.org" Subject: Re: [bmwg] [Editorial Errata Reported] RFC5180 (3953) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:41:10 -0000 That was easy, thanks Gunther! I think the next step belongs to Joel - Confirmation of errata. Al ________________________________________ From: Gunter Van de Velde (gvandeve) [gvandeve@cisco.com] Sent: Tuesday, April 08, 2014 5:04 AM To: MORTON, ALFRED C (AL); RFC Errata System; cpopovic@cisco.com; Ahmed Ham= za (ahamza); gunter@cisco.com; diego@fastsoft.com; joelja@bogus.com Cc: fernando@gont.com.ar; bmwg@ietf.org Subject: RE: [Editorial Errata Reported] RFC5180 (3953) Yes, small typo indeed. Section 6 speaks about filters and section 7 about benchmark tests. G/ -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: 08 April 2014 11:00 To: RFC Errata System; cpopovic@cisco.com; Ahmed Hamza (ahamza); gunter@cis= co.com; diego@fastsoft.com; joelja@bogus.com Cc: fernando@gont.com.ar; bmwg@ietf.org Subject: RE: [Editorial Errata Reported] RFC5180 (3953) Do Authors agree with this editorial change? Al co-chair bmwg ________________________________________ From: RFC Errata System [rfc-editor@rfc-editor.org] Sent: Tuesday, April 08, 2014 2:34 AM To: cpopovic@cisco.com; ahamza@cisco.com; gunter@cisco.com; diego@fastsoft.= com; bclaise@cisco.com; joelja@bogus.com; sbanks@akamai.com; MORTON, ALFRED= C (AL) Cc: fernando@gont.com.ar; bmwg@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5180 (3953) The following errata report has been submitted for RFC5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5180&eid=3D3953 -------------------------------------- Type: Editorial Reported by: Fernando Gont Section: 3 Original Text ------------- Nevertheless, for each evaluated device, it is recommended to perform as ma= ny of the applicable tests described in Section 6 as possible. Corrected Text -------------- Nevertheless, for each evaluated device, it is recommended to perform as ma= ny of the applicable tests described in Section 7 as possible. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary. -------------------------------------- RFC5180 (draft-ietf-bmwg-ipv6-meth-05) -------------------------------------- Title : IPv6 Benchmarking Methodology for Network Interconnec= t Devices Publication Date : May 2008 Author(s) : C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin Category : INFORMATIONAL Source : Benchmarking Methodology Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 8 08:11:11 2014 Return-Path: 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 39C7B1A00FC for ; Mon, 7 Apr 2014 23:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c6vL2NQgx2AY for ; Mon, 7 Apr 2014 23:34:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E04591A0032 for ; Mon, 7 Apr 2014 23:34:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 766E818000C; Mon, 7 Apr 2014 23:34:33 -0700 (PDT) To: cpopovic@cisco.com, ahamza@cisco.com, gunter@cisco.com, diego@fastsoft.com, bclaise@cisco.com, joelja@bogus.com, sbanks@akamai.com, acmorton@att.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140408063433.766E818000C@rfc-editor.org> Date: Mon, 7 Apr 2014 23:34:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/tbmEWx_LCZMRVkRZ6k-uQshWImk X-Mailman-Approved-At: Tue, 08 Apr 2014 08:11:09 -0700 Cc: fernando@gont.com.ar, bmwg@ietf.org, rfc-editor@rfc-editor.org Subject: [bmwg] [Editorial Errata Reported] RFC5180 (3953) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 06:34:58 -0000 The following errata report has been submitted for RFC5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5180&eid=3953 -------------------------------------- Type: Editorial Reported by: Fernando Gont Section: 3 Original Text ------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 6 as possible. Corrected Text -------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 7 as possible. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5180 (draft-ietf-bmwg-ipv6-meth-05) -------------------------------------- Title : IPv6 Benchmarking Methodology for Network Interconnect Devices Publication Date : May 2008 Author(s) : C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin Category : INFORMATIONAL Source : Benchmarking Methodology Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Apr 8 10:47:28 2014 Return-Path: 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 BDB271A0663 for ; Tue, 8 Apr 2014 10:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] 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 MZrGcTnCiVZS for ; Tue, 8 Apr 2014 10:47:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8571A03FA for ; Tue, 8 Apr 2014 10:47:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1570A47527; Tue, 8 Apr 2014 17:47:19 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 0994E474F4; Tue, 8 Apr 2014 17:47:19 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 75D95203F; Tue, 8 Apr 2014 17:47:18 +0000 (GMT) Received: from USMBX2.msg.corp.akamai.com ([169.254.1.234]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 8 Apr 2014 13:47:17 -0400 From: "Banks, Sarah" To: "bhavani@cisco.com" , "shares@ndzh.com" , "dlee@ixiacom.com" , "ilya.varlashkin@easynet.com" Date: Tue, 8 Apr 2014 13:47:16 -0400 Thread-Topic: Comments/review on draft-ietf-bmwg-bgp-basic-convergence Thread-Index: Ac9TUpTFHxx7zGIDQkWj+cICS8MAEg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/0hF4ZlZzSsaA3roa-P3xnMho_-k Cc: "bmwg@ietf.org" Subject: [bmwg] Comments/review on draft-ietf-bmwg-bgp-basic-convergence X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:47:21 -0000 SGVsbG8gZHJhZnQtaWV0Zi1ibXdnLWJncC1iYXNpYy1jb252ZXJnZW5jZSBhdXRob3JzLA0KCUlu IHByZXBwaW5nIHRvIGJlIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQsIEkgcmUtcmVhZCB0aGUgZHJh ZnQgYWdhaW4gd2l0aA0KZnJlc2ggZXllcyAoaGFoKSBhbmQgaGF2ZSBhIGZldyBjb21tZW50czsg bW9zdGx5IGVkaXRvcmlhbCwgYnV0DQpub25ldGhlbGVzcywgaGVyZSB0aGV5IGNvbWUuDQoNCg0K DQoNClNlY3Rpb24gMSBhbmQgMS4xDQoJSSdtIG5vdCBhIGZhbiBvZiByZXN0YXRpbmcgLSBzYXkg d2hhdCB5b3UgbWVhbiwgYW5kIGJlIGNsZWFyIGFuZCBwcmVjaXNlLg0KVGhlIGRvY3VtZW50IGdl bmVyYWxseSByZWFkcyB0aGlzIHdheSwgc28gY29uc2lkZXIgc3RhcnRpbmcgb2ZmIHRoYXQgd2F5 DQp0b28uIEluIHBhcnRpY3VsYXIsIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgZmlyc3QgcGFy YWdyYXBoIGluIFNlY3Rpb24NCjEuMSwgIlNpbmNlIGJlbmNobWFya2luZyBpcyBhIHNjaWVuY2Ug b2YgcHJlY2lzaW9uLCBsZXQgdXMgcmVzdGF0ZSB0aGUNCnB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVu dCBpbiBiZW5jaG1hcmtpbmcgdGVybXMuIiBUaGVyZSdzIHNvbWV0aGluZyBhYm91dA0KdGhpcyB0 aGF0IHJ1YnMgbWUgdGhlIHdyb25nIHdheSwgYXMgYW4gZWRpdG9yLiBJJ20gYWxzbyBub3QgMTAw JSBzdXJlDQpiZW5jaG1hcmtpbmcgaXMgYSBzY2llbmNlIG9mIHByZWNpc2lvbi4gOikgIEluIGFu eSBldmVudCwgY29uc2lkZXIgc3RhdGluZw0Kb25jZSB3aGF0IHRoZSBkcmFmdCBpcyBhYm91dC4N Cg0KU2VjdGlvbiAxLjEgDQoJV2hhdCBpcyAiQmFzaWMgQkdQIj8gSXMgdGhlcmUgIkFkdmFuY2Vk IEJHUCIgdG9vPyBJIGplc3QgLSBidXQgeW91J3JlDQp1c2luZyBhIHRlcm0gYmVmb3JlIGludHJv ZHVjaW5nIGl0LCBpbnN0ZWFkLCB3YWl0aW5nIHRvIGludHJvZHVjZSBpdCAyDQpwYXJhZ3JhcGhz IGRvd24uIENvbnNpZGVyIGFkanVzdGluZyB0aGlzLg0KDQoJWW91IGNhbGwgb3V0IGEgdGVzdCB0 b3BvbG9neSBvZiAzIG9yIDQgbm9kZXMgLSB3aHk/IEkgZG9uJ3QgdGhpbmsgdGhpcw0KaGFzIHRv IGJlIGEgbG9uZyBwYXJhZ3JhcGgsIGp1c3QgYSBzZW50ZW5jZSwgdGhhdCBjb3ZlcnMgd2h5IHlv dSBjaG9zZSAzLzQNCm5vZGVzLCBhbmQgbm90IDIsIG9yIDIwMC4NCg0KCVNwZWFraW5nIG9mIEJh c2ljIEJHUCBkZWZpbml0aW9ucyAtIHlvdXIgZGVmaW5pdGlvbiBzYXlzICJhcyBSRkMgNDI3MSAu Li4NCkZvciBJUHY2Ii4gWW91ciBpbnRyb2R1Y3Rpb24gc3RhdGVzIHRoYXQgdGhpcyBkb2N1bWVu dCBjb3ZlcnMNCm1ldGhvZG9sb2dpZXMgZm9yIGJvdGggSVB2NCBhbmQgdjYsIHlldCBoZXJlLCB5 b3Ugc2F5IEJhc2ljIEJHUCBmb3IgdjYNCm9ubHkuIENvbnNpZGVyIHJldmlzaW5nIHRoaXMgc2Vu dGVuY2UvcGFyYWdyYXBoLg0KDQpTZWN0aW9uIDEuMg0KCUEgbWlub3IgbGFuZ3VhZ2Ugbml0LiBJ biB5b3VyIHNlY29uZCBzZW50ZW5jZS9maXJzdCBwYXJhZ3JhcGgsIHlvdSBzdGF0ZSwNCiJUbyBt YWludGFpbiBhIHJlbGlhYmxlIGNvbm5lY3Rpdml0eSB3aXRoaW4uLi4iLiBDb25zaWRlciByZXZp c2luZyB0bywgIlRvDQptYWludGFpbiByZWxpYWJsZSBjb25uZWN0aXZpdHkuLi4iDQoNCglMYXN0 IHNlbnRlbmNlLCAiVGhlc2Ugc2ltcGxlIHRlc3RzLi4uIEhpZ2gtbGV2ZWwgY2hlY2ssIG9mIHRo ZSAuLi4iIC0NCmNvbnNpZGVyIHJlbW92aW5nIHRoZSAiLCIuIFRoZXJlJ3Mgbm8gbmVlZCBmb3Ig YSBwYXVzZSB0aGVyZS4NCg0KCUxhc3Qgc2VudGVuY2UgLSB3aGF0IGlzICJtdWx0aXBsZSBpbXBs ZW1lbnRhdGlvbnMiPyBQbGVhc2UgY29uc2lkZXINCmNsYXJpZnlpbmcuDQoNClNlY3Rpb24gMS40 DQoJV2hpbGUgSSB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIHRyeWluZyB0byBkbyBoZXJlLCBJIG9m dGVuIHRlbGwgY3VzdG9tZXJzDQpOT1QgdG8gZG8gdGhpcyAtIHRoYXQgdGhleSBTSE9VTEQgdGVz dCB3aXRoIHRoZSB0aW1lciBzZXR0aW5ncywgZm9yDQpleGFtcGxlLCB0aGF0IHRoZXkgZGVwbG95 IGluIHRoZSBuZXR3b3JrIHRvZGF5LiBUaGVyZSBhcmUgbG90cyBvZiByZWFzb25zDQp3aHkgZGVm YXVsdCB0aW1lcnMgZG9uJ3Qgd29yayBmb3IgcmVhbC1saWZlIGRlcGxveW1lbnRzLCBhbmQgdGVz dCByZXN1bHRzDQp5b3UgZ2V0IGZyb20gZGVmYXVsdCB0aW1lcnMgYXJlIG9mdGVuIE5PVCB0aGUg c2FtZSBhcyB3aGVuLCBmb3IgZXhhbXBsZSwNCmNvbmZpZ3VyZWQgZm9yIGFnZ3Jlc3NpdmUgdGlt ZXJzLiBJIHRoaW5rIHRoaXMgc2tld3MgdGhlIGRhdGEgaW4gYSB3YXkgYXMNCnRvIG1ha2UgaXQg dXNlbGVzcyBpZiBub24tc3RhbmRhcmQgb3Igbm9uLWRlZmF1bHRzIGFyZSBkZXBsb3llZCBpbiB0 aGUNCndpbGQuIEknZCBwcmVmZXIgdGhhdCBpZiBhIGN1c3RvbWVyIHdhbnRzIHRvIHVzZSBhZ2dy ZXNzaXZlIHRpbWVycywgdGhleQ0KYmUgY29uZmlndXJlZCB0aGUgc2FtZSB3YXkgYWNyb3NzIGVh Y2ggaXRlcmF0aW9uIG9mIHRoZSB0ZXN0LCBhbmQgYWNyb3NzDQplYWNoIHZlbmRvcidzIGdlYXIs IGZvciBhcHBsZXMgdG8gYXBwbGVzIGNvbXBhcmlzb24uDQoNClNlY3Rpb24gMw0KCVlvdSBzdGF0 ZSwgIlRoZXNlIHNpbXBsZSB0ZXN0IG5vZGVzIGhhdmUgMyBvciA0IG5vZGVzIHdpdGggdGhlIGZv bGxvd2luZw0KY29uZmlndXJhdGlvbjoiIC0gYnV0IHRoZW4geW91IGxpc3Qgd2hhdCBJIHRoaW5r IGFyZSA0IGRpZmZlcmVudA0KY29uZmlndXJhdGlvbnMuIENvbnNpZGVyIHJldmlzaW5nIHRoZSBh Zm9yZW1lbnRpb25lZCBzZW50ZW5jZSB0byByZWFkDQpzb21ldGhpbmcgbGlrZSwgIlRoZXNlIHNp bXBsZSB0ZXN0IHNldHVwcyBoYXZlIDMgb3IgNCBub2RlcyB3aXRoIG9uZSBvZg0KdGhlIGZvbGxv d2luZyBjb25maWd1cmF0aW9uczoiDQoNCglCVFcgSSdtIG5vdCBzdXJlIHdoYXQgdXNlICJzaW1w bGUiIGhhcyBpbiB0aGUgb3JpZ2luYWwgc2VudGVuY2U7IHdoaWxlDQpJJ20gbm90IG1hcnJpZWQg dG8gdGhpcyBpZGVhLCBJJ2Qgbml4IHRoZSB1c2Ugb2YgdGhlIHdvcmQgInNpbXBsZSIgaGVyZSwN CmV2ZW4gZnJvbSB0aGUgc2FtcGxlIHNlbnRlbmNlIEkgZ2F2ZSBhYm92ZS4gOikNCg0KCVNlY3Rp b24gMyBpcyB0aGUgZmlyc3QgdGltZSB0aGUgZHJhZnQgc3RhdGVzIHRoYXQgYm90aCBpQkdQIGFu ZCBlQkdQIHdpbGwNCmJlIGNvdmVyZWQuIENvbnNpZGVyIGFkZGluZyB0aGlzIGZhY3QgdG8geW91 ciBvdmVydmlldy9pbnRyb2R1Y3Rpb24uDQoNClNlY3Rpb24gNC4yDQoJU2Vjb25kIHBhcmFncmFw aCAtICJlYWNoIHRlc3QgcnVuIG11c3QgaWRlbnRpZnkuLi4gTnVtYmVyIG9mIHJvdXRlcy4gVGhp cw0Kcm91dGUgc3RyZWFtIG11c3QgYmUgLi4uIFJlcG9ydGluZyBzdHJlYW0uIiBBcmUgdGhlc2Ug bm9ybWF0aXZlDQpyZWZlcmVuY2VzPyA6KQ0KDQoJTGFzdCBwYXJhZ3JhcGgsIGZpcnN0IHNlbnRl bmNlLCAiSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgdXNlciBtYXkNCmNvbnNpZGVyLi4uIiBD b25zaWRlciByZXZpc2luZyB0aGlzIHRvIHJlbW92ZSB0aGUgIm1heSIgLSAiSXQgaXMNClJFQ09N TUVOREVEIHRoYXQgdGhlIHVzZXIgY29uc2lkZXIgYWR2ZXJ0aXNpbmcuLi4iDQoNClNlY3Rpb24g NC4zIA0KCXdoeSBpcyAiTWluaW1hbCIgd2l0aCBhbiAiTSI/DQoNCglXaHkgYXJlIGV4YWN0IHBv bGljeSBkb2N1bWVudGF0aW9ucyBhICJzaG91bGQiIC0gSSB0aGluayB0aGlzIGlzDQpub3JtYXRp dmUgYW55aG93LCBidXQgd2h5IG5vdCBNVVNUPyBJZiB5b3UgZG9uJ3QgZG9jdW1lbnQgdGhlIHBv bGljeQ0KcHJvY2Vzc2VzLCBzbyB0aGF0IHRoZSB0ZXN0cyBjb3VsZCBiZSByZXByb2R1Y2VkIGVm ZmVjdGl2ZWx5Pw0KDQpTZWN0aW9uIDQuOA0KCVdoeSBzaG91bGQsIGFuZCBub3QgTVVTVD8NCg0K U2VjdGlvbiA1LjEuMQ0KCVdoZW4geW91IHNheSAiU3RhbmQgRGV2aWF0aW9uIiBkaWQgeW91IG1l YW4gIlN0YW5kYXJkIERldmlhdGlvbiI/DQoNCg0KVGVzdCByZXBlYXRhYmlsaXR5Og0KCVNvbWUg b2YgdGhlIHRlc3RzIGNhc2VzIHNheSB0aGF0IGl0J3MgcmVjb21tZW5kZWQgdG8gcnVuIHRoZSB0 ZXN0IGNhc2UgYQ0KY291cGxlIHRpbWVzIC0gYW5kIG5vdCBvdGhlcnMuICBJIHdvbmRlciBpZiB5 b3UgbWVhbnQgdGhpcyB0byBiZSB0cnVlIGZvcg0KYWxsIHRoZSBjYXNlcy4gSW4gYW55IGV2ZW50 LCBjb25zaWRlciBhZGRpbmcgYSBzZWN0aW9uIG9yIGFkZGluZyB0byB0aGUNCiJ0ZXN0IGNvbnNp ZGVyYXRpb25zIiBzZWN0aW9uIGEgbm90ZSBvbiBydW5uaW5nIHRoZSB0ZXN0IGNhc2VzIG11bHRp cGxlDQp0aW1lcyAtIGFuZCBldmVuIGZ1cnRoZXIsIGNvbnNpZGVyIHRha2luZyBhIHN0YW5kIG9u IGhvdyBtYW55IHRpbWVzIHRvIHJ1bg0KdGhlbS4gOikNCg0KU2VjdGlvbiA1LjgNCglIb3cgZG9l cyBvbmUgdHJpZ2dlciBhIEdSIGV2ZW50IG9uIHRoZSBEVVQ/IFRoZSBkb2N1bWVudCBkb2VzIGEg cHJldHR5DQpnb29kIGpvYiBoYW5kIGhvbGRpbmcgdGhlIHRlc3RlciAtIGNvbnNpZGVyIGFkZGlu ZyBhIHNlbnRlbmNlIG9yIHR3byBhdA0KdGhlIHN0YXJ0IG9mIHRoZSBzZWN0aW9uIG9uIGhvdyB0 byB0cmlnZ2VyIHRoZSBldmVudC4gRG8geW91IGV4cGVjdCB0aGUNCkRVVCBpbnRlcmZhY2UgdG8g ZmxhcCBvciB0aGUgdGVzdCB0b29sIHRvIGNhdXNlIHRoZSBmbGFwPyBEbyB5b3UgY2FyZT8NCg0K CVdoeSBkb2VzIHRoZSBkcmFmdCBjb3ZlciBhIHRlc3QgY2FzZSBmb3IgR1IgYW5kIG5vdCBOU1I/ DQoNCg0KDQpUaGFua3MNClNhcmFoDQoNCg0KCQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KCQ0KDQo= From nobody Wed Apr 9 07:12:31 2014 Return-Path: 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 079FD1A0320 for ; Wed, 9 Apr 2014 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, SPF_PASS=-0.001] autolearn=no 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 jE_FWE2nIkWm for ; Wed, 9 Apr 2014 07:12:24 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8331A031B for ; Wed, 9 Apr 2014 07:12:21 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s39DU9k5022581; Wed, 9 Apr 2014 07:12:20 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1k4uk7rh3w-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Apr 2014 07:12:19 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Apr 2014 07:12:18 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 9 Apr 2014 07:12:03 -0700 From: ramki Krishnan To: Muhammad Durrani , Bhavani Parise , "bmwg@ietf.org" Date: Wed, 9 Apr 2014 07:12:05 -0700 Thread-Topic: [bmwg] draft-morton-bmwg-virtual-net-00 Thread-Index: Ac9DQUDG9rb1/MKIRCaB49COb/+HIAAAk1GwBC45t2A= Message-ID: References: <2845723087023D4CB5114223779FA9C80178E0CCD3@njfpsrvexg8.research.att.com> <53294119.6040709@cisco.com> <06FF377397785A4781BD13272EBF3D58231D89E1D9@HQ1-EXCH02.corp.brocade.com> In-Reply-To: <06FF377397785A4781BD13272EBF3D58231D89E1D9@HQ1-EXCH02.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C00372AD68HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-09_02:2014-04-09,2014-04-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1404090077 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/o3D3QnYr5x6Mf74S8mJjDhQdM5g Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:12:26 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AD68HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Additionally, it would be worthwhile to discuss the common energy efficienc= y aspects across all VNFs. These would include discussing the tradeoffs bet= ween CPU energy efficiency/latency/throughput for various packet processing= schemes such as - Fixed polling - Adaptive polling - Changing processor P-states (this could be platform specific) Thanks, Ramki -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Muhammad Durrani Sent: Wednesday, March 19, 2014 12:27 AM To: Bhavani Parise; bmwg@ietf.org Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 Hi Bhavani, - do we need to consider or compare performance with the real/physical netw= ork vs. the virtual network - in 3.2 do we need Virtual Switch [MD] We do need to provide methodologies to benchmark for three architectur= es vSwitch/SR-IOV and PCI bypass. Regarding comparing performance only PCI bypass can be compared with physic= al world. Again we are not benchmarking networks here but the virtual appl= iance and wherever needed comparison will be laid out for both Physical and= virtual appliance. for 3.2 how about load balancers, firewalls - do we need to consider, what = kind of DPI - firewalls - stateful vs stateless [MD] Virtual appliance is broader term - it means virtual Load balancer an= d firewalls (both state full and stateless) We won't be suggesting "kind of= DPI" - Standard method will be provided to qualify appliance for any type = of DPI Regards, Muhammad -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Bhavani Parise Sent: Wednesday, March 19, 2014 12:03 AM To: bmwg@ietf.org Subject: [bmwg] draft-morton-bmwg-virtual-net-00 Al, including the WG list also for my comments/Qs for this draft. These are= a few things which we can look into including as considerations for this d= raft. - also for 3.2 - for VNF itself, do we need location of the VNF - guest VM,= separate process, appliance etc - - what kind of considerations we need to note when testing a Virtual Fi= rewall Function - how many Tenants can a VNF support? - for 3.3 - how about VM mobility or VNF mobility itself thanks, Bhavani ________________________________________ _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AD68HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Additionally,= it would be worthwhile to discuss the common energy efficiency aspects acr= oss all VNFs. These would include discussing the tradeoffs between CPU ener= gy efficiency/latency/throughput for various packet processing schemes such= as

-  &= nbsp;     Fixed polling

-    =     Adaptive polling

<= p class=3DMsoPlainText style=3D'margin-left:.25in;text-indent:-.25in;mso-li= st:l0 level1 lfo1'>-     &n= bsp;  Changing processor P-states (this could = be platform specific)

 

Thanks,

Ramki

 

-----Original Message-----
From: bmwg [mailto:bmwg-bounc= es@ietf.org] On Behalf Of Muhammad Durrani
Sent: Wednesday, March 19, 20= 14 12:27 AM
To: Bhavani Parise; bmwg@ietf.org
Subject: Re: [bmwg] dra= ft-morton-bmwg-virtual-net-00

 <= /p>

Hi Bhavani,

 

- do we need to consider or = compare performance with the real/physical network vs. the virtual network<= o:p>

- in 3.2 do we need Virtual Switch

 

[MD] We do need to provide methodologies to benchmark for three archi= tectures vSwitch/SR-IOV and PCI bypass.

Regarding comparing performance only PCI bypass can be compared with phy= sical world.  Again we are not benchmarking networks here but the virt= ual appliance and wherever needed comparison will be laid out for both Phys= ical and virtual appliance.

&nbs= p;

for 3.2 how about load balancers, firew= alls - do we need to consider, what kind of DPI

    - firewalls - stateful vs stateless

[MD] Virtual appliance is broader term - it me= ans virtual Load balancer  and firewalls (both state full and stateles= s) We won't be suggesting "kind of DPI" - Standard method will be= provided to qualify appliance for any type of DPI 

 

Regards,<= o:p>

Muhammad

-----Original Message-----

= From: bmwg [mailto:bmwg-bounces@ietf.org] On= Behalf Of Bhavani Parise

Sent: Wedne= sday, March 19, 2014 12:03 AM

To: bmwg@ietf.org

Sub= ject: [bmwg] draft-morton-bmwg-virtual-net-00

 

Al,

    including the WG list also for my c= omments/Qs for this draft. These are a few things which we can look into in= cluding as considerations for this draft.

 

- also for 3.2 - for VNF = itself, do we need location of the VNF - guest VM,separate process, applian= ce etc

-

    - what kind of considerations we need to= note when testing a Virtual Firewall Function

- how many Tenants can a VNF support?

- for 3.3 - how about VM mobility or VNF mobility itself

 

 

thanks,

Bhavani

____________= ____________________________

&nb= sp;

______________________________________= _________

bmwg mailing list

bmwg@ietf.org

https://ww= w.ietf.org/mailman/listinfo/bmwg

 

_______________________= ________________________

bmwg mailing= list

bmwg@ietf.org

https://www.ietf.org/mailman/listinfo/bmwg

= --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AD68HQ1EXCH01corp_-- From nobody Wed Apr 9 08:06:56 2014 Return-Path: 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 613341A03A4 for ; Wed, 9 Apr 2014 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=no 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 Szf7mrrPKcmw for ; Wed, 9 Apr 2014 08:06:48 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 882131A02C6 for ; Wed, 9 Apr 2014 08:06:48 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id A466955490E; Wed, 9 Apr 2014 11:13:04 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 18BDEF036A; Wed, 9 Apr 2014 11:06:47 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Wed, 9 Apr 2014 11:06:46 -0400 From: "MORTON, ALFRED C (AL)" To: ramki Krishnan , Muhammad Durrani , Bhavani Parise , "bmwg@ietf.org" Date: Wed, 9 Apr 2014 11:06:45 -0400 Thread-Topic: [bmwg] draft-morton-bmwg-virtual-net-00 Thread-Index: Ac9DQUDG9rb1/MKIRCaB49COb/+HIAAAk1GwBC45t2AAAgaG2Q== Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD25@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C80178E0CCD3@njfpsrvexg8.research.att.com> <53294119.6040709@cisco.com> <06FF377397785A4781BD13272EBF3D58231D89E1D9@HQ1-EXCH02.corp.brocade.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/uPLA2YnrweH7qpc-RorK2jISmwM Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:06:52 -0000 Hi Ramki, If you search our past work proposals, draft-manral-... proposed energy efficiency metrics and benchmarking. There is some controversy and complexity on making power measurements, we need to collect these issues and see what can be done. Al=20 ________________________________________ From: bmwg [bmwg-bounces@ietf.org] On Behalf Of ramki Krishnan [ramk@Brocad= e.com] Sent: Wednesday, April 09, 2014 10:12 AM To: Muhammad Durrani; Bhavani Parise; bmwg@ietf.org Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 Additionally, it would be worthwhile to discuss the common energy efficienc= y aspects across all VNFs. These would include discussing the tradeoffs bet= ween CPU energy efficiency/latency/throughput for various packet processing= schemes such as - Fixed polling - Adaptive polling - Changing processor P-states (this could be platform specific) Thanks, Ramki -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Muhammad Durrani Sent: Wednesday, March 19, 2014 12:27 AM To: Bhavani Parise; bmwg@ietf.org Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 Hi Bhavani, - do we need to consider or compare performance with the real/physical netw= ork vs. the virtual network - in 3.2 do we need Virtual Switch [MD] We do need to provide methodologies to benchmark for three architectur= es vSwitch/SR-IOV and PCI bypass. Regarding comparing performance only PCI bypass can be compared with physic= al world. Again we are not benchmarking networks here but the virtual appl= iance and wherever needed comparison will be laid out for both Physical and= virtual appliance. for 3.2 how about load balancers, firewalls - do we need to consider, what = kind of DPI - firewalls - stateful vs stateless [MD] Virtual appliance is broader term - it means virtual Load balancer an= d firewalls (both state full and stateless) We won't be suggesting "kind of= DPI" - Standard method will be provided to qualify appliance for any type = of DPI Regards, Muhammad -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Bhavani Parise Sent: Wednesday, March 19, 2014 12:03 AM To: bmwg@ietf.org Subject: [bmwg] draft-morton-bmwg-virtual-net-00 Al, including the WG list also for my comments/Qs for this draft. These are= a few things which we can look into including as considerations for this d= raft. - also for 3.2 - for VNF itself, do we need location of the VNF - guest VM,= separate process, appliance etc - - what kind of considerations we need to note when testing a Virtual Fi= rewall Function - how many Tenants can a VNF support? - for 3.3 - how about VM mobility or VNF mobility itself thanks, Bhavani ________________________________________ _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg From nobody Wed Apr 9 22:12:07 2014 Return-Path: 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 8AEB11A00AA for ; Wed, 9 Apr 2014 22:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, SPF_PASS=-0.001] autolearn=no 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 mRt3KuNeUpOt for ; Wed, 9 Apr 2014 22:12:00 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E781A0097 for ; Wed, 9 Apr 2014 22:12:00 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3A52hbd032387; Wed, 9 Apr 2014 22:11:54 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1k5drbr7ae-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Apr 2014 22:11:53 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Apr 2014 22:11:53 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 9 Apr 2014 22:11:52 -0700 From: ramki Krishnan To: "MORTON, ALFRED C (AL)" , Muhammad Durrani , Bhavani Parise , "bmwg@ietf.org" Date: Wed, 9 Apr 2014 22:11:54 -0700 Thread-Topic: [bmwg] draft-morton-bmwg-virtual-net-00 Thread-Index: Ac9DQUDG9rb1/MKIRCaB49COb/+HIAAAk1GwBC45t2AAAgaG2QAb45Wg Message-ID: References: <2845723087023D4CB5114223779FA9C80178E0CCD3@njfpsrvexg8.research.att.com> <53294119.6040709@cisco.com> <06FF377397785A4781BD13272EBF3D58231D89E1D9@HQ1-EXCH02.corp.brocade.com>, <2845723087023D4CB5114223779FA9C80178E0CD25@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CD25@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C00372AF33HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-10_01:2014-04-09,2014-04-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1404100081 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/OYCPZNmHsEmQ3faACVkA0p8Dhu0 Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 05:12:04 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AF33HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Al, There are some important and interesting differences between energy efficie= ncy in switches/routers vs VNFs (which runs on servers). Energy efficiency in Switches/Routers - Powering off switch/router components for energy efficiency could = have a detrimental effect on the applications unless the servers (sourcing = the applications) are also turned off - There are no open standards for this Energy efficiency in VNFs - The NFV requirements (high level) for energy efficiency are well d= efined in the NFV Virtualization Requirements document (http://www.etsi.org= /deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf) - A number of standard interfaces have been developed to support the= need to manage workloads across individual/multiple servers to achieve the= desired performance and power consumption. Notable established standards a= re: * Intelligent Platform Management Interface (IPMI 2.0) * Data Center Management Interface (DCMI 1.5) * DMTF Systems Management Architecture for Server Hardware (SMASH) As you pointed out, we need to take closer look, but I don't see a big prob= lem in coming to consensus on topic in a reasonable amount of time. Thanks, Ramki -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Wednesday, April 09, 2014 8:07 AM To: ramki Krishnan; Muhammad Durrani; Bhavani Parise; bmwg@ietf.org Subject: RE: [bmwg] draft-morton-bmwg-virtual-net-00 Hi Ramki, If you search our past work proposals, draft-manral-... proposed energy efficiency metrics and benchmarking. There is some controversy and complexity on making power measurements, we n= eed to collect these issues and see what can be done. Al ________________________________________ From: bmwg [bmwg-bounces@ietf.org] On Behalf Of ramki Krishnan [ramk@Brocad= e.com] Sent: Wednesday, April 09, 2014 10:12 AM To: Muhammad Durrani; Bhavani Parise; bmwg@ietf.org Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 Additionally, it would be worthwhile to discuss the common energy efficienc= y aspects across all VNFs. These would include discussing the tradeoffs bet= ween CPU energy efficiency/latency/throughput for various packet processing= schemes such as - Fixed polling - Adaptive polling - Changing processor P-states (this could be platform specific) Thanks, Ramki -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Muhammad Durrani Sent: Wednesday, March 19, 2014 12:27 AM To: Bhavani Parise; bmwg@ietf.org Subject: Re: [bmwg] draft-morton-bmwg-virtual-net-00 Hi Bhavani, - do we need to consider or compare performance with the real/physical netw= ork vs. the virtual network - in 3.2 do we need Virtual Switch [MD] We do need to provide methodologies to benchmark for three architectur= es vSwitch/SR-IOV and PCI bypass. Regarding comparing performance only PCI bypass can be compared with physic= al world. Again we are not benchmarking networks here but the virtual appl= iance and wherever needed comparison will be laid out for both Physical and= virtual appliance. for 3.2 how about load balancers, firewalls - do we need to consider, what = kind of DPI - firewalls - stateful vs stateless [MD] Virtual appliance is broader term - it means virtual Load balancer an= d firewalls (both state full and stateless) We won't be suggesting "kind of= DPI" - Standard method will be provided to qualify appliance for any type = of DPI Regards, Muhammad -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Bhavani Parise Sent: Wednesday, March 19, 2014 12:03 AM To: bmwg@ietf.org> Subject: [bmwg] draft-morton-bmwg-virtual-net-00 Al, including the WG list also for my comments/Qs for this draft. These are= a few things which we can look into including as considerations for this d= raft. - also for 3.2 - for VNF itself, do we need location of the VNF - guest VM,= separate process, appliance etc - - what kind of considerations we need to note when testing a Virtual Fi= rewall Function - how many Tenants can a VNF support? - for 3.3 - how about VM mobility or VNF mobility itself thanks, Bhavani ________________________________________ _______________________________________________ bmwg mailing list bmwg@ietf.org> https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list bmwg@ietf.org> https://www.ietf.org/mailman/listinfo/bmwg --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AF33HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Al,

 

There are some important and interesting differences between energy effic= iency in switches/routers vs VNFs (which runs on servers).

 

Energy e= fficiency in Switches/Routers

-        Powering off switch/router components for energy efficiency could ha= ve a detrimental effect on the applications unless the servers (sourcing th= e applications) are also turned off

-        There are no open standards for this

 

Energy efficiency i= n VNFs

- &n= bsp;      The NFV requirem= ents (high level) for energy efficiency are well defined in the NFV Virtual= ization Requirements document (http://www.etsi.org/d= eliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf)<= /o:p>

-   &nbs= p;    A number of standard interface= s have been developed to support the need to manage workloads across indivi= dual/multiple servers to achieve the desired performance and power consumpt= ion. Notable established standards are:

•     Intelligent = Platform Management Interface (IPMI 2.0)

•     Data Center= Management Interface (DCMI 1.5)

•     DMTF Systems Manage= ment Architecture for Server Hardware (SMASH)

 

As you pointed out, w= e need to take closer look, but I don’t see a big problem in coming t= o consensus on topic in a reasonable amount of time.

 

Thanks,

Ramki

 

-----Original Message-----From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Wednesday,= April 09, 2014 8:07 AM
To: ramki Krishnan; Muhammad Durrani; Bhavani Pa= rise; bmwg@ietf.org
Subject: RE: [bmwg] draft-morton-bmwg-virtual-net-00=

 

Hi= Ramki,

 

If you search our past work proposals,  draft-manral-.= ..

proposed energy efficiency metrics= and benchmarking.

There is some cont= roversy and complexity on making power measurements, we need to collect the= se issues and see what can be done.

<= o:p> 

Al

________________________________________

From: bmwg [bmwg-bounces@ietf.org] On Behalf Of ramki Krish= nan [ramk@Brocade.com]

Sent: Wednesda= y, April 09, 2014 10:12 AM

To: Muhamm= ad Durrani; Bhavani Parise; bmwg@ietf.org=

Subject: Re: [bmwg] draft-morton-bmwg-virtual-n= et-00

 

Additionally, it would be worthwhile to discuss the common = energy efficiency aspects across all VNFs. These would include discussing t= he tradeoffs between CPU energy efficiency/latency/throughput for various p= acket processing schemes such as

 

-     &nb= sp;  Fixed polling

 

-       = Adaptive polling

 

-        Chang= ing processor P-states (this could be platform specific)

 

 = ;

 

Thanks,

 

Ramki

 = ;

 

 

-----Original Message----= -

From: bmwg [mai= lto:bmwg-bounces@ietf.org] On Behalf Of Muhammad Durrani

Sent: Wednesday, March 19, 2014 12:27 AM

To: Bhavani Parise; bmwg@iet= f.org

Subject: Re: [bmwg] = draft-morton-bmwg-virtual-net-00

 

 

 

Hi Bhavani,

 

 

 

- do we need to consider or compare performance with the re= al/physical network vs. the virtual network

 

- in 3.2 do we need Vir= tual Switch

 

 

 = ;

[MD] We do need to provide methodologies= to benchmark for three architectures vSwitch/SR-IOV and PCI bypass.

 

Regarding comparing performance only PCI bypass can be compared with phys= ical world.  Again we are not benchmarking networks here but the virtu= al appliance and wherever needed comparison will be laid out for both Physi= cal and virtual appliance.

 = ;

 

 

for 3.2 how about load ba= lancers, firewalls - do we need to consider, what kind of DPI

 

 = ;   - firewalls - stateful vs stateless

 

[MD] Virtual appl= iance is broader term - it means virtual Load balancer  and firewalls = (both state full and stateless) We won't be suggesting "kind of DPI&qu= ot; - Standard method will be provided to qualify appliance for any type of= DPI

 

 

 =

Regards,

=  

Muhammad

 

-----Original= Message-----

 

From: bmwg [= mailto:bmwg-bounces@i= etf.org] On Behalf Of Bhavani Parise

 

Sent: Wednesday, Ma= rch 19, 2014 12:03 AM

 

To: bmwg@i= etf.org<mailto:bmwg@ietf.org>

 

Subject: [bmwg] draf= t-morton-bmwg-virtual-net-00

&nb= sp;

 

 

Al,

 

  = ;  including the WG list also for my comments/Qs for this draft. These= are a few things which we can look into including as considerations for th= is draft.

 

 

 <= /o:p>

- also for 3.2 - for VNF itself, do we nee= d location of the VNF - guest VM,separate process, appliance etc=

 

-<= o:p>

 

    - what kind of considerations we need to note wh= en testing a Virtual Firewall Function

 

- how many Tenants can a VNF= support?

 

- for 3.3 - how about VM mobility or VNF mobility itself<= o:p>

 

 

 

<= p class=3DMsoPlainText> 

&n= bsp;

thanks,

 

Bhavani

 

_____= ___________________________________

<= o:p> 

 

 

______________= _________________________________

 

bmwg mailing list

<= p class=3DMsoPlainText> 

bmwg@ietf.org<mailto:bmwg@ietf.org>

 

https://www.ietf.org/mail= man/listinfo/bmwg

&nb= sp;

 

 

_______________________= ________________________

 <= /o:p>

bmwg mailing list

 

bmwg@ietf.org<mailto:bmwg@ietf.org>

 

https://www.ietf.org/mailman/lis= tinfo/bmwg

 

= --_000_C7634EB63EFD984A978DFB46EA5174F2C00372AF33HQ1EXCH01corp_-- From nobody Sun Apr 13 23:51:57 2014 Return-Path: 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 B90501A0387 for ; Sun, 13 Apr 2014 23:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.073 X-Spam-Level: X-Spam-Status: No, score=-12.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 cctBW2CEZLwy for ; Sun, 13 Apr 2014 23:51:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE41A037D for ; Sun, 13 Apr 2014 23:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4551; q=dns/txt; s=iport; t=1397458309; x=1398667909; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dF5mfWP945DIb4Ts2DhYCErAZ8viijrOFD2lV2ggeis=; b=C4SH+4JlD1XSXXMt3N5SIUrpClH3plqIK0gbPVYsV34qY9sOwM3d7j1l hOx6Rd1EaF9EWxMV3TPRVgsxYJTx8vFRr5D3/4H5KVr7YYG1LmLv2y1TE QjHOlAnJLeB2oYAWqk6dvZ6btQ17R5hSez4ZY2CTZFySrqdR8peSe3eu0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADeES1OrRDoJ/2dsb2JhbABagwY7vDqHNYEfFnSCJQEBAQQBAQE1NgoRCxgJFg8JAwIBAgEVMAYBDAYCAQGHdw7LAReOdYQ4AQOJXI8FgTaRDYNRHQ X-IronPort-AV: E=Sophos;i="4.97,855,1389744000"; d="scan'208";a="107834614" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Apr 2014 06:51:49 +0000 Received: from sjc-lavramov-8816.cisco.com (sjc-lavramov-8816.cisco.com [10.19.100.135]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3E6plAJ015067; Mon, 14 Apr 2014 06:51:48 GMT Message-ID: <534B85FD.8050102@cisco.com> Date: Sun, 13 Apr 2014 23:53:49 -0700 From: "Lucien Avramov (lavramov)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , "bmwg@ietf.org" References: <2845723087023D4CB5114223779FA9C8017910D8A2@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017910D8A2@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/HP7iupW7Zz0w5dcLV6ibdtzno4U Subject: Re: [bmwg] New Charter Paragraphs X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 06:51:55 -0000 Hello BMWG! Suggesting some edits for the DC portion of the charter to include the benchmarking we have been talking and presenting at IEFT for the last year with Jacob Rapp: Data Center: -Bridging Some key concepts from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). Since devices that implement these new congestion-management specifications should never drop frames, and since the metric of throughput distinguishes between non-zero and zero drop rates, no throughput measurement is possible using the existing methodology. The current emphasis is on the Priority Flow Control aspects of Data Center Bridging, and the work will include an investigation into whether TRILL RBridges require any specific treatment in the methodology. This work will update RFC 2544 and exchange periodic Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. -Benchmarking Data Center DUT: The purpose of this informational document is to establish definitions, discussion and measurement techniques specific to data center environments. It is also to introduce definition terminologies applicable to data center performance evaluations. With these established, a methodology and measurement techniques for network equipement in the data center are covered. This includes data center specific congestion scenarios, switch buffer analysis, microburst, head of line blocking, while also using a wide mix of traffic conditions. This complements the existing benchmarking RFCs by specifying data center centric benchmarking. Cheers, Lucien On 3/27/14, 12:53 PM, MORTON, ALFRED C (AL) wrote: > BMWG, > > As we close in on the re-charter text, we decided at our IETF-89 session > to keep Datacenter and VNF paragraphs separate. > > To that end, we already have a Datacenter-oriented paragraph in our charter, > but it needs editing -- please make suggestions! > > * Data Center Bridging Devices: > Some key concepts from BMWG's past work are not meaningful when testing > switches that implement new IEEE specifications in the area of data > center bridging. For example, throughput as defined in RFC 1242 cannot > be measured when testing devices that implement three new IEEE > specifications: priority-based flow control (802.1Qbb); priority groups > (802.1Qaz); and congestion notification (802.1Qau). > Since devices that implement these new congestion-management > specifications should never drop frames, and since the metric of > throughput distinguishes between non-zero and zero drop rates, no > throughput measurement is possible using the existing methodology. > The current emphasis is on the Priority Flow Control aspects of > Data Center Bridging, and the work will include an investigation > into whether TRILL RBridges require any specific treatment in the > methodology. This work will update RFC 2544 and exchange periodic > Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. > > > Also, here's the (slightly modified) text for VNF activity: > > * VNF and related Infrastructure Benchmarking > > Benchmarking Methodologies have reliably characterized many physical devices. > This work item extends and enhances the methods to virtual network functions (VNF) > and their unique supporting infrastructure. First, the new task space will be > considered to ensure that common issues are considered from the start. > Virtual routers, switches and platform capacity and performance characteristics > will follow, including comparisons between physical and virtual functions. > > Finally, I'll leave it to the authors to say more, but I noticed a new draft > on our tools page: > > http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-00 > > take a look, is this something we should consider including on our ride? > > Comments by April 14th, please. > > regards, > Al/Sarah > bmwg co-chairs > > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg > From nobody Mon Apr 14 10:42:16 2014 Return-Path: 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 BD6011A06D7 for ; Mon, 14 Apr 2014 10:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 1ScBVJcJN5Ng for ; Mon, 14 Apr 2014 10:42:03 -0700 (PDT) Received: from mx0b-00158d01.pphosted.com (mx0b-00158d01.pphosted.com [67.231.152.180]) by ietfa.amsl.com (Postfix) with ESMTP id AD55C1A06C7 for ; Mon, 14 Apr 2014 10:42:03 -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 s3EHdSk6020353 for ; Mon, 14 Apr 2014 10:42:00 -0700 Received: from mx2.jdsu.com ([157.234.211.51]) by mx0b-00158d01.pphosted.com with ESMTP id 1k7wqsc6t8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Apr 2014 10:42:00 -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.174.1; Mon, 14 Apr 2014 10:41:56 -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.0174.001; Mon, 14 Apr 2014 10:41:59 -0700 From: Barry Constantine To: "bmwg@ietf.org" Thread-Topic: CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTg== Date: Mon, 14 Apr 2014 17:41:59 +0000 Message-ID: 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_DE2AAE0A8826CF4ABC3A6CCB756356EB2B3BE9AMEXMB01dsjdsunet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-14_01:2014-04-14,2014-04-14,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-1404140294 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/HGTjWWqefMXDw6XBJqAfZ06lp4U Subject: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:42:04 -0000 --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B3BE9AMEXMB01dsjdsunet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B3BE9AMEXMB01dsjdsunet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Folks

 

Looking to see if anyone has any exposure to the new= ly forming CloudEthernet Forum and how it may relate to other activities be= ing pursued by IETF.

 

Al,

 

If you prefer this be an off list discussion, please= indicate that so others may contact me off list.

 

Thank you,

Barry Constantine

--_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B3BE9AMEXMB01dsjdsunet_-- From nobody Mon Apr 14 11:39:03 2014 Return-Path: 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 5EA3A1A06AC for ; Mon, 14 Apr 2014 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 avAXqL9x6JpF for ; Mon, 14 Apr 2014 11:38:55 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id AF8A61A0203 for ; Mon, 14 Apr 2014 11:38:55 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 5F9B355413C; Mon, 14 Apr 2014 14:45:26 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id E4ED2F019A; Mon, 14 Apr 2014 14:38:52 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Mon, 14 Apr 2014 14:38:52 -0400 From: "MORTON, ALFRED C (AL)" To: Barry Constantine , "bmwg@ietf.org" Date: Mon, 14 Apr 2014 14:38:51 -0400 Thread-Topic: CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQ Message-ID: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944A39Dnjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/VCBNS2UkDt2Dz9id1fPslNaO6RQ Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:39:00 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A39Dnjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_2845723087023D4CB5114223779FA9C8017944A39Dnjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If there's someone who has expos= ure (and the answers),

plus something the bmwg pa= rticipants can learn and possibly

influence our f= uture activities, I think it would be appropriate

to discuss here.

 

bmwg co-chair

 

From:<= /b> bmwg= [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine
Sent: Monday, April 14, 2014 1:42 PM
To: bmwg@ietf.org
Subject: [bmwg] CloudEthernet Forum

<= p class=3DMsoNormal> 

Hello Folks

 

Looking to see if anyone has any exposure to the newly forming CloudEthern= et Forum and how it may relate to other activities being pursued by IETF.

 

Al,

 

If you prefer this be an off list discussion, please indicate that s= o others may contact me off list.

&= nbsp;

Thank you,

Barry Constantine

= --_000_2845723087023D4CB5114223779FA9C8017944A39Dnjfpsrvexg8re_-- From nobody Mon Apr 14 12:13:08 2014 Return-Path: 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 AF0B81A04A1 for ; Mon, 14 Apr 2014 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 EC554qyVnsbC for ; Mon, 14 Apr 2014 12:13:01 -0700 (PDT) Received: from mxr01.htp-tel.de (mxr01.htp-tel.de [81.14.243.49]) by ietfa.amsl.com (Postfix) with ESMTP id B687C1A063F for ; Mon, 14 Apr 2014 12:13:00 -0700 (PDT) Received: from mxrin02.htp-tel.de (mxrin.htp-tel.de [81.14.243.119]) by mxr01.htp-tel.de with ESMTP id s3EJChUp002579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Apr 2014 21:12:45 +0200 (CEST) Received: from WinLinux (a89-182-181-5.net-htp.de [89.182.181.5]) (authenticated bits=0) by mxrin02.htp-tel.de with ESMTP id s3EJCeV8018044; Mon, 14 Apr 2014 21:12:41 +0200 (CEST) From: "Reinhard Schrage" To: "'MORTON, ALFRED C \(AL\)'" , "'Barry Constantine'" , References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> Date: Mon, 14 Apr 2014 21:12:39 +0200 Message-ID: <002301cf5815$82900db0$87b02910$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CF5826.4618DDB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQAAEdGWA= Content-Language: en-gb X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (mxrin02.htp-tel.de [172.19.11.5]); Mon, 14 Apr 2014 21:12:43 +0200 (CEST) Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/3b11sRwzCzQSg0dnGBXLSF05L8M Cc: dromasca@avaya.com Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:13:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CF5826.4618DDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan Romascanu from Avaya is listed as director in this forum. He is also active in three WGs of the IETF: lmap, xrblock, sacm and has been active in alto. He might be able to comment? Best regards Reinhard Schrage t: +49 (0) 5137 909530 m: +49 (0) 172 26.36.046 reinhard@schrageconsult.com From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL) Sent: 14 April 2014 20:39 To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEthernet Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so others may contact me off list. Thank you, Barry Constantine ------=_NextPart_000_0024_01CF5826.4618DDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan Romascanu from Avaya is listed as director = in this forum.

He is also active in three WGs of the IETF: = lmap, xrblock, sacm and has been active in alto.

 

He might be able to = comment?

 

Best = regards

Reinhard Schrage

t:     +49 (0) 5137 = 909530

m:   +49 (0) 172  = 26.36.046

reinhard@schrageconsult.com

 

From:= bmwg = [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL)
Sent: 14 April 2014 20:39
To: Barry = Constantine; bmwg@ietf.org
Subject: Re: [bmwg] CloudEthernet = Forum

 

If = there's someone who has exposure (and the = answers),

plus something the = bmwg participants can learn and possibly

influence our = future activities, I think it would be = appropriate

to discuss = here.

 

Al

bmwg = co-chair

 

From:= bmwg [mailto:bmwg-bounces@ietf.org] = On Behalf Of Barry Constantine
Sent: Monday, April 14, = 2014 1:42 PM
To: bmwg@ietf.org
Subject: = [bmwg] CloudEthernet Forum

 

Hello Folks

 

Looking to see if anyone has any = exposure to the newly forming CloudEthernet Forum and how it may relate = to other activities being pursued by IETF.

 

Al,

 

If you prefer this be an off list = discussion, please indicate that so others may contact me off = list.

 

Thank you,

Barry = Constantine

------=_NextPart_000_0024_01CF5826.4618DDB0-- From nobody Mon Apr 14 12:18:53 2014 Return-Path: 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 758A61A02E9 for ; Mon, 14 Apr 2014 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 kZbfIgxvdVw2 for ; Mon, 14 Apr 2014 12:18:45 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id A8C8C1A0209 for ; Mon, 14 Apr 2014 12:18:45 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 8D664120340; Mon, 14 Apr 2014 15:25:02 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id F4158EF705; Mon, 14 Apr 2014 15:18:42 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Mon, 14 Apr 2014 15:18:31 -0400 From: "MORTON, ALFRED C (AL)" To: Reinhard Schrage , 'Barry Constantine' , "bmwg@ietf.org" Date: Mon, 14 Apr 2014 15:18:30 -0400 Thread-Topic: [bmwg] CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQAAEdGWAAAF1eMA== Message-ID: <2845723087023D4CB5114223779FA9C8017944A3B9@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> <002301cf5815$82900db0$87b02910$@net> In-Reply-To: <002301cf5815$82900db0$87b02910$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944A3B9njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/XhZcAeiAj-s7yZ5CfSfk9NZQG0w Cc: "dromasca@avaya.com" Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:18:50 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A3B9njfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nicely connected, Reinhard. Dan, are there any overlapping areas of interest between CloudEthernet Forum and your old friends in BMWG? Al From: Reinhard Schrage [mailto:rschrage@schrageconsult.net] Sent: Monday, April 14, 2014 3:13 PM To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org Cc: dromasca@avaya.com Subject: RE: [bmwg] CloudEthernet Forum Dan Romascanu from Avaya is listed as director in this forum. He is also active in three WGs of the IETF: lmap, xrblock, sacm and has bee= n active in alto. He might be able to comment? Best regards Reinhard Schrage t: +49 (0) 5137 909530 m: +49 (0) 172 26.36.046 reinhard@schrageconsult.com From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 14 April 2014 20:39 To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_2845723087023D4CB5114223779FA9C8017944A3B9njfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nicely connected, Reinhard. = ;

 

Dan, are ther= e any overlapping areas of interest between

Clo= udEthernet Forum and your old friends in BMWG?

 

Al

 

From: Reinhard Schrage= [mailto:rschrage@schrageconsult.net]
Sent: Monday, April 14, 20= 14 3:13 PM
To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@i= etf.org
Cc: dromasca@avaya.com
Subject: RE: [bmwg] Clou= dEthernet Forum

=  

Dan Romascanu from Avaya is listed as director in this forum.

He is also active in three WGs of the IETF: lmap, xrblock, sacm and has b= een active in alto.

 

He might be able to comment?=

 

Best regards

Reinhard Schrage

t= :     +49 (0) 5137 909530

m:   +49 (0) 172 = 26.36.046

reinhard@schragecons= ult.com

 

From: bmwg [mailto:b= mwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
S= ent: 14 April 2014 20:39
To: Barry Constantine; bmwg@ietf.org
Subject: Re: [bmwg] CloudEt= hernet Forum

 

If there's someone who has expo= sure (and the answers),

plus something the bmwg p= articipants can learn and possibly

influence our = future activities, I think it would be appropriate

 

bmwg co-chair

 

= --_000_2845723087023D4CB5114223779FA9C8017944A3B9njfpsrvexg8re_-- From nobody Mon Apr 14 14:22:15 2014 Return-Path: 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 3CB681A072B for ; Mon, 14 Apr 2014 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 naPdDUxNoUEH for ; Mon, 14 Apr 2014 14:22:10 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id F3DC91A0724 for ; Mon, 14 Apr 2014 14:22:09 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so8350630iec.25 for ; Mon, 14 Apr 2014 14:22:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=N1vY0ZUXtVR6pG4R/LXMu77bxXqR63n6BwMCnRoloq0=; b=lsuY3tTO1Y0b5n0VKznvGNsShtscLo1x32mVSvAIggM5gJ/eK09KqC+9Tlp7k2DChe Qb2dfEYxCyFu1ETrPdB8GUVvVzo3LOnujzGJwsLYbREJB7dGyC4CjAfa6AgzayDdjlLX ELWQnwpXilIVnef32dGOZnldm0HW71gdV+kVxTT1ACN0W/q24uvCvC2s1PCbqy5zmrQV +Wp5ri8FxqKusezWk52erADLY5O1OOn3XykyKBTKjP+88CW8EzzVrhOiexD2D1cAFFSb GBMUrmQrjEMlc+TTKg89juao7hA3V3hRmi6RmF+e4xFzLK10zewH515KlVEr3IOHBVsF +syQ== X-Gm-Message-State: ALoCoQkS4oCxzhexkbvSPn3OSNtg76zcMOFnNDbERQtUrsACRVRJYzs0IFGFiThtdAxIlJLZsxfw X-Received: by 10.50.47.12 with SMTP id z12mr18848445igm.37.1397510527296; Mon, 14 Apr 2014 14:22:07 -0700 (PDT) Received: from [192.168.0.197] (c-24-7-193-205.hsd1.il.comcast.net. [24.7.193.205]) by mx.google.com with ESMTPSA id s1sm30815965igr.14.2014.04.14.14.22.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Apr 2014 14:22:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 14 Apr 2014 16:22:01 -0500 From: Carol Davids To: William Cerveny , Message-ID: Thread-Topic: [bmwg] Comments on draft-ietf-bmwg-sip-bench-term-09 References: <1396894332.21912.103764125.7550637A@webmail.messagingengine.com> In-Reply-To: <1396894332.21912.103764125.7550637A@webmail.messagingengine.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/PNdIyIAZef_osZpTw7MTblwJHXY Subject: Re: [bmwg] Comments on draft-ietf-bmwg-sip-bench-term-09 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:22:14 -0000 Thanks. We will make the changes: consistently putting the acronym with the definition title, and replacing the =B3work item=B2 with =B3document.=B2 =B3Zero failures=B2 does correspond to "100% success", and we could remove "%100 success." We left it in for emphasis. We might find a different way to accomplish that. Regards. Carol Carol Davids Professor & Director RTC Lab Illinois Institute of Technology Office: 630-682-6024 Mobile: 630-292-9417 Email: davids@iit.edu Skype: caroldavids1 Web: rtc-lab.itm.iit.edu On 4/7/14, 1:12 PM, "William Cerveny" wrote: >My general comments about draft-ietf-bmwg-sip-bench-term-09 >1) Where the term has an associated acronym, include that acronym in the >definition title ... this is done in some cases, but not in others >2) Replace instances of "work item" with "document" >3) In section "3.4.2 Registration Rates", the document says: > >This benchmark is obtained with zero failures in which 100% of the > registrations attempted by the EA are successfully completed by > the DUT. > >Is "zero failures" redundant in the above text since 100% success would >imply "zero failures"? > >I've sent smaller comments directly to the authors. > >Regards, > >Bill Cerveny > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From nobody Mon Apr 14 14:23:15 2014 Return-Path: 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 C148D1A06E6 for ; Mon, 14 Apr 2014 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.399 X-Spam-Level: ** X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 jNKSvY4eWDfQ for ; Mon, 14 Apr 2014 14:23:08 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 201301A06AC for ; Mon, 14 Apr 2014 14:23:08 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id ar20so8749424iec.2 for ; Mon, 14 Apr 2014 14:23:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=y/M1r+VjABWiAKoBNIU3wVm7uvmSDNSLTWnr4UbJSms=; b=AlSFwLuBprpvBniwLwiKBiQx6tBOZjns3T3jiipIVdFJnCnvEEP5nYCrlYYy6EMWB+ EdUEiSTexg7iAGGw6z3ybL73VttIPzHEyU7XV8UsGHFozsso4PJi4/YFmlyQyDu35SXU 07CkxLFoIfm4Kjp6vE7NGMd1sAL4MV75O6O6ERD7VUeQFLRHdUwOv1CBpPLMcoU8oHq8 vZsGDVjKVwcSiEp8AzRh2jH9ld6O4aX73ngrmQUYxuSQVnj1yiiPljl0wXT+j5ecKXzk PEuTKw1A7UFwIxFBW/VB6+UuyjYlhlS3kCf3Q42+pRRWJgXlF0fxyEB14ZsCKZFdg2Al C3JQ== X-Gm-Message-State: ALoCoQk5zQBzCROJtjAE3N2ZJWpN4rGrO0qyvMNMHruXX55CYvu2QWo6F2vNQVr4poVZISCwBNRO X-Received: by 10.50.13.100 with SMTP id g4mr19180107igc.9.1397510585395; Mon, 14 Apr 2014 14:23:05 -0700 (PDT) Received: from [192.168.0.197] (c-24-7-193-205.hsd1.il.comcast.net. [24.7.193.205]) by mx.google.com with ESMTPSA id on9sm32357946igb.11.2014.04.14.14.23.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Apr 2014 14:23:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 14 Apr 2014 16:23:00 -0500 From: Carol Davids To: William Cerveny , Message-ID: Thread-Topic: [bmwg] My comments on draft-ietf-bmwg-sip-bench-meth-09 References: <1396883172.2235.103678713.65DD6B82@webmail.messagingengine.com> In-Reply-To: <1396883172.2235.103678713.65DD6B82@webmail.messagingengine.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/UyhoQoAjtr_cgiwjESbq_5wysKE Subject: Re: [bmwg] My comments on draft-ietf-bmwg-sip-bench-meth-09 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:23:11 -0000 Thanks. We will review as soon as possible. Regards, Carol Carol Davids Professor & Director RTC Lab Illinois Institute of Technology Office: 630-682-6024 Mobile: 630-292-9417 Email: davids@iit.edu Skype: caroldavids1 Web: rtc-lab.itm.iit.edu On 4/7/14, 10:06 AM, "William Cerveny" wrote: >Below are my high level comments on draft-ietf-bmwg-sip-bench-meth-09 >denoted by /* comment */ ; I'm sending more detailed (mostly grammatical >comments) directly to the authors. I've identified the section and >general line number in which the comment is made. > >Of note, I had trouble following the variables in the pseudocode, but I >may not have been following close enough attention to the code. > >Bill Cerveny > > > >desktop-10-36:scratch wcerveny$ cat grep-output-meth-2014-04-17.txt >1. Abstract: > >30- objective comparison of the capacity of SIP devices. Test setup >31- parameters and a methodology are necessary because SIP allows a >wide >32- range of configuration and operational conditions that can >influence >33:/* In my opinion, sentence beginning with "A standard terminology >..." >34: is an assumed and I'm not sure it should be in the abstract */ >35- performance benchmark measurements. A standard terminology and >36- methodology will ensure that benchmarks have consistent definition >37- and were obtained following the same procedures. >-- >2. Introduction: >-- >200- only. >201- >202- The device-under-test (DUT) is a SIP server, which may be any SIP >203:/* Capitalization in "Benchmarks can be ..." is inconsistant */ >204- conforming [RFC3261] device. Benchmarks can be obtained and >compared >205- for different types of devices such as SIP Proxy Server, Session >206- Border Controllers (SBC), SIP registrars and SIP proxy server >paired >-- >-- >208- >209- The test cases provide metrics for benchmarking the maximum 'SIP >210- Registration Rate' and maximum 'SIP Session Establishment Rate' >that >211:/* Is "extended period" defined? */ >212- the DUT can sustain over an extended period of time without >failures. >213- Some cases are included to cover Encrypted SIP. The test >topologies >214- that can be used are described in the Test Setup section. >Topologies >-- >-- >219- >220- SIP permits a wide range of configuration options that are >explained >221- in Section 4 and Section 2 of [I-D.sip-bench-term]. Benchmark >values >222:/* Is associated media defined */ >223- could possibly be impacted by Associated Media. The selected >values >224- for Session Duration and Media Streams per Session enable >benchmark >225- >-- >3. Benchmarking Topologies >-- >259- >260- There are two test topologies; one in which the DUT does not >process >261- the media (Figure 1) and the other in which it does process media >262:/* EA defined? */ >263- (Figure 2). In both cases, the tester or EA sends traffic into >the >264- DUT and absorbs traffic from the DUT. The diagrams in Figure 1 >and >265- Figure 2 represent the logical flow of information and do not >dictate >-- >4.3 Associated Media >-- >346-4.3. Associated Media >347- >348- Some tests require Associated Media to be present for each SIP >349:/* Is this redundant? */ >350- session. The test topologies to be used when benchmarking DUT >351- performance for Associated Media are shown in Figure 1 and Figure >2. >352- >-- >4.6 Session Duration >-- >370- >371- The value of the DUT's performance benchmarks may vary with the >372- duration of SIP sessions. Session Duration MUST be reported with >373:/* I'm not sure if this sentence ("A Session Duration ...") is >properly >374-formed (it might be), but I had difficulty following the logic of >the >375:sentence */ >376- benchmarking results. A Session Duration of zero seconds >indicates >377- transmission of a BYE immediately following successful SIP >378- establishment indicate by receipt of a 200 OK. An infinite >Session >-- >4.8 Benchmarking algorithm >-- >409- >410- During the Candidate Identification phase, the test runs until n >411- sessions have been attempted, at session attempt rates, r, which >vary >412:/* Upper case N and lower case n are different variables?? Same with >"R" */ >413- according to the algorithm below, where n is also a parameter of >test >414- and is a relatively large number, but an order of magnitude >smaller >415- than N. If no errors occur during the time it takes to attempt n >-- >-- >415- than N. If no errors occur during the time it takes to attempt n >416- sessions, we increment r according to the algorithm. If errors >are >417- encountered during the test, we decrement r according to the >418:/* sentence "The algorithm provides ..." needs clarification >419:Is the word "how" unnecessary? */ >420- algorithm. The algorithm provides a variable, G, that allows us >to >421- control how the accuracy, in sessions per second, that we require >of >422- the test. >-- >-- >422- the test. >423- >424- After this candidate rate has been discovered, the test enters >the >425:/* Is N consistent with N in pseudocode? */ >426- Steady State phase. In the Steady State phase, N session >Attempts >427- are made at the candidate rate. The goal is to find a rate at >which >428- the DUT can process calls "forever" with no errors and the test >-- >-- >432- the steady-state phase is entered again until a final (new) >steady- >433- state rate is achieved. >434- >435:/* Would this process be clearer if presented as a list? */ >436- The iterative process itself is defined as follows: A starting >rate >437- of r = 100 sessions per second is used and we place calls at that >438- rate until n = 5000 calls have been placed. If all n calls are >-- >-- >436- The iterative process itself is defined as follows: A starting >rate >437- of r = 100 sessions per second is used and we place calls at that >438- rate until n = 5000 calls have been placed. If all n calls are >439:/* sps defined? This said, it's easy to figure out */ >440- successful, the rate is increased to 150 sps and again we place >calls >441- at that rate until n = 5000 calls have been placed. The attempt >rate >442- is continuously ramped up until a failure is encountered before n >= >-- >-- >449- between the rate at which failures occurred and the last >successful >450- rate. Continuing in this way, an attempt rate without errors is >451- found. The tester can specify a margin of error using the >parameter G, >452:/* units? */ >453- measured in units of sessions per second. >454- >455- The pseudo-code corresponding to the description above follows. >-- >-- >478- G := 5 ; granularity of results - the margin of error in >479- ; sps >480- C := 0.05 ; calibration amount: How much to back down if we >481:/* using "s" before definition, in my opinion; consider "found >candidate rate >482:s but cannot send at s" (Still not right, though ... */ >483- ; have found candidate s but cannot send at rate >s >484- ; for time T without failures >485- >-- >-- >487- ; ---- Initialization of flags, candidate values and upper >bounds >488- >489- f := false ; indicates a success after the upper limit >490:/* Capital F never used in pseudocode */ >491- F := false ; indicates that test is done >492- c := 0 ; indicates that we have found an upper limit >493- >-- >-- >499- ; characteristics until n >500- ; requests have been sent >501- if (all requests succeeded) { >502:/* undefined variable r'? does this matter? */ >503- r' := r ; save candidate value of metric >504- if ( c == 0 ) { >-- >6.3 Session Establishment Rate with Media not on DUT >-- >649- be recorded using any pertinent parameters as shown in the >650- reporting format of Section 5.1. >651- >652:/* Long sentence in general, but minimally last part of sentence >doesn't >653:conclude */ >654- Expected Results: Session Establishment Rate results obtained >with >655- Associated Media with any number of media streams per SIP >session >656- are expected to be identical to the Session Establishment Rate > > > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From nobody Tue Apr 15 07:33:53 2014 Return-Path: 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 91C931A0430 for ; Tue, 15 Apr 2014 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 ILem6uFq8MBp for ; Tue, 15 Apr 2014 07:33:47 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFE1A00FB for ; Tue, 15 Apr 2014 07:33:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAHFCTVOHCzIm/2dsb2JhbABYgkIjITtXwymBIhZ0giUBAQEBAxIbRRcCAQgNBAEDAQELHQcyFAMGCAEBBAESCBqHWgGeZq04F44yNwGDJIEUBJ9ei0mDMYIr X-IronPort-AV: E=Sophos; i="4.97,864,1389762000"; d="scan'208,217"; a="58255967" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 15 Apr 2014 10:33:30 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 Apr 2014 10:32:53 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 16:33:28 +0200 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , Reinhard Schrage , 'Barry Constantine' , "bmwg@ietf.org" Thread-Topic: [bmwg] CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQAAEdGWAAAF1eMAAoX32Q Date: Tue, 15 Apr 2014 14:33:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7AF112@AZ-FFEXMB04.global.avaya.com> References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> <002301cf5815$82900db0$87b02910$@net> <2845723087023D4CB5114223779FA9C8017944A3B9@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A3B9@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C7AF112AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/Ttqxvkn9rs-yUON-2OKUOu21U44 Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:33:51 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7AF112AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Yep, I am a co-chair of the Technical Committee at the CEF (starting with l= ast week). The short answer to the question asked by Barry is that there is no immedia= te overlap on short term, but there may be possible relationship in the fut= ure. The CEF has recently started the technical work, and approved its firs= t project at the meeting in Budapest last week which is a Reference Archite= cture document for Cloud Ethernet Services aiming to provide the framework = for the definition of the functions and services. A program (testbed) for e= valuating performance and compliance to the functions and parameters of the= services called OpenCloud was announced as part of the roadmap of the CEF,= this is also a recent announcement, and this is where possible dialog and = interaction between BMWG (and IPPM, and maybe other IETF WGs) and the CEF m= ay be useful. Obviously I will be glad to enable and be part of this dialog= . Regards, Dan From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Monday, April 14, 2014 10:19 PM To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org Cc: Romascanu, Dan (Dan) Subject: RE: [bmwg] CloudEthernet Forum Nicely connected, Reinhard. Dan, are there any overlapping areas of interest between CloudEthernet Forum and your old friends in BMWG? Al From: Reinhard Schrage [mailto:rschrage@schrageconsult.net] Sent: Monday, April 14, 2014 3:13 PM To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org Cc: dromasca@avaya.com Subject: RE: [bmwg] CloudEthernet Forum Dan Romascanu from Avaya is listed as director in this forum. He is also active in three WGs of the IETF: lmap, xrblock, sacm and has bee= n active in alto. He might be able to comment? Best regards Reinhard Schrage t: +49 (0) 5137 909530 m: +49 (0) 172 26.36.046 reinhard@schrageconsult.com From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 14 April 2014 20:39 To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7AF112AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Yep, I am a co-chair of the Technical Committee at the CEF (starting with l= ast week).

The short answer to the question asked by Barry is that there is no immedia= te overlap on short term, but there may be possible relationship in the fut= ure. The CEF has recently started the technical work, and approved its firs= t project at the meeting in Budapest last week which is a Reference Architecture document for Cloud Ethernet Se= rvices aiming to provide the framework for the definition of the functions = and services. A program (testbed) for evaluating performance and compliance= to the functions and parameters of the services called OpenCloud was announced as part of the roadmap of t= he CEF, this is also a recent announcement, and this is where possible dial= og and interaction between BMWG (and IPPM, and maybe other IETF WGs) and th= e CEF may be useful. Obviously I will be glad to enable and be part of this dialog.

Regards,

Dan

 

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Monday, April 14, 2014 10:19 PM
To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org
Cc: Romascanu, Dan (Dan)
Subject: RE: [bmwg] CloudEthernet Forum

 

Nicely connected, Reinhard. 

 

Dan, are there any overlapping areas of interest between

CloudEthernet Forum and your old friends in BMWG?

 

Al

 

From: Reinhard= Schrage [mailto:rschrage@sc= hrageconsult.net]
Sent: Monday, April 14, 2014 3:13 PM
To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org
Cc: dromasca@avaya.com
Subject: RE: [bmwg] CloudEthernet Forum

 

Dan Rom= ascanu from Avaya is listed as director in this forum.

He is a= lso active in three WGs of the IETF: lmap, xrblock, sacm and has been activ= e in alto.

&n= bsp;

He migh= t be able to comment?

&n= bsp;

Best regar= ds

Reinhard S= chrage

t: &n= bsp;   +49 (0) 5137 909530

m:   +49= (0) 172  26.36.046

reinhard@schrageconsult.com<= /p>

&n= bsp;

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: 14 April 2014 20:39
To: Barry Constantine; bmwg@ietf.or= g
Subject: Re: [bmwg] CloudEthernet Forum

 

If there's someone who has exposure (and the answers),

plus something the bmwg participants can learn and possibl= y

influence our future activities, I think it would be appro= priate

to discuss here.

 

Al

bmwg co-chair

 

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine
Sent: Monday, April 14, 2014 1:42 PM
To: bmwg@ietf.org
Subject: [bmwg] CloudEthernet Forum

 

Hello Folks

 

Looking to see if anyone has any exposure to the new= ly forming CloudEthernet Forum and how it may relate to other activities be= ing pursued by IETF.

 

Al,

 

If you prefer this be an off list discussion, please= indicate that so others may contact me off list.

 

Thank you,

Barry Constantine

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7AF112AZFFEXMB04globa_-- From nobody Tue Apr 15 07:50:10 2014 Return-Path: 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 2520B1A030A for ; Tue, 15 Apr 2014 07:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 5UTC5LidEKGw for ; Tue, 15 Apr 2014 07:50:02 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5A1A02F7 for ; Tue, 15 Apr 2014 07:50:02 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 556BA1202B7; Tue, 15 Apr 2014 10:50:01 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id BCB69E01E9; Tue, 15 Apr 2014 10:49:59 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 15 Apr 2014 10:49:59 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , Reinhard Schrage , 'Barry Constantine' , "bmwg@ietf.org" Date: Tue, 15 Apr 2014 10:49:57 -0400 Thread-Topic: [bmwg] CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQAAEdGWAAAF1eMAAoX32QAACRkqA= Message-ID: <2845723087023D4CB5114223779FA9C8017944A46B@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> <002301cf5815$82900db0$87b02910$@net> <2845723087023D4CB5114223779FA9C8017944A3B9@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7AF112@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7AF112@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944A46Bnjfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/UjnvTKxv8r0G4GAsiwDlk_xC21M Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:50:08 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A46Bnjfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your reply, Dan. We look forward to a more detailed exchange when timing is right. best regards, Al bmwg co-chair From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, April 15, 2014 10:33 AM To: MORTON, ALFRED C (AL); Reinhard Schrage; 'Barry Constantine'; bmwg@ietf= .org Subject: RE: [bmwg] CloudEthernet Forum Hi, Yep, I am a co-chair of the Technical Committee at the CEF (starting with l= ast week). The short answer to the question asked by Barry is that there is no immedia= te overlap on short term, but there may be possible relationship in the fut= ure. The CEF has recently started the technical work, and approved its firs= t project at the meeting in Budapest last week which is a Reference Archite= cture document for Cloud Ethernet Services aiming to provide the framework = for the definition of the functions and services. A program (testbed) for e= valuating performance and compliance to the functions and parameters of the= services called OpenCloud was announced as part of the roadmap of the CEF,= this is also a recent announcement, and this is where possible dialog and = interaction between BMWG (and IPPM, and maybe other IETF WGs) and the CEF m= ay be useful. Obviously I will be glad to enable and be part of this dialog= . Regards, Dan From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Monday, April 14, 2014 10:19 PM To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org Cc: Romascanu, Dan (Dan) Subject: RE: [bmwg] CloudEthernet Forum Nicely connected, Reinhard. Dan, are there any overlapping areas of interest between CloudEthernet Forum and your old friends in BMWG? Al From: Reinhard Schrage [mailto:rschrage@schrageconsult.net] Sent: Monday, April 14, 2014 3:13 PM To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org Cc: dromasca@avaya.com Subject: RE: [bmwg] CloudEthernet Forum Dan Romascanu from Avaya is listed as director in this forum. He is also active in three WGs of the IETF: lmap, xrblock, sacm and has bee= n active in alto. He might be able to comment? Best regards Reinhard Schrage t: +49 (0) 5137 909530 m: +49 (0) 172 26.36.046 reinhard@schrageconsult.com From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 14 April 2014 20:39 To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_2845723087023D4CB5114223779FA9C8017944A46Bnjfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your reply, Dan. = ; We look forward to a more detailed

exchange whe= n timing is right.

 

Al

bmw= g co-chair

 

From: Romascanu, Dan (Dan) [mailto:dromasca@a= vaya.com]
Sent: Tuesday, April 15, 2014 10:33 AM
To: M= ORTON, ALFRED C (AL); Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org<= br>Subject: RE: [bmwg] CloudEthernet Forum

 

Hi,

Yep, I am a co-chair of the Techn= ical Committee at the CEF (starting with last week).

The short answ= er to the question asked by Barry is that there is no immediate overlap on = short term, but there may be possible relationship in the future. The CEF h= as recently started the technical work, and approved its first project at t= he meeting in Budapest last week which is a Reference Architecture document= for Cloud Ethernet Services aiming to provide the framework for the defini= tion of the functions and services. A program (testbed) for evaluating perf= ormance and compliance to the functions and parameters of the services call= ed OpenCloud was announced as part of the roadmap of the CEF, this is also = a recent announcement, and this is where possible dialog and interaction be= tween BMWG (and IPPM, and maybe other IETF WGs) and the CEF may be useful. = Obviously I will be glad to enable and be part of this dialog.

Rega= rds,

Dan

 

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Monday, April 14, 2014 10:1= 9 PM
To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org
Cc: Romascanu, Dan (Dan)
= Subject: RE: [bmwg] CloudEthernet Forum

 

Nicely connected, Reinhard= . 

 

Dan, ar= e there any overlapping areas of interest between

Al

 = ;

From: Reinhard S= chrage [mailto:rschrage@schr= ageconsult.net]
Sent: Monday, April 14, 2014 3:13 PM
T= o: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org
Cc: dromasca@avaya.com
Subject: RE: [bmwg] CloudEthernet Foru= m

 

Dan Romas= canu from Avaya is listed as director in this forum.

<= p class=3DMsoNormal>He is also a= ctive in three WGs of the IETF: lmap, xrblock, sacm and has been active in = alto.

 

He might be able to comment?

 

Best regards

Reinhard Schrage

<= p class=3DMsoNormal>t:  &= nbsp;  +49 (0) 5137 909530

<= span style=3D'color:#1F497D'>m:   +49 (0) 172  26.36.046

reinhard@schrageconsult.com

 

Fro= m: bmwg [mailto:bmwg-bounces@ie= tf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: 14 Ap= ril 2014 20:39
To: Barry Constantine; bmwg@ietf.org
Subject: Re: [bmwg] CloudEthernet Forum

 

If there's someone who has exposure (and the = answers),

plus something the bmwg participants ca= n learn and possibly

influence our future activi= ties, I think it would be appropriate

to discuss = here.

 

Al

bmwg co-chair

=  

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behal= f Of Barry Constantine
Sent: Monday, April 14, 2014 1:42 PMTo: bmwg@ietf.org
Subje= ct: [bmwg] CloudEthernet Forum

 

Hello Folks

 

Looki= ng to see if anyone has any exposure to the newly forming CloudEthernet For= um and how it may relate to other activities being pursued by IETF.

 

Al,

 

If you prefer this be an off list discussion, please indicate that so othe= rs may contact me off list.

 <= /o:p>

Thank you,

Barry Constantine

= --_000_2845723087023D4CB5114223779FA9C8017944A46Bnjfpsrvexg8re_-- From nobody Tue Apr 15 09:44:13 2014 Return-Path: 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 C7D2D1A0499 for ; Tue, 15 Apr 2014 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 NRnEAHZvCMtX for ; Tue, 15 Apr 2014 09:44:05 -0700 (PDT) Received: from mx0b-00158d01.pphosted.com (mx0b-00158d01.pphosted.com [67.231.152.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB631A01BE for ; Tue, 15 Apr 2014 09:44:03 -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 s3FGhuUL020315; Tue, 15 Apr 2014 09:43:58 -0700 Received: from mx2.jdsu.com ([157.234.211.51]) by mx0b-00158d01.pphosted.com with ESMTP id 1k9530rwag-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:43:57 -0700 Received: from AMEXHTCA01.ds.jdsu.net (10.239.69.11) by mx2.jdsu.com (10.239.15.51) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 15 Apr 2014 09:43:43 -0700 Received: from AMEXMB01.ds.jdsu.net ([fe80::9402:2c4c:29f3:a264]) by AMEXHTCA01.ds.jdsu.net ([fe80::def:afde:7a37:2c3b%15]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 09:43:48 -0700 From: Barry Constantine To: "Romascanu, Dan (Dan)" , "MORTON, ALFRED C (AL)" , Reinhard Schrage , "bmwg@ietf.org" Thread-Topic: [bmwg] CloudEthernet Forum Thread-Index: Ac9YCKZmBfah6Ym+Szu7jv6XIoulTgAB3bGQAAEdGWAAAF1eMAAoX32QAASIAYA= Date: Tue, 15 Apr 2014 16:43:48 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> <002301cf5815$82900db0$87b02910$@net> <2845723087023D4CB5114223779FA9C8017944A3B9@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7AF112@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7AF112@AZ-FFEXMB04.global.avaya.com> 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_DE2AAE0A8826CF4ABC3A6CCB756356EB2B4DC5AMEXMB01dsjdsunet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-15_02:2014-04-15,2014-04-15,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-1404150273 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/XN5H-Wl0-1kYHCJAEDqoFYj8NAw Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:44:10 -0000 --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B4DC5AMEXMB01dsjdsunet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the reply, Dan. Do you see the need for test and measurement industry presence in the techn= ical committee you for which you are co-chair? Thank you, Barry Constantine From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, April 15, 2014 10:33 AM To: MORTON, ALFRED C (AL); Reinhard Schrage; Barry Constantine; bmwg@ietf.o= rg Subject: RE: [bmwg] CloudEthernet Forum Hi, Yep, I am a co-chair of the Technical Committee at the CEF (starting with l= ast week). The short answer to the question asked by Barry is that there is no immedia= te overlap on short term, but there may be possible relationship in the fut= ure. The CEF has recently started the technical work, and approved its firs= t project at the meeting in Budapest last week which is a Reference Archite= cture document for Cloud Ethernet Services aiming to provide the framework = for the definition of the functions and services. A program (testbed) for e= valuating performance and compliance to the functions and parameters of the= services called OpenCloud was announced as part of the roadmap of the CEF,= this is also a recent announcement, and this is where possible dialog and = interaction between BMWG (and IPPM, and maybe other IETF WGs) and the CEF m= ay be useful. Obviously I will be glad to enable and be part of this dialog= . Regards, Dan From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Monday, April 14, 2014 10:19 PM To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org Cc: Romascanu, Dan (Dan) Subject: RE: [bmwg] CloudEthernet Forum Nicely connected, Reinhard. Dan, are there any overlapping areas of interest between CloudEthernet Forum and your old friends in BMWG? Al From: Reinhard Schrage [mailto:rschrage@schrageconsult.net] Sent: Monday, April 14, 2014 3:13 PM To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org Cc: dromasca@avaya.com Subject: RE: [bmwg] CloudEthernet Forum Dan Romascanu from Avaya is listed as director in this forum. He is also active in three WGs of the IETF: lmap, xrblock, sacm and has bee= n active in alto. He might be able to comment? Best regards Reinhard Schrage t: +49 (0) 5137 909530 m: +49 (0) 172 26.36.046 reinhard@schrageconsult.com From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: 14 April 2014 20:39 To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B4DC5AMEXMB01dsjdsunet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the reply, = Dan.

 

Do you see the need fo= r test and measurement industry presence in the technical committee you for= which you are co-chair?

 

Thank you,<= /span>

Barry Constantine=

 

 

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, April 15, 2014 10:33 AM
To: MORTON, ALFRED C (AL); Reinhard Schrage; Barry Constantine; bmwg= @ietf.org
Subject: RE: [bmwg] CloudEthernet Forum

 

Hi,

Yep, I am a co-chair of the Technical Committee at the CEF (starting with l= ast week).

The short answer to the question asked by Barry is that there is no immedia= te overlap on short term, but there may be possible relationship in the fut= ure. The CEF has recently started the technical work, and approved its firs= t project at the meeting in Budapest last week which is a Reference Architecture document for Cloud Ethernet Se= rvices aiming to provide the framework for the definition of the functions = and services. A program (testbed) for evaluating performance and compliance= to the functions and parameters of the services called OpenCloud was announced as part of the roadmap of t= he CEF, this is also a recent announcement, and this is where possible dial= og and interaction between BMWG (and IPPM, and maybe other IETF WGs) and th= e CEF may be useful. Obviously I will be glad to enable and be part of this dialog.

Regards,

Dan

 

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com<= /a>]
Sent: Monday, April 14, 2014 10:19 PM
To: Reinhard Schrage; 'Barry Constantine'; bmwg@ietf.org
Cc: Romascanu, Dan (Dan)
Subject: RE: [bmwg] CloudEthernet Forum

 

Nicely connected, Reinhard. 

 

Dan, are there any overlapping areas of interest between

CloudEthernet Forum and your old friends in BMWG?

 

Al

 

From: Reinhard= Schrage [mailto:rschrage@sc= hrageconsult.net]
Sent: Monday, April 14, 2014 3:13 PM
To: MORTON, ALFRED C (AL); 'Barry Constantine'; bmwg@ietf.org
Cc: dromasca@avaya.com
Subject: RE: [bmwg] CloudEthernet Forum

 

Dan Rom= ascanu from Avaya is listed as director in this forum.

He is a= lso active in three WGs of the IETF: lmap, xrblock, sacm and has been activ= e in alto.

&n= bsp;

He migh= t be able to comment?

&n= bsp;

Best regar= ds

Reinhard S= chrage

t: &n= bsp;   +49 (0) 5137 909530

m:   +49= (0) 172  26.36.046

reinhard@schrageconsult.com<= /p>

&n= bsp;

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL)
Sent: 14 April 2014 20:39
To: Barry Constantine; bmwg@ietf.or= g
Subject: Re: [bmwg] CloudEthernet Forum

 

If there's someone who has exposure (and the answers),

plus something the bmwg participants can learn and possibl= y

influence our future activities, I think it would be appro= priate

to discuss here.

 

Al

bmwg co-chair

 

From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine
Sent: Monday, April 14, 2014 1:42 PM
To: bmwg@ietf.org
Subject: [bmwg] CloudEthernet Forum

 

Hello Folks

 

Looking to see if anyone has any exposure to the new= ly forming CloudEthernet Forum and how it may relate to other activities be= ing pursued by IETF.

 

Al,

 

If you prefer this be an off list discussion, please= indicate that so others may contact me off list.

 

Thank you,

Barry Constantine

--_000_DE2AAE0A8826CF4ABC3A6CCB756356EB2B4DC5AMEXMB01dsjdsunet_-- From nobody Tue Apr 15 09:52:39 2014 Return-Path: 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 F12771A011A; Tue, 15 Apr 2014 09:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 we4MKaWE1SOs; Tue, 15 Apr 2014 09:52:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E96F71A04C2; Tue, 15 Apr 2014 09:52:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 93C4118000C; Tue, 15 Apr 2014 09:52:05 -0700 (PDT) To: fernando@gont.com.ar, cpopovic@cisco.com, ahamza@cisco.com, gunter@cisco.com, diego@fastsoft.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140415165205.93C4118000C@rfc-editor.org> Date: Tue, 15 Apr 2014 09:52:05 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/7FsEQungt1_TMCNVlqIPhcZFlCA Cc: iesg@ietf.org, bmwg@ietf.org, rfc-editor@rfc-editor.org Subject: [bmwg] [Errata Verified] RFC5180 (3953) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:52:37 -0000 The following errata report has been verified for RFC5180, "IPv6 Benchmarking Methodology for Network Interconnect Devices". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5180&eid=3953 -------------------------------------- Status: Verified Type: Editorial Reported by: Fernando Gont Date Reported: 2014-04-07 Verified by: Benoit Claise (IESG) Section: 3 Original Text ------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 6 as possible. Corrected Text -------------- Nevertheless, for each evaluated device, it is recommended to perform as many of the applicable tests described in Section 7 as possible. Notes ----- -------------------------------------- RFC5180 (draft-ietf-bmwg-ipv6-meth-05) -------------------------------------- Title : IPv6 Benchmarking Methodology for Network Interconnect Devices Publication Date : May 2008 Author(s) : C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin Category : INFORMATIONAL Source : Benchmarking Methodology Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Apr 16 07:48:16 2014 Return-Path: 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 982B71A01D6 for ; Wed, 16 Apr 2014 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no 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 E38TkVDpoyzp for ; Wed, 16 Apr 2014 07:48:10 -0700 (PDT) Received: from mail.veryxtech.com (mail.veryxtech.com [203.196.171.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34F1C1A015D for ; Wed, 16 Apr 2014 07:47:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.veryxtech.com (Postfix) with ESMTP id 7932C3740DD; Wed, 16 Apr 2014 20:17:44 +0530 (IST) X-Virus-Scanned: amavisd-new at veryxtech.com Received: from mail.veryxtech.com ([127.0.0.1]) by localhost (mail.veryxtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozh6WbbXSm-d; Wed, 16 Apr 2014 20:17:39 +0530 (IST) Received: from LT015PC (unknown [192.168.12.88]) by mail.veryxtech.com (Postfix) with ESMTPSA id B585F3740D1; Wed, 16 Apr 2014 20:17:39 +0530 (IST) From: "Bhuvan \(Veryx Technologies\)" To: "'MORTON, ALFRED C \(AL\)'" References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> Date: Wed, 16 Apr 2014 20:17:42 +0530 Message-ID: <008e01cf5982$d25e4e10$771aea30$@veryxtech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01CF59B0.EC18FB10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFb8CCUVJhpbJJ/AGiWEcoxExMl1QE1ey7vm/FmrKA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/b62fZZEjsmZnI0J7vq9Y8WTPvUE Cc: bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:48:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008F_01CF59B0.EC18FB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Al, I represent Veryx, a Test and Measurement solution provider focusing on networking and communications industry. We are a member of CEF and would be keen to track and support bmwg's initiatives. Regards, Bhuvan From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL) Sent: Tuesday, April 15, 2014 12:09 AM To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEthernet Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so others may contact me off list. Thank you, Barry Constantine ------=_NextPart_000_008F_01CF59B0.EC18FB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Al,

 

I represent = Veryx, a Test and Measurement solution provider focusing on networking = and communications industry.

We are a = member of CEF and would be keen to track and support bmwg’s = initiatives.

 

Regards,

Bhuvan

 

From:= = bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL)
Sent: Tuesday, April 15, 2014 12:09 AM
To: = Barry Constantine; bmwg@ietf.org
Subject: Re: [bmwg] = CloudEthernet Forum

 

If there's someone = who has exposure (and the answers),

plus something the bmwg participants can learn and = possibly

influence our = future activities, I think it would be = appropriate

to discuss = here.

 

Al

bmwg = co-chair

 

From:= = bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry = Constantine
Sent: Monday, April 14, 2014 1:42 PM
To: = bmwg@ietf.org
Subject: [bmwg] CloudEthernet = Forum

 

Hello = Folks

 

Looking to see if anyone has any exposure to the newly = forming CloudEthernet Forum and how it may relate to other activities = being pursued by IETF.

 

Al,

 

If you = prefer this be an off list discussion, please indicate that so others = may contact me off list.

 

Thank = you,

Barry = Constantine

------=_NextPart_000_008F_01CF59B0.EC18FB10-- From nobody Wed Apr 16 08:03:00 2014 Return-Path: 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 DFB7C1A019B for ; Wed, 16 Apr 2014 08:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 zmIjmfChemfu for ; Wed, 16 Apr 2014 08:01:58 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C01A01BC for ; Wed, 16 Apr 2014 08:01:58 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-red.research.att.com (Postfix) with ESMTP id 896BA5547C3; Wed, 16 Apr 2014 11:01:59 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 89FACE01F4; Wed, 16 Apr 2014 11:01:53 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Wed, 16 Apr 2014 11:01:54 -0400 From: "MORTON, ALFRED C (AL)" To: "Bhuvan (Veryx Technologies)" Date: Wed, 16 Apr 2014 11:01:53 -0400 Thread-Topic: [bmwg] CloudEthernet Forum Thread-Index: AQFb8CCUVJhpbJJ/AGiWEcoxExMl1QE1ey7vm/FmrKCAABS9gA== Message-ID: <2845723087023D4CB5114223779FA9C8017944A670@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8017944A39D@njfpsrvexg8.research.att.com> <008e01cf5982$d25e4e10$771aea30$@veryxtech.com> In-Reply-To: <008e01cf5982$d25e4e10$771aea30$@veryxtech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8017944A670njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/m8YKwrq5QXF5krNYuomBWutCtPM Cc: "bmwg@ietf.org" Subject: Re: [bmwg] CloudEthernet Forum X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:02:10 -0000 X-List-Received-Date: Wed, 16 Apr 2014 15:02:10 -0000 --_000_2845723087023D4CB5114223779FA9C8017944A670njfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good to meet you Bhuvan, and welcome to BMWG. You can see the proceedings from our March '14 session here: https://datatracker.ietf.org/meeting/89/materials.html#ops and lots of other background info is here: https://datatracker.ietf.org/wg/bmwg/ Also, allow me to introduce you to co-chair Sarah Banks. regards, Al bmwg co-chair From: Bhuvan (Veryx Technologies) [mailto:bhuvaneswaran.vengainathan@veryxt= ech.com] Sent: Wednesday, April 16, 2014 10:48 AM To: MORTON, ALFRED C (AL) Cc: 'Barry Constantine'; bmwg@ietf.org Subject: RE: [bmwg] CloudEthernet Forum Hi Al, I represent Veryx, a Test and Measurement solution provider focusing on net= working and communications industry. We are a member of CEF and would be keen to track and support bmwg's initia= tives. Regards, Bhuvan From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Tuesday, April 15, 2014 12:09 AM To: Barry Constantine; bmwg@ietf.org Subject: Re: [bmwg] CloudEthernet Forum If there's someone who has exposure (and the answers), plus something the bmwg participants can learn and possibly influence our future activities, I think it would be appropriate to discuss here. Al bmwg co-chair From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine Sent: Monday, April 14, 2014 1:42 PM To: bmwg@ietf.org Subject: [bmwg] CloudEthernet Forum Hello Folks Looking to see if anyone has any exposure to the newly forming CloudEtherne= t Forum and how it may relate to other activities being pursued by IETF. Al, If you prefer this be an off list discussion, please indicate that so other= s may contact me off list. Thank you, Barry Constantine --_000_2845723087023D4CB5114223779FA9C8017944A670njfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good to meet you Bhuvan, and wel= come to BMWG.

 

Yo= u can see the proceedings from our March '14 session here:

https://datatracker.ietf.org/meeting/89/materials.html#ops

and lots of other background info is here:

https://dat= atracker.ietf.org/wg/bmwg/

 <= /span>

Also, allow me to introduce you to co-chair Sarah Banks.

 

regards,=

Al

bmwg co-chair

 

= From: Bhuvan (Veryx Technologies) [mailto:bhuvaneswaran.vengainathan@ver= yxtech.com]
Sent: Wednesday, April 16, 2014 10:48 AM
To: MORTON, ALFRED C (AL)
Cc: 'Barry Constantine'; bmwg@ietf.orgSubject: RE: [bmwg] CloudEthernet Forum

 

Hi Al,

<= span style=3D'color:#002060'> 

I represent Veryx, a Test and= Measurement solution provider focusing on networking and communications in= dustry.

We are a member of CEF and would be keen to track and su= pport bmwg’s initiatives.

<= span lang=3DEN-IN style=3D'color:#1F497D'> 

=

Regards,

Bhuvan<= /span>

&nb= sp;

From: bmwg [mailto:bmwg-bounces@ietf.org] On Beha= lf Of MORTON, ALFRED C (AL)
Sent: Tuesday, April 15, 2014 12:= 09 AM
To: Barry Constantine; bmw= g@ietf.org
Subject: Re: [bmwg] CloudEthernet Forum=

 

If = there's someone who has exposure (and the answers),

influence our future activities, I think it would be appropri= ate

to discuss here.

 

Al

bmwg co-chair

 

<= p class=3DMsoNormal>From: bmwg [mail= to:bmwg-bounces@ietf.org] On Behalf Of Barry Constantine
S= ent: Monday, April 14, 2014 1:42 PM
To: bmwg@ietf.org
Subject: [bmwg] CloudEthernet Forum=

 

Hello Folks

&= nbsp;

Looking to see if anyone has any exposu= re to the newly forming CloudEthernet Forum and how it may relate to other = activities being pursued by IETF.

&= nbsp;

Al,

=  

If you prefer this be an off list= discussion, please indicate that so others may contact me off list.

 

Than= k you,

Barry Constantine

<= /div>
= --_000_2845723087023D4CB5114223779FA9C8017944A670njfpsrvexg8re_-- From nobody Fri Apr 18 09:39:05 2014 Return-Path: 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 669EB1A03F7 for ; Fri, 18 Apr 2014 09:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 ko9KETX68gOa for ; Fri, 18 Apr 2014 09:38:59 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id B72BE1A01CD for ; Fri, 18 Apr 2014 09:38:59 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 9E172554B26; Fri, 18 Apr 2014 12:39:06 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 828ADF0380; Fri, 18 Apr 2014 12:38:55 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 18 Apr 2014 12:38:55 -0400 From: "MORTON, ALFRED C (AL)" To: "Lucien Avramov (lavramov)" , "bmwg@ietf.org" Date: Fri, 18 Apr 2014 12:36:35 -0400 Thread-Topic: [bmwg] New Charter Paragraphs Thread-Index: Ac9Xrgl3jjqsziZsSvGGqMspxyCgEgDdlOyO Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD46@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8017910D8A2@njfpsrvexg8.research.att.com>, <534B85FD.8050102@cisco.com> In-Reply-To: <534B85FD.8050102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/OAG7IN76ql2X4nDDuhHdaQflaZQ Subject: Re: [bmwg] New Charter Paragraphs X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:39:04 -0000 How about this combined version? Data Center Benchmarking: This work will define additional terms, benchmarks, and methods=20 applicable to data center performance evaluations. This includes data cente= r=20 specific congestion scenarios, switch buffer analysis, microburst, head of line blocking, while also using a wide mix of traffic=20 conditions. Some aspects from BMWG's past work are not meaningful when test= ing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242=20 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). This work will update RFC 2544 and exchange periodic Liaisons with relevant SDOs, especially at WG Last Call. ________________________________________ From: Lucien Avramov (lavramov) [lavramov@cisco.com] Sent: Monday, April 14, 2014 2:53 AM To: MORTON, ALFRED C (AL); bmwg@ietf.org Subject: Re: [bmwg] New Charter Paragraphs Hello BMWG! Suggesting some edits for the DC portion of the charter to include the benchmarking we have been talking and presenting at IEFT for the last year with Jacob Rapp: Data Center: -Bridging Some key concepts from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority group= s (802.1Qaz); and congestion notification (802.1Qau). Since devices that implement these new congestion-management specifications should never drop frames, and since the metric of throughput distinguishes between non-zero and zero drop rates, no throughput measurement is possible using the existing methodology. The current emphasis is on the Priority Flow Control aspects of Data Center Bridging, and the work will include an investigation into whether TRILL RBridges require any specific treatment in the methodology. This work will update RFC 2544 and exchange periodic Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. -Benchmarking Data Center DUT: The purpose of this informational document is to establish definitions, discussion and measurement techniques specific to data center environments. It is also to introduce definition terminologies applicable to data center performance evaluations. With these established, a methodology and measurement techniques for network equipement in the data center are covered. This includes data center specific congestion scenarios, switch buffer analysis, microburst, head of line blocking, while also using a wide mix of traffic conditions. This complements the existing benchmarking RFCs by specifying data center centric benchmarking. Cheers, Lucien On 3/27/14, 12:53 PM, MORTON, ALFRED C (AL) wrote: > BMWG, > > As we close in on the re-charter text, we decided at our IETF-89 session > to keep Datacenter and VNF paragraphs separate. > > To that end, we already have a Datacenter-oriented paragraph in our chart= er, > but it needs editing -- please make suggestions! > > * Data Center Bridging Devices: > Some key concepts from BMWG's past work are not meaningful when test= ing > switches that implement new IEEE specifications in the area of data > center bridging. For example, throughput as defined in RFC 1242 cann= ot > be measured when testing devices that implement three new IEEE > specifications: priority-based flow control (802.1Qbb); priority gro= ups > (802.1Qaz); and congestion notification (802.1Qau). > Since devices that implement these new congestion-management > specifications should never drop frames, and since the metric of > throughput distinguishes between non-zero and zero drop rates, no > throughput measurement is possible using the existing methodology. > The current emphasis is on the Priority Flow Control aspects of > Data Center Bridging, and the work will include an investigation > into whether TRILL RBridges require any specific treatment in the > methodology. This work will update RFC 2544 and exchange periodic > Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. > > > Also, here's the (slightly modified) text for VNF activity: > > * VNF and related Infrastructure Benchmarking > > Benchmarking Methodologies have reliably characterized many physical devi= ces. > This work item extends and enhances the methods to virtual network functi= ons (VNF) > and their unique supporting infrastructure. First, the new task space wil= l be > considered to ensure that common issues are considered from the start. > Virtual routers, switches and platform capacity and performance character= istics > will follow, including comparisons between physical and virtual functions= . > > Finally, I'll leave it to the authors to say more, but I noticed a new dr= aft > on our tools page: > > http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-0= 0 > > take a look, is this something we should consider including on our ride? > > Comments by April 14th, please. > > regards, > Al/Sarah > bmwg co-chairs > > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg > From nobody Tue Apr 22 20:21:54 2014 Return-Path: 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 CCA271A0283; Tue, 22 Apr 2014 16:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 ayHaaSMEtwlQ; Tue, 22 Apr 2014 16:50:39 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3C1A02A8; Tue, 22 Apr 2014 16:50:39 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 22 Apr 2014 16:50:34 -0700 From: Terry Manderson To: "rtg-ads@tools.ietf.org" Date: Tue, 22 Apr 2014 16:50:31 -0700 Thread-Topic: RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: Ac9ehaXZyzfSm/bDRCa6qVIGjOtRLQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3481091431_52626586" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/s9bM4-L_m1lBVacdgjMu8GtN3k0 X-Mailman-Approved-At: Tue, 22 Apr 2014 20:21:49 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-bmwg-bgp-basic-convergence.all@tools.ietf.org" , "bmwg@ietf.org" Subject: [bmwg] RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 23:50:45 -0000 --B_3481091431_52626586 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-bmwg-bgp-basic-convergence-01 http://tools.ietf.org/id/draft-ietf-bmwg-bgp-basic-convergence-01.txt Reviewer: Terry Manderson Review Date: 18/04/2014 IETF LC End Date: N/A - WG requested Routing Area Directorate review Intended Status: Standards Track Summary:=20 I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is clearly written and for the most part easy to understand. The steps are enumerated, which is very helpful. I would have prefered to see the reference topology figures repeated closer to the test case where they are used, but this is a matter of style. Major Issues: No major issues found Minor Issues: Section 3 (figures 1-4): please define The Helper node (HLP) before its use. It is first defined in section 5.1.2 Section 4.5: Please clarify if the interface media types and throughput must all be exactly the same for all devices in all the test cases, or that the media types and throughput are to be the same for iterations of the test cases. I re-read that Para several times and could infer either situation. Section 4.10: Can you please highlight the impact on the tests for where routing processor redundancy cannot be disabled, or if unwilling to do that suggest that the impacts or assessment of impacts are out of scope of this draft. Section 5.: Point B. I assume you mean Hard Reset here. For understanding purposes you may like to consider adding the term in parenthesis. Section 5.1.1: Pont B introduces "peer x of Emulator". I find this wording terse, can you please clarify what this is as I couldn't see in the text of section 3. Point D: "peer-x" is used here. Is this the same term as point B? It appears as I read through the points, that Peer-X (possibly otherwise known as 'SOME_ASN-X) is the test case nomenclature representation of the emulator function. It may be worth stating that up front to be pragmatic and help the reader. Section 5.1.2: This section introduces a NTP time source to the test case, that isn't described in "Section 3. Test Topologies". While not a critical concern to someone implementing the topologies, it may help them by highlighting the necessity of NTP in section 3. Section 5.1.5 Is the omission of normative language in the points, specifically A,B, and C intentional? Section 5.5, Point B. The language here surrounding the time source is different than in earlier text, is that intentional? Nits: Section 1.1, Para 3: s/functional/functions/ Section 4.2, Para 1: s/or through neighbor/or through a neighbor/ Section 4.4, Para 3: s/a)default/a) default/ s/b)platform-specific/b) platform-specific/ s/c)values/c) values/ Section 4.6, Para 3: s/)is/) is/ Section 5.1.1, second last para: s/Stand Deviation/Standard Deviation/ Section 5.2.1,=20 Point C. "Tx1", do you simply mean "Tx" as described in Figure 1? Point C. s/(Tx1)Interface/(Tx1) Interface/ Point E. s/Trr2/Tr2/ Point F. "(Drr1)" Can you clarify this is the intended nomenclature for this egress interface on the DUT? Section 5.3, Point E s/route say/route, say/ - I'd expect the RFC editor may suggest using "e.g". Section 5.6, Point B(6) s/(e.g. route A)/(e.g. routeA)/ - "RouteA" appears to be the selected form from earlier parts of the draft. (same for other occurrences in the remainder of the Draft (eg S5.8 point N,Q, .) Section 5.8. point F. s/Autonomous System.s/Autonomous Systems/ Section 5.8. Point S. s/Node -1/Node-1/ Cheers Terry --B_3481091431_52626586 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFCrmTLzBZKlNvQDH6Zi7WPxBs68mMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE0MDQyMjIzNTAzMVowDQYJKoZIhvcNAQEBBQAEggEAniCZycMF gYIYqTZZxoNKFJ/QnpsPt82aAqqGr1f7uyqL9v5z9vND0KDXfOZzGOkYbUno5EFxBK1+gytE SJahQrf9ryOPShkx+phBIawMdMdmm4wlxS7ycIoOSYGKmEzbckQZgQzlOqXTm3opsAw8coRT P0+XCMyoOSB0F6hHpsEfXo5mtbsB4eIHQTzcX3fq5TncweuK7aW5DTP0/7DIYjzHNwuxOZr/ pv9MBvufLc/dSa8zXr/LDmIKymI3EsdiQXycwM6A/5NuH6tmRTCWHeP8wlMaxoiDNwCz0dpj f9oNGlFxaOK2pngaDeb1ZDxpZiEn4B57lFzKDaPU9TI8Rw== --B_3481091431_52626586-- From nobody Tue Apr 22 20:30:09 2014 Return-Path: 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 EE0591A000E; Tue, 22 Apr 2014 20:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 TkPIEmRz3Eme; Tue, 22 Apr 2014 20:30:04 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA91A0012; Tue, 22 Apr 2014 20:30:04 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id DE3A4120127; Tue, 22 Apr 2014 23:30:22 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 70427E0102; Tue, 22 Apr 2014 23:29:52 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 22 Apr 2014 23:29:58 -0400 From: "MORTON, ALFRED C (AL)" To: Terry Manderson , "rtg-ads@tools.ietf.org" Date: Tue, 22 Apr 2014 23:29:56 -0400 Thread-Topic: RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt Thread-Index: Ac9ehaXZyzfSm/bDRCa6qVIGjOtRLQAHfP9g Message-ID: <2845723087023D4CB5114223779FA9C8017944AE5A@njfpsrvexg8.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/zNuD1sWJzr48uPBEjndUAFoKZmE Cc: "rtg-dir@ietf.org" , "draft-ietf-bmwg-bgp-basic-convergence.all@tools.ietf.org" , "bmwg@ietf.org" Subject: Re: [bmwg] RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 03:30:07 -0000 VGhhbmtzIFRlcnJ5LiBZb3VyIHBvc3RzIHRvIHRoZSBsaXN0IHdpbGwgbm8gbG9uZ2VyIGJlIG1v ZGVyYXRlZC4NCg0KVGhpcyBjb25jbHVkZXMgdGhlIFdHTEMuICBUaGUgYXV0aG9ycyBoYXZlIG1h bnkgY29tbWVudHMgdG8gYWRkcmVzcywNCmluY2x1ZGluZyB0aGUgbGlzdCBiZWxvdy4NCg0KQSBy ZXZpc2VkIGRyYWZ0IGlzIHJlcXVlc3RlZCwgYW5kIHdlJ2xsIHByb2NlZWQgZnJvbSB0aGVyZS4N Cg0KQWwNCmJtd2cgY28tY2hhaXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBibXdnIFttYWlsdG86Ym13Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVy cnkgTWFuZGVyc29uDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDc6NTEgUE0NCj4g VG86IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtYm13Zy1iZ3AtYmFzaWMtDQo+IGNvbnZlcmdlbmNlLmFsbEB0b29scy5pZXRmLm9yZzsg Ym13Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbYm13Z10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi1ibXdnLWJncC1iYXNpYy1jb252ZXJnZW5jZS0NCj4gMDEudHh0DQo+IA0KPiBIZWxsbywNCj4g DQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmll d2VyIGZvciB0aGlzIGRyYWZ0Lg0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+IGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMN Cj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHBy b3ZpZGUgYXNzaXN0YW5jZSB0bw0KPiB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLA0KPiBwbGVhc2Ugc2VlIOKAi2h0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gDQo+IEFs dGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJv dXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0 aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBDYWxsIGNvbW1lbnRzIHRoYXQg eW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCj4gZGlzY3Vz c2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0 Zi1ibXdnLWJncC1iYXNpYy1jb252ZXJnZW5jZS0wMQ0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1ibXdnLWJncC1iYXNpYy1jb252ZXJnZW5jZS0wMS50eHQNCj4gUmV2aWV3 ZXI6IFRlcnJ5IE1hbmRlcnNvbg0KPiBSZXZpZXcgRGF0ZTogMTgvMDQvMjAxNA0KPiBJRVRGIExD IEVuZCBEYXRlOiBOL0EgLSBXRyByZXF1ZXN0ZWQgUm91dGluZyBBcmVhIERpcmVjdG9yYXRlIHJl dmlldw0KPiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiANCj4gU3VtbWFyeToN Cj4gDQo+IEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhh dCBJIHRoaW5rIHNob3VsZCBiZQ0KPiByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+IA0K PiBDb21tZW50czoNCj4gDQo+IFRoaXMgZG9jdW1lbnQgaXMgY2xlYXJseSB3cml0dGVuIGFuZCBm b3IgdGhlIG1vc3QgcGFydCBlYXN5IHRvIHVuZGVyc3RhbmQuDQo+IFRoZSBzdGVwcyBhcmUNCj4g ZW51bWVyYXRlZCwgd2hpY2ggaXMgdmVyeSBoZWxwZnVsLiBJIHdvdWxkIGhhdmUgcHJlZmVyZWQg dG8gc2VlIHRoZQ0KPiByZWZlcmVuY2UgdG9wb2xvZ3kgZmlndXJlcyByZXBlYXRlZCBjbG9zZXIg dG8gdGhlIHRlc3QgY2FzZSB3aGVyZSB0aGV5IGFyZQ0KPiB1c2VkLCBidXQgdGhpcyBpcyBhIG1h dHRlciBvZiBzdHlsZS4NCj4gDQo+IA0KPiBNYWpvciBJc3N1ZXM6DQo+IA0KPiBObyBtYWpvciBp c3N1ZXMgZm91bmQNCj4gDQo+IE1pbm9yIElzc3VlczoNCj4gDQo+IFNlY3Rpb24gMyAoZmlndXJl cyAxLTQpOiBwbGVhc2UgZGVmaW5lIFRoZSBIZWxwZXIgbm9kZSAoSExQKSBiZWZvcmUgaXRzDQo+ IHVzZS4gSXQgaXMgZmlyc3QgZGVmaW5lZCBpbiBzZWN0aW9uIDUuMS4yDQo+IA0KPiBTZWN0aW9u IDQuNTogUGxlYXNlIGNsYXJpZnkgaWYgdGhlIGludGVyZmFjZSBtZWRpYSB0eXBlcyBhbmQgdGhy b3VnaHB1dA0KPiBtdXN0IGFsbCBiZSBleGFjdGx5IHRoZSBzYW1lIGZvciBhbGwgZGV2aWNlcyBp biBhbGwgdGhlIHRlc3QgY2FzZXMsIG9yDQo+IHRoYXQgdGhlIG1lZGlhIHR5cGVzIGFuZCB0aHJv dWdocHV0IGFyZSB0byBiZSB0aGUgc2FtZSBmb3IgaXRlcmF0aW9ucyBvZg0KPiB0aGUgdGVzdCBj YXNlcy4gSSByZS1yZWFkIHRoYXQgUGFyYSBzZXZlcmFsIHRpbWVzIGFuZCBjb3VsZCBpbmZlciBl aXRoZXINCj4gc2l0dWF0aW9uLg0KPiANCj4gU2VjdGlvbiA0LjEwOiBDYW4geW91IHBsZWFzZSBo aWdobGlnaHQgdGhlIGltcGFjdCBvbiB0aGUgdGVzdHMgZm9yIHdoZXJlDQo+IHJvdXRpbmcgcHJv Y2Vzc29yIHJlZHVuZGFuY3kgY2Fubm90IGJlIGRpc2FibGVkLCBvciBpZiB1bndpbGxpbmcgdG8g ZG8NCj4gdGhhdCBzdWdnZXN0IHRoYXQgdGhlIGltcGFjdHMgb3IgYXNzZXNzbWVudCBvZiBpbXBh Y3RzIGFyZSBvdXQgb2Ygc2NvcGUgb2YNCj4gdGhpcyBkcmFmdC4NCj4gDQo+IFNlY3Rpb24gNS46 IFBvaW50IEIuIEkgYXNzdW1lIHlvdSBtZWFuIEhhcmQgUmVzZXQgaGVyZS4gRm9yIHVuZGVyc3Rh bmRpbmcNCj4gcHVycG9zZXMgeW91IG1heSBsaWtlIHRvIGNvbnNpZGVyIGFkZGluZyB0aGUgdGVy bSBpbiBwYXJlbnRoZXNpcy4NCj4gDQo+IFNlY3Rpb24gNS4xLjE6IFBvbnQgQiBpbnRyb2R1Y2Vz ICJwZWVyIHggb2YgRW11bGF0b3IiLiBJIGZpbmQgdGhpcyB3b3JkaW5nDQo+IHRlcnNlLCBjYW4g eW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQgdGhpcyBpcyBhcyBJIGNvdWxkbid0IHNlZSBpbiB0aGUg dGV4dA0KPiBvZiBzZWN0aW9uIDMuDQo+IA0KPiAJUG9pbnQgRDogInBlZXIteCIgaXMgdXNlZCBo ZXJlLiBJcyB0aGlzIHRoZSBzYW1lIHRlcm0gYXMgcG9pbnQgQj8NCj4gDQo+IAlJdCBhcHBlYXJz IGFzIEkgcmVhZCB0aHJvdWdoIHRoZSBwb2ludHMsIHRoYXQgUGVlci1YIChwb3NzaWJseQ0KPiBv dGhlcndpc2UNCj4ga25vd24gYXMgJ1NPTUVfQVNOLVgpIGlzIHRoZSB0ZXN0IGNhc2Ugbm9tZW5j bGF0dXJlIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0KPiBlbXVsYXRvciBmdW5jdGlvbi4gSXQgbWF5 IGJlIHdvcnRoIHN0YXRpbmcgdGhhdCB1cCBmcm9udCB0byBiZSBwcmFnbWF0aWMNCj4gYW5kIGhl bHAgdGhlIHJlYWRlci4NCj4gDQo+IA0KPiBTZWN0aW9uIDUuMS4yOg0KPiANCj4gCVRoaXMgc2Vj dGlvbiBpbnRyb2R1Y2VzIGEgTlRQIHRpbWUgc291cmNlIHRvIHRoZSB0ZXN0IGNhc2UsIHRoYXQN Cj4gaXNuJ3QNCj4gZGVzY3JpYmVkIGluICJTZWN0aW9uIDMuIFRlc3QgVG9wb2xvZ2llcyIuIFdo aWxlIG5vdCBhIGNyaXRpY2FsIGNvbmNlcm4gdG8NCj4gc29tZW9uZSBpbXBsZW1lbnRpbmcgdGhl IHRvcG9sb2dpZXMsIGl0IG1heSBoZWxwIHRoZW0gYnkgaGlnaGxpZ2h0aW5nIHRoZQ0KPiBuZWNl c3NpdHkgb2YgTlRQIGluIHNlY3Rpb24gMy4NCj4gDQo+IFNlY3Rpb24gNS4xLjUNCj4gDQo+IAlJ cyB0aGUgb21pc3Npb24gb2Ygbm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoZSBwb2ludHMsIHNwZWNp ZmljYWxseQ0KPiBBLEIsDQo+IGFuZCBDIGludGVudGlvbmFsPw0KPiANCj4gU2VjdGlvbiA1LjUs IFBvaW50IEIuIFRoZSBsYW5ndWFnZSBoZXJlIHN1cnJvdW5kaW5nIHRoZSB0aW1lIHNvdXJjZSBp cw0KPiBkaWZmZXJlbnQgdGhhbiBpbiBlYXJsaWVyIHRleHQsIGlzIHRoYXQgaW50ZW50aW9uYWw/ DQo+IA0KPiBOaXRzOg0KPiANCj4gU2VjdGlvbiAxLjEsIFBhcmEgMzogcy9mdW5jdGlvbmFsL2Z1 bmN0aW9ucy8NCj4gU2VjdGlvbiA0LjIsIFBhcmEgMTogcy9vciB0aHJvdWdoIG5laWdoYm9yL29y IHRocm91Z2ggYSBuZWlnaGJvci8NCj4gU2VjdGlvbiA0LjQsIFBhcmEgMzogcy9hKWRlZmF1bHQv YSkgZGVmYXVsdC8NCj4gCQlzL2IpcGxhdGZvcm0tc3BlY2lmaWMvYikgcGxhdGZvcm0tc3BlY2lm aWMvDQo+IAkJcy9jKXZhbHVlcy9jKSB2YWx1ZXMvDQo+IFNlY3Rpb24gNC42LCBQYXJhIDM6IHMv KWlzLykgaXMvDQo+IA0KPiBTZWN0aW9uIDUuMS4xLCBzZWNvbmQgbGFzdCBwYXJhOiBzL1N0YW5k IERldmlhdGlvbi9TdGFuZGFyZCBEZXZpYXRpb24vDQo+IA0KPiBTZWN0aW9uIDUuMi4xLA0KPiAJ UG9pbnQgQy4gIlR4MSIsIGRvIHlvdSBzaW1wbHkgbWVhbiAiVHgiIGFzIGRlc2NyaWJlZCBpbiBG aWd1cmUgMT8NCj4gCVBvaW50IEMuIHMvKFR4MSlJbnRlcmZhY2UvKFR4MSkgSW50ZXJmYWNlLw0K PiAJUG9pbnQgRS4gcy9UcnIyL1RyMi8NCj4gCVBvaW50IEYuICIoRHJyMSkiIENhbiB5b3UgY2xh cmlmeSB0aGlzIGlzIHRoZSBpbnRlbmRlZCBub21lbmNsYXR1cmUNCj4gZm9yDQo+IHRoaXMgZWdy ZXNzIGludGVyZmFjZSBvbiB0aGUgRFVUPw0KPiANCj4gU2VjdGlvbiA1LjMsIFBvaW50IEUgcy9y b3V0ZSBzYXkvcm91dGUsIHNheS8gLSBJJ2QgZXhwZWN0IHRoZSBSRkMgZWRpdG9yDQo+IG1heSBz dWdnZXN0IHVzaW5nICJlLmciLg0KPiANCj4gU2VjdGlvbiA1LjYsIFBvaW50IEIoNikgcy8oZS5n LiByb3V0ZSBBKS8oZS5nLiByb3V0ZUEpLyAtICJSb3V0ZUEiIGFwcGVhcnMNCj4gdG8gYmUgdGhl IHNlbGVjdGVkIGZvcm0gZnJvbSBlYXJsaWVyIHBhcnRzIG9mIHRoZSBkcmFmdC4NCj4gCShzYW1l IGZvciBvdGhlciBvY2N1cnJlbmNlcyBpbiB0aGUgcmVtYWluZGVyIG9mIHRoZSBEcmFmdCAoZWcg UzUuOA0KPiBwb2ludA0KPiBOLFEsIC4pDQo+IA0KPiANCj4gU2VjdGlvbiA1LjguIHBvaW50IEYu IHMvQXV0b25vbW91cyBTeXN0ZW0ucy9BdXRvbm9tb3VzIFN5c3RlbXMvDQo+IFNlY3Rpb24gNS44 LiBQb2ludCBTLiBzL05vZGUgLTEvTm9kZS0xLw0KPiANCj4gDQo+IENoZWVycw0KPiBUZXJyeQ0K From nobody Tue Apr 22 23:30:58 2014 Return-Path: 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 D2DC91A0330 for ; Tue, 22 Apr 2014 23:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JDIoEwVa0apb for ; Tue, 22 Apr 2014 23:30:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3D1A008F for ; Tue, 22 Apr 2014 23:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6292; q=dns/txt; s=iport; t=1398234648; x=1399444248; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vCbTWP9XoyqzN0vPRm/8z/or0w8yAZ+Q4Qgc8RfYNRs=; b=ixGAPugQVA5bGBpcqkei6o/dYtuO8lt/DqIOZjQgFyNaj9Y50ULXZOSI bV2vAjY6RrmX0eMDkE22egB5HJuXGbO2g8z/P9JqBKVBE3rCjqvVLXuIv WUvyPCxzFWtA004LzA8AVmht4J8Rw7YmuN1aE3UyIKMFslLipLsJZRVaR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFADRdV1OrRDoH/2dsb2JhbABZgwZPvVmHOoEWFnSCJQEBAQQBAQE1NgoRCxEEAQEBCRYPCQMCAQIBFSgIBgEMBgIBAQWINw7PLReOX4Q5AQOJZY8QgTeRHoNRHQ X-IronPort-AV: E=Sophos;i="4.97,910,1389744000"; d="scan'208";a="110880423" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 23 Apr 2014 06:30:44 +0000 Received: from sjc-lavramov-8816.cisco.com (sjc-lavramov-8816.cisco.com [10.19.100.135]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3N6Ui0e018854; Wed, 23 Apr 2014 06:30:44 GMT Message-ID: <53575E93.3000103@cisco.com> Date: Tue, 22 Apr 2014 23:32:51 -0700 From: "Lucien Avramov (lavramov)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , "bmwg@ietf.org" References: <2845723087023D4CB5114223779FA9C8017910D8A2@njfpsrvexg8.research.att.com>, <534B85FD.8050102@cisco.com> <2845723087023D4CB5114223779FA9C80178E0CD46@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CD46@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/Q-R74A0GMYAlW4uFmky4jhmSb7o Subject: Re: [bmwg] New Charter Paragraphs X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:30:58 -0000 Hi Al, This looks good to me, I think we should not restrict the charter to only update 2544, I would extend this to : RFC1242, RFC2432, RFC2544, RFC2889 and RFC3918 as per our drafts for the data center benchmarking mention in the abstract sections: http://www.ietf.org/internet-drafts/draft-dcbench-def-01.txt http://www.ietf.org/id/draft-bmwg-dcbench-methodology-02.txt Cheers, Lucien On 4/18/14, 9:36 AM, MORTON, ALFRED C (AL) wrote: > How about this combined version? > > Data Center Benchmarking: > > This work will define additional terms, benchmarks, and methods > applicable to data center performance evaluations. This includes data center > specific congestion scenarios, switch buffer analysis, microburst, > head of line blocking, while also using a wide mix of traffic > conditions. Some aspects from BMWG's past work are not meaningful when testing > switches that implement new IEEE specifications in the area of data > center bridging. For example, throughput as defined in RFC 1242 > cannot be measured when testing devices that implement three new IEEE > specifications: priority-based flow control (802.1Qbb); priority groups > (802.1Qaz); and congestion notification (802.1Qau). > This work will update RFC 2544 and exchange periodic > Liaisons with relevant SDOs, especially at WG Last Call. > > > ________________________________________ > From: Lucien Avramov (lavramov) [lavramov@cisco.com] > Sent: Monday, April 14, 2014 2:53 AM > To: MORTON, ALFRED C (AL); bmwg@ietf.org > Subject: Re: [bmwg] New Charter Paragraphs > > Hello BMWG! > > Suggesting some edits for the DC portion of the charter to include the > benchmarking we have been talking and presenting at IEFT for the last > year with Jacob Rapp: > > Data Center: > > -Bridging > Some key concepts from BMWG's past work are not meaningful when testing > switches that implement new IEEE specifications in the area of data > center bridging. For example, throughput as defined in RFC 1242 > cannot be measured when testing devices that implement three new IEEE > specifications: priority-based flow control (802.1Qbb); priority groups > (802.1Qaz); and congestion notification (802.1Qau). > Since devices that implement these new congestion-management > specifications should never drop frames, and since the metric of > throughput distinguishes between non-zero and zero drop rates, no > throughput measurement is possible using the existing methodology. > The current emphasis is on the Priority Flow Control aspects of > Data Center Bridging, and the work will include an investigation > into whether TRILL RBridges require any specific treatment in the > methodology. This work will update RFC 2544 and exchange periodic > Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. > > -Benchmarking Data Center DUT: > The purpose of this informational document is to establish definitions, > discussion and measurement techniques specific to data center > environments. It is also to introduce definition terminologies > applicable to data center performance evaluations. With these > established, a methodology and measurement techniques for network > equipement in the data center are covered. This includes data center > specific congestion scenarios, switch buffer analysis, microburst, > head of line blocking, while also using a wide mix of traffic > conditions. This complements the existing benchmarking RFCs by > specifying data center centric benchmarking. > > Cheers, > Lucien > > On 3/27/14, 12:53 PM, MORTON, ALFRED C (AL) wrote: >> BMWG, >> >> As we close in on the re-charter text, we decided at our IETF-89 session >> to keep Datacenter and VNF paragraphs separate. >> >> To that end, we already have a Datacenter-oriented paragraph in our charter, >> but it needs editing -- please make suggestions! >> >> * Data Center Bridging Devices: >> Some key concepts from BMWG's past work are not meaningful when testing >> switches that implement new IEEE specifications in the area of data >> center bridging. For example, throughput as defined in RFC 1242 cannot >> be measured when testing devices that implement three new IEEE >> specifications: priority-based flow control (802.1Qbb); priority groups >> (802.1Qaz); and congestion notification (802.1Qau). >> Since devices that implement these new congestion-management >> specifications should never drop frames, and since the metric of >> throughput distinguishes between non-zero and zero drop rates, no >> throughput measurement is possible using the existing methodology. >> The current emphasis is on the Priority Flow Control aspects of >> Data Center Bridging, and the work will include an investigation >> into whether TRILL RBridges require any specific treatment in the >> methodology. This work will update RFC 2544 and exchange periodic >> Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. >> >> >> Also, here's the (slightly modified) text for VNF activity: >> >> * VNF and related Infrastructure Benchmarking >> >> Benchmarking Methodologies have reliably characterized many physical devices. >> This work item extends and enhances the methods to virtual network functions (VNF) >> and their unique supporting infrastructure. First, the new task space will be >> considered to ensure that common issues are considered from the start. >> Virtual routers, switches and platform capacity and performance characteristics >> will follow, including comparisons between physical and virtual functions. >> >> Finally, I'll leave it to the authors to say more, but I noticed a new draft >> on our tools page: >> >> http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-00 >> >> take a look, is this something we should consider including on our ride? >> >> Comments by April 14th, please. >> >> regards, >> Al/Sarah >> bmwg co-chairs >> >> _______________________________________________ >> bmwg mailing list >> bmwg@ietf.org >> https://www.ietf.org/mailman/listinfo/bmwg >> From nobody Thu Apr 24 10:20:57 2014 Return-Path: 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 EB5BB1A02CC for ; Thu, 24 Apr 2014 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 LqxaUbo56b9l for ; Thu, 24 Apr 2014 10:20:51 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id EF7DF1A02B5 for ; Thu, 24 Apr 2014 10:20:50 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id A56B4120729 for ; Thu, 24 Apr 2014 13:21:13 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id 946A1E022F for ; Thu, 24 Apr 2014 13:20:44 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 24 Apr 2014 13:20:44 -0400 From: "MORTON, ALFRED C (AL)" To: "bmwg@ietf.org" Date: Thu, 24 Apr 2014 13:20:40 -0400 Thread-Topic: Re-Charter Text for review Thread-Index: Ac9f4Gy8wxiQ2jJ5T5CMVHKqDo6rRQ== Message-ID: <2845723087023D4CB5114223779FA9C8017944B077@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/0j9rl7QTJAkjtLqxm7PMC4cAfJ0 Subject: [bmwg] Re-Charter Text for review X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:20:53 -0000 BMWG,=20 Over the last year, we've developed this set of paragraphs for specific work items one at a time. Now it's time for one last look (by May 2) and then we declare consensus and move to the next step (unless the=20 wheels come-off). Reply with your comments on the text below. Al and Sarah, bmwg co-chairs -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g., network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminology will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the detailed description of the task, as listed below. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the capabilities and operation of inter-networking technology implementations. The BMWG will communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT. In addition to its current work items, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: Traffic Management: Develop the methods to characterize the capacity=20 of traffic management features in network devices, such as classification,= =20 policing, shaping, and active queue management. Existing terminology=20 will be used where appropriate. Configured operation will be verified=20 as a part of the methodology. The goal is a methodology to assess the=20 maximum forwarding performance that a network device can sustain without=20 dropping or impairing packets, or compromising the accuracy of multiple=20 instances of traffic management functions. This is the benchmark for=20 comparison between devices. Another goal is to devise methods that=20 utilize flows with congestion-aware transport as part of the traffic=20 load and still produce repeatable results in the isolated test environment. IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents=20 several networking challenges, as described in RFC 6583. Indexes to=20 describe the performance of network devices, such as the number of=20 reachable devices on a sub-network, are useful benchmarks to the=20 operations community. The working group will develop the necessary=20 terminology and methodologies to measure such benchmarks. In-Service Software Upgrade: Develop new methods and benchmarks to=20 characterize the upgrade of network devices while in-service,=20 considering both data and control plane operations and impacts.=20 These devices are generally expected to maintain control plane session=20 integrity, including routing connections. Quantification of Upgrade=20 impact will include packet loss measurement, and other forms of recovery=20 behavior will be noted accordingly. The work will produce a definition=20 of ISSU, which will help refine the scope.=A0Liaisons will be established=20 as needed. Data Center Benchmarking: This work will define additional terms,=20 benchmarks, and methods applicable to data center performance evaluations.= =20 This includes data center specific congestion scenarios, switch buffer=20 analysis, microburst, head of line blocking, while also using a wide mix=20 of traffic conditions. Some aspects from BMWG's past work are not=20 meaningful when testing switches that implement new IEEE specifications=20 in the area of data center bridging. For example, throughput as defined=20 in RFC 1242 cannot be measured when testing devices that implement three=20 new IEEE specifications: priority-based flow control (802.1Qbb);=20 priority groups (802.1Qaz); and congestion notification (802.1Qau). This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs),=20 and exchange Liaisons with relevant SDOs, especially at WG Last Call. VNF and related Infrastructure Benchmarking: Benchmarking Methodologies=20 have reliably characterized many physical devices. This work item extends=20 and enhances the methods to virtual network functions (VNF) and their=20 unique supporting infrastructure. First, the new task space will be=20 considered to ensure that common issues are recognized from the start.=20 Benchmarks for platform capacity and performance characteristics of=20 virtual routers, switches, and related components will follow, including=20 comparisons between physical and virtual network functions. From nobody Sat Apr 26 06:19:29 2014 Return-Path: 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 9E5C81A0415 for ; Fri, 25 Apr 2014 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 mdSMDX5GqQtg for ; Fri, 25 Apr 2014 16:11:02 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) by ietfa.amsl.com (Postfix) with ESMTP id AD2121A0673 for ; Fri, 25 Apr 2014 16:11:02 -0700 (PDT) Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id BB6DA139 for ; Fri, 25 Apr 2014 23:10:55 +0000 (UTC) Received: from G9W3617.americas.hpqcorp.net (16.216.186.52) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 25 Apr 2014 23:08:45 +0000 Received: from G9W0735.americas.hpqcorp.net ([169.254.11.138]) by G9W3617.americas.hpqcorp.net ([16.216.186.52]) with mapi id 14.03.0169.001; Fri, 25 Apr 2014 23:08:45 +0000 From: "Tassinari, Mark A" To: "bmwg@ietf.org" Thread-Topic: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance Thread-Index: Ac9ecGt5dB0hc1KSRza1QkEtI5opNw== Date: Fri, 25 Apr 2014 23:08:44 +0000 Deferred-Delivery: Fri, 25 Apr 2014 23:08:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.26] Content-Type: multipart/alternative; boundary="_000_B5838747F54175449562AA808237BE1446D3ABC6G9W0735americas_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/U5MYtm_FDvv5dmq0OAbIxko9_UQ X-Mailman-Approved-At: Sat, 26 Apr 2014 06:19:27 -0700 Subject: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 23:11:09 -0000 --_000_B5838747F54175449562AA808237BE1446D3ABC6G9W0735americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Bhuvan, Standardizing on a set of controller performance tests is a great idea and = the OpenFlow SDN Controller Performance draft is a good start. I'd like to= submit some comments and questions. - The Test Setup section is unclear about where virtualization is = permitted but this can have a dramatic effect on the results. I believe th= e benchmark test should require the controller and any virtual switches to = be on separate servers. - I'm curious to know why the number of switches in the tests are = not defined - not even to require more than one. There is way to know if t= he tests were executed the tests under the same conditions which makes comp= arison much less meaningful. - What is the numerator (OFRi) in the Flow setup rate formula defi= ned in Section 6.1.1.1.4? Is it the sum of all packet_out and flow mod mes= sages sent by the controller? - The test does not specify whether throughput results are verifie= d to be lossless (every packet_in results in a packet_out). Since TCP is t= he specified connection it may not matter but I thought I'd toss it out for= discussion. - The Reactive Mode Flow setup in section 6.1.1.2.2 is a little un= clear. If the objective is to have the 10% of all "specified" switches tha= t are connected send Packet_In messages I'd rephrase the second sentence t= o state "Load controller with Packet-In messages from all connected control= lers for a specified interval." Regards, Mark --_000_B5838747F54175449562AA808237BE1446D3ABC6G9W0735americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Bhuvan,

 

Standardizing on a set of controller performance tes= ts is a great idea and the OpenFlow SDN Controller Performance draft is a g= ood start.  I’d like to submit some comments and questions. = ;

 

-     &= nbsp;    The Test Setup section is unclear about where virtu= alization is permitted but this can have a dramatic effect on the results.&= nbsp; I believe the benchmark test should require the controller and any vi= rtual switches to be on separate servers. 

-     &= nbsp;    I’m curious to know why the number of switche= s in the tests are not defined – not even to require more than one.&n= bsp; There is way to know if the tests were executed the tests under the sa= me conditions which makes comparison much less meaningful.

-     &= nbsp;    What is the numerator (OFRi) in the Flow setup rate= formula defined in Section 6.1.1.1.4?  Is it the sum of all packet_ou= t and flow mod messages sent by the controller?

-     &= nbsp;    The test does not specify whether throughput result= s are verified to be lossless (every packet_in results in a packet_out).&nb= sp; Since TCP is the specified connection it may not matter but I thought I= ’d toss it out for discussion. 

-     &= nbsp;    The Reactive Mode Flow setup in section 6.1.1.2.2 i= s a little unclear.  If the objective is to have the 10% of all “= ;specified” switches that are connected send Packet_In messages IR= 17;d rephrase  the second sentence to state “Load controller with Packet-In messages from all connected controllers for a specified int= erval.” 

 

Regards,

 

Mark

 

 

--_000_B5838747F54175449562AA808237BE1446D3ABC6G9W0735americas_-- From nobody Mon Apr 28 06:07:51 2014 Return-Path: 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 7D0BB1A078F for ; Mon, 28 Apr 2014 06:07:47 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 05L9fYwgprIy for ; Mon, 28 Apr 2014 06:07:45 -0700 (PDT) Received: from mx0a-00158d01.pphosted.com (mx0a-00158d01.pphosted.com [208.84.65.189]) by ietfa.amsl.com (Postfix) with ESMTP id 07B791A09E8 for ; Mon, 28 Apr 2014 06:07:44 -0700 (PDT) Received: from pps.filterd (m0043267.ppops.net [127.0.0.1]) by mx0a-00158d01.pphosted.com (8.14.5/8.14.5) with SMTP id s3SD5g3G028941; Mon, 28 Apr 2014 06:07:42 -0700 Received: from mx2.jdsu.com ([157.234.211.51]) by mx0a-00158d01.pphosted.com with ESMTP id 1khkterpnc-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Apr 2014 06:07:41 -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.174.1; Mon, 28 Apr 2014 06:07:38 -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.0174.001; Mon, 28 Apr 2014 06:07:41 -0700 From: Barry Constantine To: "MORTON, ALFRED C (AL)" , "bmwg@ietf.org" Thread-Topic: Re-Charter Text for review Thread-Index: Ac9f4Gy8wxiQ2jJ5T5CMVHKqDo6rRQDAj9Ag Date: Mon, 28 Apr 2014 13:07:40 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8017944B077@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017944B077@njfpsrvexg8.research.att.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-28_01:2014-04-28,2014-04-27,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-1404280223 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/0UghllA22rLoL7BCfP54m4_RgLo Subject: Re: [bmwg] Re-Charter Text for review X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:07:47 -0000 Hi Al, I think the charter is well written and with topics that are very relevant. Thank you, Barry Constantine JDSU Network and Service Enablement Principal Member Technical Staff 301-325-7069 -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Thursday, April 24, 2014 1:21 PM To: bmwg@ietf.org Subject: [bmwg] Re-Charter Text for review BMWG,=20 Over the last year, we've developed this set of paragraphs for specific wor= k items one at a time. Now it's time for one last look (by May 2) and then= we declare consensus and move to the next step (unless the wheels come-off= ). Reply with your comments on the text below. Al and Sarah, bmwg co-chairs -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce = a series of recommendations concerning the key performance characteristics = of internetworking technologies, or benchmarks for network devices, systems= , and services. Taking a view of networking divided into planes, the scope = of work includes benchmarks for the management, control, and forwarding pla= nes. Each recommendation will describe the class of equipment, system, or servic= e being addressed; discuss the performance characteristics that are pertine= nt to that class; clearly identify a set of metrics that aid in the descrip= tion of those characteristics; specify the methodologies required to collec= t said metrics; and lastly, present the requirements for the common, unambi= guous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the commun= ity of users (e.g., network operators and testing organizations) and from t= hose affected by the benchmarks when they are published (networking and tes= t equipment manufacturers). When possible, the benchmarks and other termino= logy will be developed jointly with organizations that are willing to share= their expertise. Joint review requirements for a specific work area will b= e included in the detailed description of the task, as listed below. To better distinguish the BMWG from other measurement initiatives in the IE= TF, the scope of the BMWG is limited to the characterization of implementat= ions of various internetworking technologies using controlled stimuli in a = laboratory environment. Said differently, the BMWG does not attempt to prod= uce benchmarks for live, operational networks. Moreover, the benchmarks pro= duced by this WG shall strive to be vendor independent or otherwise have un= iversal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to = deployment, a specific non-goal of the Working Group is to define acceptanc= e criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancem= ent of measurements designed to provide insight on the capabilities and ope= ration of inter-networking technology implementations. The BMWG will communicate with the operations community through organizatio= ns such as NANOG, RIPE, and APRICOT. In addition to its current work items, the BMWG is explicitly tasked to dev= elop benchmarks and methodologies for the following technologies: Traffic Management: Develop the methods to characterize the capacity of tra= ffic management features in network devices, such as classification, polici= ng, shaping, and active queue management. Existing terminology will be used= where appropriate. Configured operation will be verified as a part of the = methodology. The goal is a methodology to assess the maximum forwarding per= formance that a network device can sustain without dropping or impairing pa= ckets, or compromising the accuracy of multiple instances of traffic manage= ment functions. This is the benchmark for comparison between devices. Anoth= er goal is to devise methods that utilize flows with congestion-aware trans= port as part of the traffic load and still produce repeatable results in th= e isolated test environment. IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents sever= al networking challenges, as described in RFC 6583. Indexes to describe the= performance of network devices, such as the number of reachable devices on= a sub-network, are useful benchmarks to the operations community. The work= ing group will develop the necessary terminology and methodologies to measu= re such benchmarks. In-Service Software Upgrade: Develop new methods and benchmarks to characte= rize the upgrade of network devices while in-service, considering both data= and control plane operations and impacts.=20 These devices are generally expected to maintain control plane session inte= grity, including routing connections. Quantification of Upgrade impact will= include packet loss measurement, and other forms of recovery behavior will= be noted accordingly. The work will produce a definition of ISSU, which wi= ll help refine the scope.=A0Liaisons will be established as needed. Data Center Benchmarking: This work will define additional terms, benchmark= s, and methods applicable to data center performance evaluations.=20 This includes data center specific congestion scenarios, switch buffer anal= ysis, microburst, head of line blocking, while also using a wide mix of tra= ffic conditions. Some aspects from BMWG's past work are not meaningful when= testing switches that implement new IEEE specifications in the area of dat= a center bridging. For example, throughput as defined in RFC 1242 cannot be= measured when testing devices that implement three new IEEE specifications= : priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and c= ongestion notification (802.1Qau). This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs), and e= xchange Liaisons with relevant SDOs, especially at WG Last Call. VNF and related Infrastructure Benchmarking: Benchmarking Methodologies hav= e reliably characterized many physical devices. This work item extends and = enhances the methods to virtual network functions (VNF) and their unique su= pporting infrastructure. First, the new task space will be considered to en= sure that common issues are recognized from the start.=20 Benchmarks for platform capacity and performance characteristics of virtual= routers, switches, and related components will follow, including compariso= ns between physical and virtual network functions. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg From nobody Mon Apr 28 06:30:46 2014 Return-Path: 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 5882A1A09E6 for ; Mon, 28 Apr 2014 06:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 8mA49tBnuM3O for ; Mon, 28 Apr 2014 06:30:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CEBF41A0795 for ; Mon, 28 Apr 2014 06:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7125; q=dns/txt; s=iport; t=1398691842; x=1399901442; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=nUc6C5uS8EHzl/4xQpOt1CklEounQQNSYiloYkb9ow4=; b=Apb8nPZLP1xLvxr0ATbNXhYY6JCij2ZDOf1x4uE3p9Lb9zzFq5MBlpjl arVrnJIMWZS5Is5nsCvFD5/RYz3TkX3rq0JTSi7dpDPCjfkoA84HZwAvR tGMzw7bmcJVSch3OucqY2eD22ksotRiDG/4HAcgWONUkJF9BITazVilrB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFALJXXlOtJA2H/2dsb2JhbABPBwODBk9XvS6HOYEVFnSCJQEBAQQBAQE3MQMXBgEIEQQBAR8JLgsUCQoEARIUiC0NyXMTBI19BCUIGx0LhCgEmQySXoMxgWlC X-IronPort-AV: E=Sophos;i="4.97,944,1389744000"; d="scan'208";a="320908977" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 28 Apr 2014 13:30:36 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3SDUZX7002968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 13:30:35 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 08:30:35 -0500 From: "Fernando Calabria (fcalabri)" To: Barry Constantine , "MORTON, ALFRED C (AL)" , "bmwg@ietf.org" Thread-Topic: [bmwg] Re-Charter Text for review Thread-Index: AQHPYuYI+sFq4e5XzUOeDhY19DyGBg== Date: Mon, 28 Apr 2014 13:30:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [64.102.130.150] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C170C8FFD1D144BBA7F5BDCBF1146D8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/VMkdRAWFMJ_wOordB7uCIaPZKdQ Subject: Re: [bmwg] Re-Charter Text for review X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:30:45 -0000 +1=20 On 4/28/14, 9:07 AM, "Barry Constantine" wrote: >Hi Al, > >I think the charter is well written and with topics that are very >relevant. > >Thank you, >Barry Constantine > >JDSU Network and Service Enablement >Principal Member Technical Staff >301-325-7069 > >-----Original Message----- >From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C >(AL) >Sent: Thursday, April 24, 2014 1:21 PM >To: bmwg@ietf.org >Subject: [bmwg] Re-Charter Text for review > >BMWG,=20 > >Over the last year, we've developed this set of paragraphs for specific >work items one at a time. Now it's time for one last look (by May 2) and >then we declare consensus and move to the next step (unless the wheels >come-off). Reply with your comments on the text below. > >Al and Sarah, >bmwg co-chairs > >-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > >Description of Working Group: > > >The Benchmarking Methodology Working Group (BMWG) will continue to >produce a series of recommendations concerning the key performance >characteristics of internetworking technologies, or benchmarks for >network devices, systems, and services. Taking a view of networking >divided into planes, the scope of work includes benchmarks for the >management, control, and forwarding planes. > >Each recommendation will describe the class of equipment, system, or >service being addressed; discuss the performance characteristics that are >pertinent to that class; clearly identify a set of metrics that aid in >the description of those characteristics; specify the methodologies >required to collect said metrics; and lastly, present the requirements >for the common, unambiguous reporting of benchmarking results. > >The set of relevant benchmarks will be developed with input from the >community of users (e.g., network operators and testing organizations) >and from those affected by the benchmarks when they are published >(networking and test equipment manufacturers). When possible, the >benchmarks and other terminology will be developed jointly with >organizations that are willing to share their expertise. Joint review >requirements for a specific work area will be included in the detailed >description of the task, as listed below. > >To better distinguish the BMWG from other measurement initiatives in the >IETF, the scope of the BMWG is limited to the characterization of >implementations of various internetworking technologies using controlled >stimuli in a laboratory environment. Said differently, the BMWG does not >attempt to produce benchmarks for live, operational networks. Moreover, >the benchmarks produced by this WG shall strive to be vendor independent >or otherwise have universal applicability to a given technology class. > >Because the demands of a particular technology may vary from deployment >to deployment, a specific non-goal of the Working Group is to define >acceptance criteria or performance requirements. > >An ongoing task is to provide a forum for discussion regarding the >advancement of measurements designed to provide insight on the >capabilities and operation of inter-networking technology implementations. > >The BMWG will communicate with the operations community through >organizations such as NANOG, RIPE, and APRICOT. > >In addition to its current work items, the BMWG is explicitly tasked to >develop benchmarks and methodologies for the following technologies: > >Traffic Management: Develop the methods to characterize the capacity of >traffic management features in network devices, such as classification, >policing, shaping, and active queue management. Existing terminology will >be used where appropriate. Configured operation will be verified as a >part of the methodology. The goal is a methodology to assess the maximum >forwarding performance that a network device can sustain without dropping >or impairing packets, or compromising the accuracy of multiple instances >of traffic management functions. This is the benchmark for comparison >between devices. Another goal is to devise methods that utilize flows >with congestion-aware transport as part of the traffic load and still >produce repeatable results in the isolated test environment. > >IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents >several networking challenges, as described in RFC 6583. Indexes to >describe the performance of network devices, such as the number of >reachable devices on a sub-network, are useful benchmarks to the >operations community. The working group will develop the necessary >terminology and methodologies to measure such benchmarks. > >In-Service Software Upgrade: Develop new methods and benchmarks to >characterize the upgrade of network devices while in-service, considering >both data and control plane operations and impacts. >These devices are generally expected to maintain control plane session >integrity, including routing connections. Quantification of Upgrade >impact will include packet loss measurement, and other forms of recovery >behavior will be noted accordingly. The work will produce a definition of >ISSU, which will help refine the scope. Liaisons will be established as >needed. > >Data Center Benchmarking: This work will define additional terms, >benchmarks, and methods applicable to data center performance >evaluations.=20 >This includes data center specific congestion scenarios, switch buffer >analysis, microburst, head of line blocking, while also using a wide mix >of traffic conditions. Some aspects from BMWG's past work are not >meaningful when testing switches that implement new IEEE specifications >in the area of data center bridging. For example, throughput as defined >in RFC 1242 cannot be measured when testing devices that implement three >new IEEE specifications: priority-based flow control (802.1Qbb); priority >groups (802.1Qaz); and congestion notification (802.1Qau). >This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs), and >exchange Liaisons with relevant SDOs, especially at WG Last Call. > >VNF and related Infrastructure Benchmarking: Benchmarking Methodologies >have reliably characterized many physical devices. This work item extends >and enhances the methods to virtual network functions (VNF) and their >unique supporting infrastructure. First, the new task space will be >considered to ensure that common issues are recognized from the start. >Benchmarks for platform capacity and performance characteristics of >virtual routers, switches, and related components will follow, including >comparisons between physical and virtual network functions. > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From nobody Mon Apr 28 15:32:24 2014 Return-Path: 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 133DF1A8861 for ; Mon, 28 Apr 2014 15:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 B22j2eS-b9kb for ; Mon, 28 Apr 2014 15:32:17 -0700 (PDT) Received: from mail.veryxtech.com (mail.veryxtech.com [203.196.171.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2661A885D for ; Mon, 28 Apr 2014 15:32:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.veryxtech.com (Postfix) with ESMTP id 7F9F13740DE; Tue, 29 Apr 2014 04:02:12 +0530 (IST) X-Virus-Scanned: amavisd-new at veryxtech.com Received: from mail.veryxtech.com ([127.0.0.1]) by localhost (mail.veryxtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd3rTX272e8t; Tue, 29 Apr 2014 04:02:07 +0530 (IST) Received: from LT015PC (unknown [12.216.212.50]) by mail.veryxtech.com (Postfix) with ESMTPSA id B91E93740DC; Tue, 29 Apr 2014 04:02:05 +0530 (IST) From: "Bhuvan \(Veryx Technologies\)" To: "Tassinari, Mark A" , References: In-Reply-To: Date: Tue, 29 Apr 2014 04:01:59 +0530 Message-ID: <007301cf6331$afc89820$0f59c860$@veryxtech.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0074_01CF635F.C9834520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOjkglqC341B3UMB1mDwB9FyJDuZqpPKUA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/VlKlYClxM64kUbgqn9_bcuqdSGA Subject: Re: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 22:32:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01CF635F.C9834520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0075_01CF635F.C9834520" ------=_NextPart_001_0075_01CF635F.C9834520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, Thanks for reviewing the draft (initial sections) and providing valuable comments. Please find my responses inline with tag [Bhuvan]. If needed, we can discuss my responses. Also, I look forward your comments on other sections of the draft (if any). Best regards, Description: Description: Description: Description: Description: Description: Description: Description: Description: Veryx-Logo for Webinar Bhuvan | Cloud and SDN Solutions Phone: +91 44 4567 2222 x242 Mobile: +91 988 428 6693 www.veryxtech.com Description: Description: Description: Description: Description: Description: Description: Description: Signature From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Tassinari, Mark A Sent: Saturday, April 26, 2014 4:39 AM To: bmwg@ietf.org Subject: [bmwg] Benchmarking Methodology for OpenFlow SDN Controller Performance Hello Bhuvan, Standardizing on a set of controller performance tests is a great idea and the OpenFlow SDN Controller Performance draft is a good start. I'd like to submit some comments and questions. - The Test Setup section is unclear about where virtualization is permitted but this can have a dramatic effect on the results. I believe the benchmark test should require the controller and any virtual switches to be on separate servers. [Bhuvan] I do agree with your comment. The controller and the emulated virtual switches need to be running in separate servers. We will explicitly capture this point as part of test setup in our next version. - I'm curious to know why the number of switches in the tests are not defined - not even to require more than one. There is way to know if the tests were executed the tests under the same conditions which makes comparison much less meaningful. [Bhuvan] I agree with you that the number switches should be more than one (suggestion could be - max. switches supported by the controller). We can add a note to specify this in the draft. But the reasons behind not defining the exact value for number of switches are: 1) The number of switches supported may vary from controller to controller 2) Some controllers may perform better for smaller number of switches and some for larger number of switches Hence we left it to the vendors to specify this parameter based on their implementation. Also we recommended specifying the results against the number of switches emulated as part of "Reporting Format" section to enable comparison. - What is the numerator (OFRi) in the Flow setup rate formula defined in Section 6.1.1.1.4? Is it the sum of all packet_out and flow mod messages sent by the controller? [Bhuvan] No. We recommend taking into account either sum of all 'PACKET_OUT' (or) 'FLOW_MOD' messages. We can also provide description for OFRi in Terminology section. Please let me know if you have different thoughts on this. We could discuss them. - The test does not specify whether throughput results are verified to be lossless (every packet_in results in a packet_out). Since TCP is the specified connection it may not matter but I thought I'd toss it out for discussion. [Bhuvan] The Throughput results are verified based on the total number of responses received from the controller over the sample interval (not considering every packet_ins results in a packet_out). We may look at adding this as an additional metric if the end users are looking for such metrics. As you pointed out, we shall leave this open for discussion. - The Reactive Mode Flow setup in section 6.1.1.2.2 is a little unclear. If the objective is to have the 10% of all "specified" switches that are connected send Packet_In messages I'd rephrase the second sentence to state "Load controller with Packet-In messages from all connected controllers for a specified interval." [Bhuvan] As suggested, we will rephrase in next version of draft. Regards, Mark ------=_NextPart_001_0075_01CF635F.C9834520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mark,

 

Thanks for reviewing the = draft (initial sections) and providing valuable = comments.

Please find my responses inline with tag = [Bhuvan].

If needed, we can discuss my = responses.

 

Also, I look forward = your comments on other sections of the draft (if = any).

 

Best = regards,

 

3D"Description:

Bhuvan = | Cloud and SDN Solutions

Phone: = +91 44 4567 2222 x242

Mobile: +91 988 428 6693 =

www.veryxtech.com

 

3D"Description:

 

From:= = bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Tassinari, Mark = A
Sent: Saturday, April 26, 2014 4:39 AM
To: = bmwg@ietf.org
Subject: [bmwg] Benchmarking Methodology for = OpenFlow SDN Controller Performance

 

Hello = Bhuvan,

 

Standardizing on a set of controller performance tests = is a great idea and the OpenFlow SDN Controller Performance draft is a = good start.  I’d like to submit some comments and = questions. 

 

-          = The Test Setup section is unclear about where = virtualization is permitted but this can have a dramatic effect on the = results.  I believe the benchmark test should require the = controller and any virtual switches to be on separate servers.  =

[Bhuvan] I do agree with your comment. The = controller and the emulated virtual switches need to be running in = separate servers. We will explicitly capture this point as part of test = setup in our next version.

 

-          = I’m curious to know why the number of = switches in the tests are not defined – not even to require more = than one.  There is way to know if the tests were executed the = tests under the same conditions which makes comparison much less = meaningful.

[Bhuvan] I = agree with you that the number switches should be more than one = (suggestion could be – max. switches supported by the controller). =  We can add a note to specify this in the draft.
But the reasons = behind not defining the exact value for number of switches are:
1) = The number of switches supported may vary from controller to = controller
2) Some controllers may perform better for smaller number = of switches and some for larger number of switches
Hence we left it = to the vendors to specify this parameter based on their implementation. = Also we recommended specifying the results against the number of = switches emulated as part of “Reporting Format” section to = enable comparison.

 

-          = What is the numerator (OFRi) in the Flow setup = rate formula defined in Section 6.1.1.1.4?  Is it the sum of all = packet_out and flow mod messages sent by the controller? =

[Bhuvan] No. We recommend taking into account either sum = of all ‘PACKET_OUT’ (or) ‘FLOW_MOD’ messages. We = can also provide description for OFRi in Terminology section. Please let = me know if you have different thoughts on this. We could discuss = them.

 

-          = The test does not specify whether throughput = results are verified to be lossless (every packet_in results in a = packet_out).  Since TCP is the specified connection it may not = matter but I thought I’d toss it out for discussion.  =

[Bhuvan] The Throughput results are verified = based on the total number of responses received from the controller over = the sample interval (not considering every packet_ins results in a = packet_out). We may look at adding this as an additional metric if the = end users are looking for such metrics. As you pointed out, we shall = leave this open for discussion.

 

-          = The Reactive Mode Flow setup in section = 6.1.1.2.2 is a little unclear.  If the objective is to have the 10% = of all “specified” switches that are connected send = Packet_In messages I’d rephrase  the second sentence to state = “Load controller with Packet-In messages from all connected = controllers for a specified interval.” 

[Bhuvan] As = suggested, we will rephrase in next version of = draft.

 

Regards,

 

Mark

 

 

------=_NextPart_001_0075_01CF635F.C9834520-- ------=_NextPart_000_0074_01CF635F.C9834520 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAAtAEsDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gArL1rXYNGjjUo1xdznbBbR/fkP9B6ml1/XLfw/pUl5cckfLHGDzI3YCs7wvo1wrvrWs/Pql0M4P SBOyAdvf/wDXnOUnfljuddGjFQ9tV+HZLu/8l1fy3N60ad7WNruNI5yuXRG3BT6Z71NRRWhyt3dw ooooEFFFFAFW/wBSs9Lg86+uY4IycBnbGT6D1qeOaOWFZo5FeJl3K6nII9c1R1zQ7TX9Pe1vI1JI PlyY+aNvUH/Oa8sHiG/8PaJqnhu4D+eH8uNh/Ap++B7Ecj/eNYVKvs37y0PUweXrGU7Un76auvJ9 V6dToob638TeKJdX1CeOHRNKbbAZWCo8nrz9M/8AfNdraazp1/bPcWl/bTQR/fkSUEJ9T2/GvI76 xe18T6LocumyahFa2wuHskcJ50zgsxJPBxgD6LV9NC1CPV9UvIvD8mkaXcaZPFPCZUZS2wkHAPqB 29fWrpRajd7s58dWjUqctP4I6L0XX57nph1vTBJbodRtN1z/AKkecv7znHy8888U6y1ew1KSWOxv ILh4TiRYpAxTr1x06H8q89+Gng7S77Q7HW7pJZL2OYtGTIQsexjgAdMd/wAaGceC/iXqsuAtrqFj JdJ6b1BYj8w3/fQrQ4zu28S6MsMsrapZiOKQRSP5y4R+flJ7Hg8e1TXOsadZ2kV1dX1vFbzY8uR5 AFfIyMHvxXFeDfC9tcfDSZNVAUanuupZG4KD+Fs+wAb8a5zwPKuv65pOlarOr2ukpJLZKUIF0d3y nnsoGQPb2NAHsgORkdKWiigArlPEXgpdZ8RWOpRSRxiNl+0IwP7wKQRj3xkflXV0VM4KatI3w+Iq YefPTdnt95yvi/wUPEdxbX9lePY6na8RzqM5GcgHHPB6H3NVbPwx4naO7XV/ES3SS2ssEcKxbV3M uAzEYziu0oqjAwvBmgz+GvDcGm3M0c0kbOxeMEA5Ynv9a5X4sWkWoXGhWcLj7dPcGFVU/N5b4BJ9 s4/WvR656z8E6XaeJbjXSJpr2V2dTK+ViJ67Rj69c9aAE8VaBfar4ZGj6PcQ2kbBY5GkBP7sD7ox 64H4ZrL1/wAAyXKaLLoVzFZ3elKESSRThlHIzj3z/wB9Gu2ooAbHv8tfM278Ddt6Z74p1FFAH//Z ------=_NextPart_000_0074_01CF635F.C9834520 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAX8AAAABAQAAAAAeYJPPAAAABGdBTUEAALGOfPtRkwAAAAlwSFlz AAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAAMSURB VBhXY2AgEQAAADEAAR3vwWAAAAAASUVORK5CYII= ------=_NextPart_000_0074_01CF635F.C9834520 Content-Type: image/jpeg; name="image006.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAA9AX4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2akJ5 paaxwM0MCKe4S3iaSVlVFBLMxwABXHaf8UdK1C/uIRDLFBBG8pncjaVX0HXntVbxfcah4pvW8O6E MQIR9uuj9xP9jPc+ork7jw3FMJrHSmMel2h/03UpBzPIP4U9QOw6ZrSEV1Mpza2Oz0/4qaZfW99O 9tNBHaR78uRmTJwFA9TRb/FPTZtFudRktZohDIsSxFgWkYjOBXDS6La3kKRxH7JYWo3SKOZJ3PAO fX9AKWfRra72XEm2DTrfEcVpGfmkbuS382/AVfs0YLErueq+FvE0PinTHvYIJIUWQx7XIJyMen1r bzXBWPim20jw9ElnYRQsHKpAhwAo/iJrrtF1BtU0uG6dAjSAkqO1Zyi0bU6sZuyZoUtIKWoNgooo oAKKKKACiiigAooooATNNkmSGJpJXVEUZZmIAA9zWf4i0w6xoF7Yo7RyTQsqMpwVbqp/PFecTa3L 4k0O/wBUdQy6VoxhlilXKG6b74ZTwcBR19aAPV/MQJvLAJjO4njHrRHIksayRsrowyrKcgj2NeeS eIbxdautOubqA2j2Un2a2ijjdGCw5Ic53IwPYjBFReEbi8bxTpyPqaw2suiwTJZLGqo3UFUHbB5y OccUAelZoyK4DxN4wu9HvvENut5DC9tbWz2SOF3MzkhsA/e/pVmy1++b4gNp11ex/Z5Fb7PBEiOC FQE72B3IwPYjBoA7bNGa8t8d63O3iWWayTUJP7BWOQfZomaMuWDSCQjgDy/X1qfxD40v4L7UpdN1 W0ht7W2trq1t3iVmuvMHKA5zz7c8igD0iWaOCMvLIqIvJZiAB+NCTxSlxHIjlDhgrA7T6H0rzjxB qupXmneK3nnt2sdPKRpaSW6tuLKjfMT6EnArd8Ihf7V8VZIVf7S5OcY/cpQB1uaK8q06OHUL3xBP 4Y1UWVm1k1vE014WMswOWmwSSqjpu981pfDx7iPVdZht40W0ihhIiivDcxibB3YkPcjBIHTigD0O jPFYFlqfiOa8ijvdAgt7djh5VvlcoPXbt5rkNb1F9E+IOp668sptLD7NFcxgkjypEYZ2+oYKaAPT s0ZFeRWeqX+iPrd5PdTR315FaTdA/lvM74UBiFXAwMngYqW28fa1a6UL69ljmjl+02UW2NTm5Qjy iSvB3AkcccUAesZFGax7qE/8Iz5er3picQKJ50cQ5bAzg9snj8azPAOqWh8D6N5t7CZHUQjdKCTJ yQvX72O3WgDq6M15/wDEr7BcXFpYx3Jh1ufabeU3RiS1jDZaVuQPUeprF126Daxq9w19J/a1pfWc WnIsxBaNgmdqA4YNlsnBoA9a3UZrhobu1sPibqPlXjXMj6bvMBuN7GQSH92q54OB0FZfgrUbmb4g 3ZvodRS7u7ASzR3ELIsTb+AAeihcKD3INAHp1FJS0AFFFFABRRRQAUUUUAJUcqGRCuSMjGRwRT81 zMXim8utbuLS00iWS0tpmhmu/MACkDJ+XqaLXE3Y1xplrb6c1rCnkwsCG2nBOepJ9T61yt3Ztrrr FbhbPQ7Lo4GA+OpA/rV4+Lre88HT6s8CtsB8y2Eo3Ab9vJ7Vsq9ldaesjPCbZVDHDjYuOx7cVSbi ZVIKehxqaNHeIbqZTZ6NbjKDHzy+/wBTR/Y6uh1HU4Tb2iDbbWa/ef0H49+9drM9k8MM80kJgB3I 5cbM9j6Upazlul3PE0yfdUsMr+FXzsx+rRRzOk+Enu7j7dq6KoPMdsvAUdgf8K7KKNY41RAAo4AA wBUBuYlMiJIhkQZZA3I/CoNH1VNUsY512q7DJjDZK896iTb3NqcIQ0iaOKWkBpak2CiiigAooooA KKKKACiiigBCM1WXTbNIZoktLdYpyTKgiXbIT1LDHP41aooAprpVis7zrZ2wmkXY8giXcy+hOMke 1OGm2ayQyLawB4F2RMIxmMeinsPYVaooAqT6VY3UokubS3mkClA8kSsQp6jJHSlj0yziumuY7WBL hxhpljAdh6Fupq1RQBXW0t0EoWCMCY5lAQfvCRjLevHHNZkHhbTYtXm1AW8btIsapG0alIdgIUoM fKeawPiR5sl1oFvD84luZA0Ru2tlkAQnBdeR61jaJ4n1RtL03SoNThtJkhuHmvL0CUExPt8tTkBh z97OcCgD0ptPtXWZXtoWE5zKDGCJD6t69O9KLa2gErLHHGJDulIUDccYy3rx6156/jjWL+0hkhuL HTHj0oahJ9oj3CdskbFyRgfL15PzCq97qWqahfaw9xfCK0m8Pi5+wsnQtG2QCT1B5Jx7UAegQaHp MW6S302xjMilS0cCDcp6jIHINWrS0trCAQ2lvFBEDwkSBF/IVyXgrUtTS5g0rUJreaH+yre6hMUZ Qxg/LtPJz0HNcxqWoXmnQ+K7p7uc2l1cXNoMyH9xKoBjK/3QQWHHfFAHrfUVWlsLSUzebbQv5wAl 3Rg+YB0Dcc4964G88Y6ray3clvdWccGmS29v9ilTMt3vC5YNnI+9xgHoa1PiNE0ujloCpmjjkdVO oG1KjH3wB98g44PFAHUy6bZziQS2sEglULJviDbwOgORyBVC/wDDVhfLZR+WsMFpdLdCKFFVHdQc buPx/CvOdQ1Q6jYTTz6rdwtZ6HDdWLNKYmklOcuVB+YkgDHI5ovNTupPFkd3PeXCpHd2sMkqTlWg YoN0Qgzh1JIy2OM+1AHrNzaQXsDQ3UMc0TfeSRAyn6g8GqX/AAjemLcWssVpFCLWQzRxwoEQyEbd xAHJA6GtMUtAFK80bTtQkEl9YWly4GA00CuQPTJFOOl2RuI7g2luZ4htjk8pdyD0BxkD6VbooAor oumrefa1sLQXW7d5whUPn13YzmrItoRcGcRIJiuwybRuK+meuPapaKAEpaKKACiiigAooooAKKKK AGngVw3h2bUV17X447WE6c17MZJzJh1baMAL6V2xYYNcvZaNrOn63emGaybTry5aeUMG80bhggdq pESOZtNOtIvhLeXkdtGlxcArLIBhnAl4BNVdSht9P0rVraGDbaDWLVWgiHDKUBZQO+fStqLwTrI0 u6059Qh+yCMx28a5AYmTfuf3HTirl74Qu7qDUhHPEs0t5DeW+QSuY1Aw31IPSndE2ZgWdhHPbaJa Xdk8dnLrM5S2nQriMqSo2ntWzJbRLr0koQCRdUjjVh1C7en0q9F4d1RzpM+oXqT3FteyXUx5woYE BEz2GasPoU7ag84kj2tfLcjrnaBjH1oi9SKkG0rGJpatJriyRwylxNcCefadrDB2gmt/whZW8OiW 9xHEiyzJ87jq3J61HY6LfWl+266X7EHkkCpnc5fs3bipdE0i+0+dVuLlGtoUKRImfmyc7m96bdyK cHFptHQDrS01XBOBT6zOsKKKKACisTxNaXt7ZRJYFmKyh5YVmMLToM5UOPunofwrCn8WtZ6favpi NLDHGDPFOjySoN5QhnBwvIOCc5xQB3FFcu+vaiupSAQ2pskv1sjkt5h3AYb0GC3Tv7VTstb1eHQz Lc3FrNdS3ksEAW3kcsFZgQFU84C+owOtAHaU0sF68VzUuvXU/gKXWIYxFdeQzAYyEYEqTg+mM4qv qunQ2Hh6WSC9up2l8liZbgyB/wB4vzgHp+GBQB19FcqPE1z/AMJILNUjls5HliWRInG1kUkjeeGP BBAHHrVObxTq0OjW120do088DXQt4opJCIwB1IOByfvds9DQB21Fc3rV9LPYaOqSvbQ6jPGk0iNt ZVZC20N2JIAz70s7zaTPaaXpMoea6dyGvJWlWEKoJHXcSc8DPqaAOjorjR4m1W6h/wBEgs1eK2lm mMjMykxuUITHY44J6e9WY/E88tylssKLcXDQPbqc4MTpuZj7rtcflQBuajo+n6xEkepWVvdoh3Ks 0YcA+ozUdx4f0m6s4bS4020ktoP9VE0KlU+gxxXM2/jDVJ7O4vf7NItvs0k8TNGyqpX7qs5OGz6g DGKdqmt65Ha3MKPZw3kUlq4kRWZDHK+3bgnqCOT3HpQB015oemah5P23T7W48jHleZEreXj0yOKd c6Pp95cCe5sreWZYzEHeMEhDwVz6HPSsGfVrqy1C8gjEb3Us9vbq0jt5Ss0ZJO3PA4PA6nFImv6r NdR6fFHZfbRcSW8kp3GL5UDhgM5/iAIz+NAHRw6faW8yyw28UcixCEMqgEIOi/QelRy6Pp01tNby 2Vu8M7+ZLG0YKyN/eI7ngc1lS65dS+Bp9WijVLpbd3Cj5grrkEj1GRmoJnj8NaK+pQXF1fTPEnyy TmQSsxAD47cn+HAoA2pND0yW/ivZdPtXu4QBHM0Sl0A6YOKXUNF03VhH/aNjbXXlHKedGH2n2zXP xa/rUiwQGyiiuZrryFknjeNGXyy24ITngjGM80211rVr7V9K2vbQwyR3AuYtrNuaJwpKnP5fU5zQ B0V1ommX0sEt3YWs0lv/AKlpIlYx/TPSmyaHpcmpLqMun2rXq/duGiUuP+Bda5i28YapPY3N7/Zp Ft9mknhZo2RVK9FZicNn1AGK6uw+1NZI98YTMwyRCCFHoOf50AWlYHocinVheG9x8IWYR9jmEgOe dp5waxLHUJ9Ct57S585NW2xndNM9zHcbiVDooOQSc/Lx/WgDuKK5C08R6pqUVjFbwW0V1PJcRyGZ XCoYsc7c559CeKbYa9qV/qtvOZLaGxfTTcywspJVgxBIb6j06ds0AdjSVzfhzxBdarfz213EoCxJ PFIsTxh0YkdGOSOODxn0qLQojqfmapd3tyt0l3LHsWcqkYVyoj2dOgHUZOaAOpDBhwaWuBj8RXOj eHLAWixzNHbtPLGYndtgcjO4cKOvJz9K1bnX7+ObUXX7JHbWzpFGXV3eR3VSBhf97GO/tQB1GaQM G6HNZPhrVZ9X06WS7hEU8M7wuAhXO3vtOSOvSm+HuRqnP/MQm/pQBtUVyuiQjVGl1O8vblbpLySL Ys5WOMK5UIU6cgA8jJzVLR/EP2jxUJTNcm3v3khRHjcRJs/1ZUkbcsA/Q85FAHb0Ug6UtAHnjyXW j6g66cvkq91Iu59zbwpXag6+pp0up6jOsdxHeSm4iSWRlEPEbAE7PQjge9d/sBx7UbAOgH5U7k8p wba5q28GW6eKKbq4iH7kB2HHHfA61BBrWrxb3XzFmkk8xYSnEznYCnPQAEmvQ9gPX+VIYg3X+VF0 FmcDH4g1XcRHdGbc8cJzEB5byDj8ARirOuu1trwkj8yWdFjWOP5gwPPzJjhh/eBrqINC062dWhtY 0Kv5gIzw2MZ/Kr2wZB7jvRcOU4P+3tVuYi0FwyBU3bkizlgqZHT1ZqmbUtYMgiF1KoRzGX8oZYby uTx6AV2oQDoB+VLtHt+VO4WOD0a8vbnxDZy3Uske/IYBcK7eWOvvXejpSbR6D8qdSY0rBRRRSGU9 R0qz1aJYr6BJkU7gGzwfUEVXm8NaRceT5un27CBPLjGzAVewxWpRQBUOmWpDZgQlpROeOsgxhvrw KrS+HNKmSZZLGErNL5zjB5f+97Hr09a1KKAK1vYW1paLa28McduoIESr8oB6jFVLfw3pNrHKkFhB GkpBcBeuDkD2AIzitSigDNXw/pqX7XqWcIunJZpdvJJGCfxB5pLnw9pl5DBFcWUMkcC7YlZeFX0+ ntWnRQBVm061ubA2c8EcluVC+WwyuB0/Kqh8NaS1gLM2EJtw28Jg8N6565981q0UAUk0mzjQKltE qiEwABcDyz/D9KVNKs0uILhbeMTW8XkxOF5ROPlHtxVyigDLTw3pUcs8iWEKtcKVlwOGB5Ix05qe 40ixu0nW4to5FnRY5Qw+8q/dB+mTV2igDPl0TT54JYJbSJ4pQodWGd20YX8uxp1to9lZpAttbRRi DcYto+6W6n6mr1FAEFvaQ2tsIIYlSEZwgHAycn+Zqlb+G9JtY50h0+3VJ12yLsyGHpjsPYVqUUAZ 1poWnWKRpa2scaxuZUxk4YjGee+OKcdEsCYD9lj3W8jSxEDBRmOSR9TV+igDLTw3pUck8kdjCrXC lZcDhgeox0GfatLbhNo4wMU6igChp2lpY6RFp7N50caeWS643A9cj8agTwvo8VpJbJp8IhlILrg8 kdOevHataigCja6NY2QiFtaxRCHcY9q427vvY+uKb/YWnBrdhaRBrZWSEgfcU9R9D6VoUUAZ+naH p+kuzWFpFAXGGKDBI9PpQ2g6a+pfbzZw/a8583bzn19M+9aFFAGVP4a0m5WFZ7CCRYVKxhl+6Cck fTNTzaPY3EM8M1tG8dwQZVI++QAAT7gAflV6igCrY6da6ZbmCygSGMtuKoMAk9T9aZp+niwNziQv 59w8/Ixt3Y4/SrtFAGbJoGmTX5vXsoTdHrJt5PGM/X361OdMtGtYLYwJ5NuVaJMcIV+6R9Kt0UAJ S0UUAf/Z ------=_NextPart_000_0074_01CF635F.C9834520-- From nobody Mon Apr 28 17:36:55 2014 Return-Path: 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 2CCD11A8844 for ; Mon, 28 Apr 2014 17:36:52 -0700 (PDT) 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, SPF_PASS=-0.001] 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 O_MGxfV_HhcJ for ; Mon, 28 Apr 2014 17:36:49 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7A1A8841 for ; Mon, 28 Apr 2014 17:36:49 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3T0SEJP009276; Mon, 28 Apr 2014 17:36:43 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1kfyw4uhdp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Apr 2014 17:36:42 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 17:36:41 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Mon, 28 Apr 2014 17:36:40 -0700 From: ramki Krishnan To: "Fernando Calabria (fcalabri)" , Barry Constantine , "MORTON, ALFRED C (AL)" , "bmwg@ietf.org" Date: Mon, 28 Apr 2014 17:36:36 -0700 Thread-Topic: [bmwg] Re-Charter Text for review Thread-Index: AQHPYuYI+sFq4e5XzUOeDhY19DyGBpsnwFPQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-28_03:2014-04-28,2014-04-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1404290004 Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/qaTp_2Nuk_0KfmrSBnu4ELEO9WQ Subject: Re: [bmwg] Re-Charter Text for review X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:36:52 -0000 +1. -----Original Message----- From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Fernando Calabria (f= calabri) Sent: Monday, April 28, 2014 6:31 AM To: Barry Constantine; MORTON, ALFRED C (AL); bmwg@ietf.org Subject: Re: [bmwg] Re-Charter Text for review +1=20 On 4/28/14, 9:07 AM, "Barry Constantine" wrote: >Hi Al, > >I think the charter is well written and with topics that are very >relevant. > >Thank you, >Barry Constantine > >JDSU Network and Service Enablement >Principal Member Technical Staff >301-325-7069 > >-----Original Message----- >From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of MORTON, ALFRED C >(AL) >Sent: Thursday, April 24, 2014 1:21 PM >To: bmwg@ietf.org >Subject: [bmwg] Re-Charter Text for review > >BMWG,=20 > >Over the last year, we've developed this set of paragraphs for specific >work items one at a time. Now it's time for one last look (by May 2) and >then we declare consensus and move to the next step (unless the wheels >come-off). Reply with your comments on the text below. > >Al and Sarah, >bmwg co-chairs > >-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > >Description of Working Group: > > >The Benchmarking Methodology Working Group (BMWG) will continue to >produce a series of recommendations concerning the key performance >characteristics of internetworking technologies, or benchmarks for >network devices, systems, and services. Taking a view of networking >divided into planes, the scope of work includes benchmarks for the >management, control, and forwarding planes. > >Each recommendation will describe the class of equipment, system, or >service being addressed; discuss the performance characteristics that are >pertinent to that class; clearly identify a set of metrics that aid in >the description of those characteristics; specify the methodologies >required to collect said metrics; and lastly, present the requirements >for the common, unambiguous reporting of benchmarking results. > >The set of relevant benchmarks will be developed with input from the >community of users (e.g., network operators and testing organizations) >and from those affected by the benchmarks when they are published >(networking and test equipment manufacturers). When possible, the >benchmarks and other terminology will be developed jointly with >organizations that are willing to share their expertise. Joint review >requirements for a specific work area will be included in the detailed >description of the task, as listed below. > >To better distinguish the BMWG from other measurement initiatives in the >IETF, the scope of the BMWG is limited to the characterization of >implementations of various internetworking technologies using controlled >stimuli in a laboratory environment. Said differently, the BMWG does not >attempt to produce benchmarks for live, operational networks. Moreover, >the benchmarks produced by this WG shall strive to be vendor independent >or otherwise have universal applicability to a given technology class. > >Because the demands of a particular technology may vary from deployment >to deployment, a specific non-goal of the Working Group is to define >acceptance criteria or performance requirements. > >An ongoing task is to provide a forum for discussion regarding the >advancement of measurements designed to provide insight on the >capabilities and operation of inter-networking technology implementations. > >The BMWG will communicate with the operations community through >organizations such as NANOG, RIPE, and APRICOT. > >In addition to its current work items, the BMWG is explicitly tasked to >develop benchmarks and methodologies for the following technologies: > >Traffic Management: Develop the methods to characterize the capacity of >traffic management features in network devices, such as classification, >policing, shaping, and active queue management. Existing terminology will >be used where appropriate. Configured operation will be verified as a >part of the methodology. The goal is a methodology to assess the maximum >forwarding performance that a network device can sustain without dropping >or impairing packets, or compromising the accuracy of multiple instances >of traffic management functions. This is the benchmark for comparison >between devices. Another goal is to devise methods that utilize flows >with congestion-aware transport as part of the traffic load and still >produce repeatable results in the isolated test environment. > >IPv6 Neighbor Discovery: Large address space in IPv6 subnets presents >several networking challenges, as described in RFC 6583. Indexes to >describe the performance of network devices, such as the number of >reachable devices on a sub-network, are useful benchmarks to the >operations community. The working group will develop the necessary >terminology and methodologies to measure such benchmarks. > >In-Service Software Upgrade: Develop new methods and benchmarks to >characterize the upgrade of network devices while in-service, considering >both data and control plane operations and impacts. >These devices are generally expected to maintain control plane session >integrity, including routing connections. Quantification of Upgrade >impact will include packet loss measurement, and other forms of recovery >behavior will be noted accordingly. The work will produce a definition of >ISSU, which will help refine the scope. Liaisons will be established as >needed. > >Data Center Benchmarking: This work will define additional terms, >benchmarks, and methods applicable to data center performance >evaluations.=20 >This includes data center specific congestion scenarios, switch buffer >analysis, microburst, head of line blocking, while also using a wide mix >of traffic conditions. Some aspects from BMWG's past work are not >meaningful when testing switches that implement new IEEE specifications >in the area of data center bridging. For example, throughput as defined >in RFC 1242 cannot be measured when testing devices that implement three >new IEEE specifications: priority-based flow control (802.1Qbb); priority >groups (802.1Qaz); and congestion notification (802.1Qau). >This work will update RFC1242, RFC2544, RFC2889 (and other key RFCs), and >exchange Liaisons with relevant SDOs, especially at WG Last Call. > >VNF and related Infrastructure Benchmarking: Benchmarking Methodologies >have reliably characterized many physical devices. This work item extends >and enhances the methods to virtual network functions (VNF) and their >unique supporting infrastructure. First, the new task space will be >considered to ensure that common issues are recognized from the start. >Benchmarks for platform capacity and performance characteristics of >virtual routers, switches, and related components will follow, including >comparisons between physical and virtual network functions. > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg