From acmorton@att.com Thu Apr 8 13:55:08 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033413A6A26 for ; Thu, 8 Apr 2010 13:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.534 X-Spam-Level: X-Spam-Status: No, score=-104.534 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6m9ENUqBSUo for ; Thu, 8 Apr 2010 13:55:07 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 003613A695D for ; Thu, 8 Apr 2010 13:55:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1270760101!34278234!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13133 invoked from network); 8 Apr 2010 20:55:02 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2010 20:55:02 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o38Ksmi7031357 for ; Thu, 8 Apr 2010 16:54:48 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o38Ksh7u031296 for ; Thu, 8 Apr 2010 16:54:43 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o38Ksuh8020895 for ; Thu, 8 Apr 2010 15:54:56 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o38Kssr5020868 for ; Thu, 8 Apr 2010 15:54:54 -0500 Message-Id: <201004082054.o38Kssr5020868@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100408205453gw100b8i1te>; Thu, 8 Apr 2010 20:54:53 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Apr 2010 16:54:22 -0400 To: bmwg@ietf.org From: Al Morton In-Reply-To: <201003250014.o2P0EK0U015296@alpd052.aldc.att.com> References: <201003250014.o2P0EK0U015296@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [bmwg] WGLC: IGP-Dataplane Convergence Time drafts X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:55:08 -0000 This last call has ended quietly after many, many, calls
with comments, so I will now declare "Working Group Consensus".

There are a few small items that needed fixing, as we agreed
during our session at IETF-77. So when the drafts have been revised,
we'll proceed (again) to the Publication Requested state.

Al
bmwg chair

At 08:14 PM 3/24/2010, Al Morton wrote:

BMWG,

This message begins a WG Last Call on the IGP-Dataplane Convergence
Time Benchmarking drafts.

http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-term-20

http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-meth-20

The Last Call will end on April 7, at 5PM US EDT, 2200 GMT.

This is a topic we've been discussing in BMWG
as long as I have been chairman. The state of the art advanced
while we were developing these drafts, and hopefully now they
are fully in-sync and relevant. The term and meth drafts
have been improved again based on new testing experience
in the -20- versions.

We also need to decide whether we need this expired draft:
http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-app-17
It may be that the revisions to bring this in sync with the terms
and meth drafts are fairly trivial. Comments on this are welcome.

Please weigh-in on whether or not these Internet-Drafts
should be given to the Area Directors and IESG for consideration and
publication as an Informational RFCs. Send your comments
to this list or acmorton@att.com.

Al
bmwg chair
_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

From acmorton@att.com Thu Apr 8 14:07:44 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23883A6A93 for ; Thu, 8 Apr 2010 14:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.214 X-Spam-Level: X-Spam-Status: No, score=-105.214 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meVq3m5KLTXS for ; Thu, 8 Apr 2010 14:07:44 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id EC5323A67A4 for ; Thu, 8 Apr 2010 14:07:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-167.messagelabs.com!1270760859!31595047!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 7162 invoked from network); 8 Apr 2010 21:07:39 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2010 21:07:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o38L7oc4022916 for ; Thu, 8 Apr 2010 17:07:50 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o38L7mIV022884 for ; Thu, 8 Apr 2010 17:07:49 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o38L7anE004923 for ; Thu, 8 Apr 2010 17:07:36 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o38L7ZCH004869 for ; Thu, 8 Apr 2010 17:07:35 -0400 Message-Id: <201004082107.o38L7ZCH004869@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100408210735gw100b8i23e>; Thu, 8 Apr 2010 21:07:35 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Apr 2010 17:07:07 -0400 To: bmwg@ietf.org From: Al Morton In-Reply-To: <7F298ACC76CC154F832B6D02852D169FE17EF9@XMB-RCD-101.cisco.c om> References: <7F298ACC76CC154F832B6D02852D169FE17EF9@XMB-RCD-101.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:07:44 -0000 BMWG, At our IETF-77 session, there was support to adopt the subject draft (but few readers present at the meeting). We received advice (from AD-Advisor Ron) that BMWG could add this work item under our current charter. Therefore, we are raising the question again on the list: Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 as a chartered work item? Please *read* and express your opinion on whether or not this Internet-Draft should be adopted as an Informational RFC. Send your comments to this list or acmorton@att.com by April 26th, at 5PM US EDT, 2200 GMT. Al bmwg chair At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: >Content-Type: multipart/related; > type="multipart/alternative"; > boundary="----_=_NextPart_001_01CAB185.558EF827" >Content-class: urn:content-classes:message > >Hello WG > >We just submitted a new revision of the draft-asati-bmwg-reset , so >far we incorporated all the comments and feedback received by you, >so please take some time "if possible" to go over the document a and >let us know your thoughts and why not any questions and or concerns >you may have > > >Kind Regards > >Fernando Calabria & Authors > From sporetsky@allot.com Thu Apr 8 14:18:18 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45D528C0F3 for ; Thu, 8 Apr 2010 14:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bqCyQEIYxKA for ; Thu, 8 Apr 2010 14:18:17 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by core3.amsl.com (Postfix) with ESMTP id CA5A93A6B1C for ; Thu, 8 Apr 2010 14:18:15 -0700 (PDT) Received: from mail.allot.com (Not Verified[172.20.20.20]) by mailgw.allot.com with MailMarshal (v6, 5, 4, 7535) id ; Fri, 09 Apr 2010 00:18:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 00:22:15 +0300 Message-ID: In-Reply-To: <201004082107.o38L7ZCH004869@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Thread-Index: AcrXX41kXzxC6S9+SAiOISmK5FHRtwAAZdnA References: <7F298ACC76CC154F832B6D02852D169FE17EF9@XMB-RCD-101.cisco.com> <201004082107.o38L7ZCH004869@alpd052.aldc.att.com> From: "Scott Poretsky" To: "Al Morton" , Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:18:18 -0000 I would be much more interested to have a work item to measure the conditions that cause a networking device's software to reset. Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, April 08, 2010 5:07 PM To: bmwg@ietf.org Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 BMWG, At our IETF-77 session, there was support to adopt the subject draft (but few readers present at the meeting). We received advice (from AD-Advisor Ron) that BMWG could add this work item under our current charter. Therefore, we are raising the question again on the list: Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 as a chartered work item? Please *read* and express your opinion on whether or not this Internet-Draft should be adopted as an Informational RFC. Send your comments to this list or acmorton@att.com by April 26th, at 5PM US EDT, 2200 GMT. Al bmwg chair At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: >Content-Type: multipart/related; > type=3D"multipart/alternative"; > boundary=3D"----_=3D_NextPart_001_01CAB185.558EF827" >Content-class: urn:content-classes:message > >Hello WG > >We just submitted a new revision of the draft-asati-bmwg-reset , so=20 >far we incorporated all the comments and feedback received by you,=20 >so please take some time "if possible" to go over the document a and=20 >let us know your thoughts and why not any questions and or concerns=20 >you may have > > >Kind Regards > >Fernando Calabria & Authors > _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg From acmorton@att.com Sat Apr 10 08:20:55 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A784D3A69D7 for ; Sat, 10 Apr 2010 08:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.476 X-Spam-Level: X-Spam-Status: No, score=-105.476 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI2KozGJjZ9g for ; Sat, 10 Apr 2010 08:20:53 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 7E5193A6893 for ; Sat, 10 Apr 2010 08:20:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1270912845!54575902!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 23966 invoked from network); 10 Apr 2010 15:20:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Apr 2010 15:20:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3AFKvI8004089 for ; Sat, 10 Apr 2010 11:20:57 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3AFKocf004048 for ; Sat, 10 Apr 2010 11:20:50 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o3AFKcwh028648 for ; Sat, 10 Apr 2010 11:20:38 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o3AFKYZI028636 for ; Sat, 10 Apr 2010 11:20:35 -0400 Message-Id: <201004101520.o3AFKYZI028636@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-86-83.vpn.swst.att.com[135.70.86.83](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100410152034gw100b8i80e>; Sat, 10 Apr 2010 15:20:34 +0000 X-Originating-IP: [135.70.86.83] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Apr 2010 11:19:47 -0400 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [bmwg] Fwd: Publication Request for draft-ietf-bmwg-protection-term-08 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 15:20:55 -0000 BMWG, After a successful WGLC and agreed at the working group session during IETF-77, we are moving this draft to the Publication Requested state. The completed Document Shepherd's form is below. Al bmwg chair >Date: Sat, 10 Apr 2010 11:13:43 -0400 >To: Ron Bonica , iesg-secretary@ietf.org >From: Al Morton >Subject: Publication Request for draft-ietf-bmwg-protection-term-08 >Cc: Dan Romascanu > >This is a publication request for >http://tools.ietf.org/html/draft-ietf-bmwg-protection-term-08 >as an INFORMATIONAL RFC. > > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? >Al Morton is the shepherd, has read this version and says its ready. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? >Yes, I believe so. This work was initially proposed in 2002, and was >discussed extensively with many members of the community before >working group adoption in 2006. Extensive review was sought in the last >two rounds of WGLC. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? >No. There will likely be a few more issues raised by the IESG, but >no laws-of-physics class violations that might stall the work. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. >There are no concerns and no IPR disclosures. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? >The consensus is solid. Many WG members read and agreed >with this document at various times. Many readers completed the >BMWG Active Review template for this draft. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) >No. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > >There are a few errors in the nits: >http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bmwg-protection-term-08.txt >These can be corrected after AD-review, but there will be some work >necessary to adopt the new boilerplate, update references, fix >page lengths, etc. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. >Yes, the references are split. > >There is a normative dependency on: >"Benchmarking Terminology for IGP Convergence", >draft-ietf-bmwg-igp-dataplane-conv-term-21, (to be published) which is >also effectively at the Publication Requested state. >(Authors: this reference needs to be updated in the next version) > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? >N/A > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? >N/A > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. > > The purpose of this document is to provide a single terminology for > benchmarking sub-IP protection mechanisms. > > Technologies that transport IP packets can be designed to provide > protection for IP traffic by providing the failure recovery at lower > layers. Possibly, the outage is not even observed at the IP-layer. > Sub-IP protection technologies include, but are not limited to, > High Availability (HA) stateful failover, Virtual Router Redundancy > Protocol (VRRP), Automatic Link Protection (APS) for SONET/SDH, > Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for > Multi-Protocol Label Switching (MPLS-FRR). > > Benchmarking terminology was defined for IP-layer convergence in > draft-ietf-bmwg-igp-dataplane-conv-term-21 . > Different terminology and methodologies specific to > benchmarking sub-IP layer protection mechanisms are required. The > metrics for benchmarking the performance of sub-IP protection > mechanisms are measured at the IP layer, so that the results are > independent of the specific protection mechanism being used. > > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? > Working group consensus was smoothly achieved over a period of > several years, with many controversies ironed-out before WG adoption. > Several authors came and went, but others were willing to pick-up the > work and complete it, so here we are. > > Document Quality > >Q - Are there existing implementations of the protocol? > >A these documents neither propose a new protocol nor extend any existing >one, hence current implementations are not required to support this >document. The document only attempts to standardize the benchmarking >strategies so that service providers could evaluate multiple protection >implementations using standard figures of merit with an aim of >producing consistent test results across multiple platforms. > >Q - Have a significant number of vendors indicated their plan to implement >the specification? > >A - Several test vendors, including the leading ones, have >shown their support and interest in the execution of these methodologies. >The authors have regularly acknowledged them in WG status presentations. > >Reference/acknowledgements were shared in the following: >http://www.ietf.org/proceedings/06jul/slides/bmwg-3/bmwg-3.ppt > >Q - Are there any reviewers that merit special mention as having done a >thorough review, e.g., one that resulted in important changes or a >conclusion that the document had no substantive issues? > >A - The following lays down the history of this work item, which >demonstrates substantial revisions of the documents based on comments form >the BMWGers > >1. July 2005: Common protection terminology created due to merger of >draft-kimura-protection-term-02.txt and >draft-poretsky-mpls-protection-meth-02 as result of series of reviews and >comments. New draft-poretsky-protection-term-00.txt created. > >2. December 2005: another effort with additional test scenarios >(draft-vapiwala-bmwg-frr-failover-meth-00.txt) was merged into >draft-poretsky-meth-05. It was felt that additional scenarios proposed were >needed to offer comprehensive MPLS (including the services) based protection >techniques evaluation. Terms checked against this new methodology. > >3. June 2006: Due to additional test items proposal, a new draft was >created draft-papneja-mpls-protection-meth-merge-00.txt > >4. Also in the combined effort Mr. Vapiwala were included as one of the >co-authors due to his contribution to the effort in the form of additional >test scenarios for the methodology document, and accordingly updating the >terminology document. > >5. The acknowledgement section is included for terminology document to >thank those who significantly helped in shaping the final version. The >document did receive comments from one of co-authors of original fast >reroute RFC 4090 in the early versions of the work item document in addition >to other pioneers in the MPLS field. From acmorton@att.com Mon Apr 12 09:10:32 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC653A6A9A for ; Mon, 12 Apr 2010 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.03 X-Spam-Level: X-Spam-Status: No, score=-104.03 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrJLXtMEKEYk for ; Mon, 12 Apr 2010 09:10:30 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 502203A6A6C for ; Mon, 12 Apr 2010 09:09:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1271088565!47315380!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 27365 invoked from network); 12 Apr 2010 16:09:26 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Apr 2010 16:09:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3CG9ano010675 for ; Mon, 12 Apr 2010 12:09:37 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3CG9XTd010586 for ; Mon, 12 Apr 2010 12:09:33 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o3CG9Kop028748 for ; Mon, 12 Apr 2010 12:09:20 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o3CG9FCJ028321 for ; Mon, 12 Apr 2010 12:09:15 -0400 Message-Id: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100412160915gw100b8j3me>; Mon, 12 Apr 2010 16:09:15 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Apr 2010 12:08:18 -0400 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dan Romascanu , Eric Gray Subject: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:10:32 -0000 BMWG, The first draft Liaison to IEEE 802.1 describing the proposal to update RFCs 2544 and 2889 to address the Per-Flow Control capabilities of IEEE 802.1Qbb is below. Thanks to David Newman and Eric Gray (IETF Liaison Manager for 802.1) for suggested text and/or background info shared off-list. Comments by April 26, 2010, on the bmwg-list, please. Al bmwg chair --------------------------------------------------------------- To: IEEE 802.1 Tony Jeffrey, WG Chair tony@jeffree.co.uk and Pat Thaler, DCB TG Chair pthaler@broadcom.com From: IETF-BMWG Al Morton, WG Chair acmorton@att.com For Action/Comment Deadline: August 1, 2010 Title: Proposal to update RFCs 2544 and 2889 to address the Per-Flow Control capabilities of IEEE 802.1Qbb The purpose of this Liaison is to inform you of a new work proposal in the Benchmarking Methodology Working Group (BMWG) of the IETF, and seek your comments. BMWG is considering adding a charter work item to update several of our fundamental RFCs, described in detail in the memo by D.Newman and T.Player: http://tools.ietf.org/html/draft-player-dcb-benchmarking-01 In this proposal, there is an intersection between IETF benchmarking practice and new IEEE standardization work. Benchmarks for Ethernet switch performance based on RFCs 1242, 2285, 2544 and 2889 are recognized as industry standards. The terminology and methodology described in these memos has been in widespread use by test equipment vendors, networking device manufacturers, enterprises and service providers for more than a decade. Some concepts in these RFCs 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. There are related cases where other existing metrics can be extended or replaced. The Internet-Draft seeks to recognize the importance of these new IEEE specifications in the context of data center switch benchmarking. The draft seeks to extend rather than replace existing industry standard practices for benchmarking switch performance characteristics in the lab, and it does so by defining new terms and metrics relevant to recent IEEE work on data center bridging. The charter of BMWG strictly limits our work to laboratory characterization. Therefore, live network performance testing, manageability, MIB module development, and other operational/functional testing is beyond our scope. http://www.ietf.org/dyn/wg/charter/bmwg-charter Before considering this work proposal further, we seek your comments on: - whether there is overlapping work planned in 802.1 - whether a liaison relationship could be beneficial to complete this work - the proposal details, as currently described sincerely, Al Morton bmwg chair From dromasca@avaya.com Tue Apr 13 03:10:54 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6310F28C0EF for ; Tue, 13 Apr 2010 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPaVYwzjSnfi for ; Tue, 13 Apr 2010 03:10:53 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 3D1293A69F3 for ; Tue, 13 Apr 2010 03:10:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,196,1270440000"; d="scan'208";a="11338335" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Apr 2010 06:10:42 -0400 X-IronPort-AV: E=Sophos;i="4.52,196,1270440000"; d="scan'208";a="451085123" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Apr 2010 06:10:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 12:09:54 +0200 Message-ID: In-Reply-To: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal Thread-Index: AcraWrXC1c71bunrQeaVwWoyqYZ3dAAlgPBg References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> From: "Romascanu, Dan (Dan)" To: "Al Morton" , Cc: Eric Gray Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 10:10:54 -0000 Looks good, editorial comments in-line.=20 Dan =20 > -----Original Message----- > From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On=20 > Behalf Of Al Morton > Sent: Monday, April 12, 2010 7:08 PM > To: bmwg@ietf.org > Cc: Romascanu, Dan (Dan); Eric Gray > Subject: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal >=20 > BMWG, >=20 > The first draft Liaison to IEEE 802.1 describing the proposal=20 > to update RFCs 2544 and 2889 to address the Per-Flow Control=20 > capabilities of IEEE 802.1Qbb is below. Thanks to David=20 > Newman and Eric Gray (IETF Liaison Manager for 802.1) for=20 > suggested text and/or background info shared off-list. >=20 > Comments by April 26, 2010, on the bmwg-list, please. >=20 > Al > bmwg chair >=20 > --------------------------------------------------------------- > To: IEEE 802.1 > Tony Jeffrey, WG Chair tony@jeffree.co.uk and Pat Thaler, DCB=20 > TG Chair pthaler@broadcom.com > From: IETF-BMWG > Al Morton, WG Chair acmorton@att.com > For Action/Comment > Deadline: August 1, 2010 >=20 > Title: Proposal to update RFCs 2544 and 2889 to address the=20 > Per-Flow Control capabilities of IEEE 802.1Qbb >=20 >=20 > The purpose of this Liaison is to inform you of a new work=20 > proposal in the Benchmarking Methodology Working Group (BMWG)=20 > of the IETF, and seek your comments. >=20 > BMWG is considering adding a charter work item to update=20 > several of our fundamental RFCs, described in detail in the=20 I do not really know what a 'fundamental RFC' is so I suggest to strike this out or use a more clear term.=20 > memo by D.Newman and T.Player: > http://tools.ietf.org/html/draft-player-dcb-benchmarking-01 > In this proposal, there is an intersection between IETF=20 > benchmarking practice and new IEEE standardization work. >=20 > Benchmarks for Ethernet switch performance based on RFCs 1242, 2285, > 2544 and 2889 are recognized as industry standards. The=20 > terminology and methodology described in these memos has been=20 s/has been/have been/ > in widespread use by test equipment vendors, networking=20 > device manufacturers, enterprises and service providers for=20 > more than a decade. >=20 > Some concepts in these RFCs are not meaningful when testing=20 > switches that implement new IEEE specifications in the area=20 > of data center bridging. For example, throughput as defined=20 > in RFC 1242 cannot be measured when testing devices that=20 > implement three new IEEE > specifications: priority-based flow control (802.1Qbb);=20 > priority groups (802.1Qaz); and congestion notification (802.1Qau). >=20 > Since devices that implement these new congestion-management=20 > specifications should never drop frames, and since the metric=20 > of throughput distinguishes between non-zero and zero drop=20 > rates, no throughput measurement is possible using the=20 > existing methodology. > There are related cases where other existing metrics can be=20 > extended or replaced. >=20 > The Internet-Draft seeks to recognize the importance of these=20 > new IEEE specifications in the context of data center switch=20 > benchmarking. > The draft seeks to extend rather than replace existing=20 > industry standard practices for benchmarking switch=20 > performance characteristics in the lab, and it does so by=20 > defining new terms and metrics relevant to recent IEEE work=20 > on data center bridging. >=20 > The charter of BMWG strictly limits our work to laboratory=20 > characterization. > Therefore, live network performance testing, manageability,=20 > MIB module development, and other operational/functional=20 > testing is beyond our scope. s/is beyond/are beyond/ > http://www.ietf.org/dyn/wg/charter/bmwg-charter >=20 > Before considering this work proposal further, we seek your=20 > comments on: > - whether there is overlapping work planned in 802.1 > - whether a liaison relationship could be beneficial to=20 > complete this work It would be useful to specify what liaison we are asking about - probably between the BMWG and the IEEE 802.1 (?) > - the proposal details, as currently described >=20 > sincerely, > Al Morton > bmwg chair >=20 >=20 > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg >=20 From acmorton@att.com Tue Apr 13 07:25:29 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1363A6940 for ; Tue, 13 Apr 2010 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.191 X-Spam-Level: X-Spam-Status: No, score=-105.191 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxXgNjTF8YU7 for ; Tue, 13 Apr 2010 07:25:28 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id EA47B3A69E7 for ; Tue, 13 Apr 2010 07:24:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1271168669!29086103!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 24719 invoked from network); 13 Apr 2010 14:24:29 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2010 14:24:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DEOe9p013166 for ; Tue, 13 Apr 2010 10:24:40 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DEOdOd013154 for ; Tue, 13 Apr 2010 10:24:39 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o3DEOQQV030495 for ; Tue, 13 Apr 2010 10:24:27 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o3DEONCc030395 for ; Tue, 13 Apr 2010 10:24:23 -0400 Message-Id: <201004131424.o3DEONCc030395@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100413142423gw100b8idle>; Tue, 13 Apr 2010 14:24:23 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Apr 2010 10:23:30 -0400 To: "Romascanu, Dan (Dan)" , From: Al Morton In-Reply-To: References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Eric Gray Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:25:29 -0000 At 06:09 AM 4/13/2010, Romascanu, Dan (Dan) wrote: > > BMWG is considering adding a charter work item to update > > several of our fundamental RFCs, described in detail in the > >I do not really know what a 'fundamental RFC' is so I suggest to strike >this out or use a more clear term. It might be better to say "foundation RFCs", or some other adjective, but the point is that these RFCs are key ones. Al From dromasca@avaya.com Tue Apr 13 07:33:11 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF3528C226 for ; Tue, 13 Apr 2010 07:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxev-FjGQLmR for ; Tue, 13 Apr 2010 07:33:10 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 4759528C212 for ; Tue, 13 Apr 2010 07:33:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,197,1270440000"; d="scan'208";a="11378039" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 13 Apr 2010 10:33:04 -0400 X-IronPort-AV: E=Sophos;i="4.52,197,1270440000"; d="scan'208";a="464117427" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2010 10:33:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 16:32:54 +0200 Message-ID: In-Reply-To: <201004131424.o3DEON7K030394@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal Thread-Index: AcrbFQm5yYR2l+ViRIuv+j3BMnzbwwAAPbRA References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> <201004131424.o3DEON7K030394@alpd052.aldc.att.com> From: "Romascanu, Dan (Dan)" To: "Al Morton" , Cc: Eric Gray Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:33:11 -0000 =20 > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com]=20 > Sent: Tuesday, April 13, 2010 5:24 PM > To: Romascanu, Dan (Dan); bmwg@ietf.org > Cc: Eric Gray > Subject: RE: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal >=20 > At 06:09 AM 4/13/2010, Romascanu, Dan (Dan) wrote: > > > BMWG is considering adding a charter work item to update=20 > several of=20 > > > our fundamental RFCs, described in detail in the > > > >I do not really know what a 'fundamental RFC' is so I=20 > suggest to strike=20 > >this out or use a more clear term. >=20 > It might be better to say "foundation RFCs", or some other=20 > adjective, but the point is that these RFCs are key ones. >=20 > Al >=20 >=20 I think that you mean the RFCs that define the basic metrics and methodology of IPPM. It would be good to find some exact words around this definition to be sure that our IEEE 802.1 partners understand correctly what we mean. Dan From fcalabri@cisco.com Tue Apr 13 08:21:35 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF093A6B1C for ; Tue, 13 Apr 2010 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zml+orOIRR1I for ; Tue, 13 Apr 2010 08:21:32 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B71953A6B08 for ; Tue, 13 Apr 2010 08:20:59 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEIoxEutJV2a/2dsb2JhbACbSHGjF5oXhQ0Egyc X-IronPort-AV: E=Sophos;i="4.52,197,1270425600"; d="scan'208,146";a="101357209" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2010 15:20:53 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3DFKrbf017203 for ; Tue, 13 Apr 2010 15:20:53 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 10:20:53 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 10:20:52 -0500 Message-ID: <7F298ACC76CC154F832B6D02852D169F015EED89@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Thread-Index: AcrXX41kXzxC6S9+SAiOISmK5FHRtwAAZdnAAAAAAaAA7tSZIA== From: "Fernando Calabria (fcalabri)" To: "Fernando Calabria (fcalabri)" , X-OriginalArrivalTime: 13 Apr 2010 15:20:53.0245 (UTC) FILETIME=[E8109AD0:01CADB1C] Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:21:35 -0000 Scott, while we sympathize with your request, it is beyond the scope of the current draft / work=20 Rgds=20 Fernando Calabria -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Scott Poretsky Sent: Thursday, April 08, 2010 5:22 PM To: Al Morton; bmwg@ietf.org Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 I would be much more interested to have a work item to measure the conditions that cause a networking device's software to reset. Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, April 08, 2010 5:07 PM To: bmwg@ietf.org Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 BMWG, At our IETF-77 session, there was support to adopt the subject draft (but few readers present at the meeting). We received advice (from AD-Advisor Ron) that BMWG could add this work item under our current charter. Therefore, we are raising the question again on the list: Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 as a chartered work item? Please *read* and express your opinion on whether or not this Internet-Draft should be adopted as an Informational RFC. Send your comments to this list or acmorton@att.com by April 26th, at 5PM US EDT, 2200 GMT. Al bmwg chair At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: >Content-Type: multipart/related; > type=3D"multipart/alternative"; > boundary=3D"----_=3D_NextPart_001_01CAB185.558EF827" >Content-class: urn:content-classes:message > >Hello WG > >We just submitted a new revision of the draft-asati-bmwg-reset , so=20 >far we incorporated all the comments and feedback received by you,=20 >so please take some time "if possible" to go over the document a and=20 >let us know your thoughts and why not any questions and or concerns=20 >you may have > > >Kind Regards > >Fernando Calabria & Authors > _______________________________________________ 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 dnewman@networktest.com Tue Apr 13 08:37:04 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBA03A6AF9 for ; Tue, 13 Apr 2010 08:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id truN-pfy6sHK for ; Tue, 13 Apr 2010 08:37:04 -0700 (PDT) Received: from mail3.networktest.com (mail3.networktest.com [69.55.234.60]) by core3.amsl.com (Postfix) with ESMTP id 3A90A3A6AEF for ; Tue, 13 Apr 2010 08:37:04 -0700 (PDT) Received: from localhost (localhost [69.55.234.60]) by mail3.networktest.com (Postfix) with ESMTP id B531795944 for ; Tue, 13 Apr 2010 08:36:58 -0700 (PDT) Received: from mail3.networktest.com ([69.55.234.60]) by localhost (mail3.networktest.com [69.55.234.60]) (amavisd-maia, port 10024) with ESMTP id 71164-06 for ; Tue, 13 Apr 2010 08:36:58 -0700 (PDT) Received: from levi.local (adsl-99-102-128-38.dsl.pltn13.sbcglobal.net [99.102.128.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dnewman@networktest.com) by mail3.networktest.com (Postfix) with ESMTPSA id 4A02895928 for ; Tue, 13 Apr 2010 08:36:43 -0700 (PDT) Message-ID: <4BC48F8B.1040902@networktest.com> Date: Tue, 13 Apr 2010 08:36:43 -0700 From: David Newman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: bmwg@ietf.org References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> <201004131424.o3DEON7K030394@alpd052.aldc.att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:37:05 -0000 On 4/13/10 7:32 AM, Romascanu, Dan (Dan) wrote: > > >> -----Original Message----- >> From: Al Morton [mailto:acmorton@att.com] >> Sent: Tuesday, April 13, 2010 5:24 PM >> To: Romascanu, Dan (Dan); bmwg@ietf.org >> Cc: Eric Gray >> Subject: RE: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal >> >> At 06:09 AM 4/13/2010, Romascanu, Dan (Dan) wrote: >>>> BMWG is considering adding a charter work item to update >> several of >>>> our fundamental RFCs, described in detail in the >>> >>> I do not really know what a 'fundamental RFC' is so I >> suggest to strike >>> this out or use a more clear term. >> >> It might be better to say "foundation RFCs", or some other >> adjective, but the point is that these RFCs are key ones. >> >> Al >> >> > I think that you mean the RFCs that define the basic metrics and > methodology of IPPM. It would be good to find some exact words around > this definition to be sure that our IEEE 802.1 partners understand > correctly what we mean. The key concepts from past bmwg work this ID include: - throughput, as defined in 1242 and described in procedures in 2544 and 2889. In this ID we suggest a replacement metric, queueput, since throughput measurement is not possible in a DCB device context - various traffic classification concepts described in 4689 But throughput is the big one, given its widespread use. dn > > Dan > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg From sporetsky@allot.com Tue Apr 13 09:06:28 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA20B3A67C1 for ; Tue, 13 Apr 2010 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEUjwzVjN1Gq for ; Tue, 13 Apr 2010 09:06:27 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by core3.amsl.com (Postfix) with ESMTP id 6CFF33A6853 for ; Tue, 13 Apr 2010 09:05:19 -0700 (PDT) Received: from mail.allot.com (Not Verified[172.20.20.20]) by mailgw.allot.com with MailMarshal (v6, 5, 4, 7535) id ; Tue, 13 Apr 2010 19:05:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 19:05:25 +0300 Message-ID: In-Reply-To: <7F298ACC76CC154F832B6D02852D169F015EED89@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Thread-Index: AcrXX41kXzxC6S9+SAiOISmK5FHRtwAAZdnAAAAAAaAA7tSZIAAAdnRw References: <7F298ACC76CC154F832B6D02852D169F015EED89@XMB-RCD-101.cisco.com> From: "Scott Poretsky" To: "Fernando Calabria (fcalabri)" , Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:06:29 -0000 Fernando, I appreciate your sympathy for users experiencing software resets. I think it is laughable that someone wants to benchmark the duration of a software reset. A technically-viable standard would first determine the conditions that cause the device to reset. Let's say hypothetically, under Condition Set 1 vendor C resets at 180 seconds and vendor J resets at 24 hours. Vendor C has optimized software to recover from the software reset in 30 seconds. Vendor J has its software reset achieve the same level of recovery in 240 seconds. According to your proposed work Vendor C would have a better reported result, which is wrong. The mission of BMWG is to provide clarity through the smoke and mirrors, not enable vendors to create more smoke and mirrors. Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Fernando Calabria (fcalabri) Sent: Tuesday, April 13, 2010 11:21 AM To: Fernando Calabria (fcalabri); bmwg@ietf.org Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Scott, while we sympathize with your request, it is beyond the scope of the current draft / work=20 Rgds=20 Fernando Calabria -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Scott Poretsky Sent: Thursday, April 08, 2010 5:22 PM To: Al Morton; bmwg@ietf.org Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 I would be much more interested to have a work item to measure the conditions that cause a networking device's software to reset. Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, April 08, 2010 5:07 PM To: bmwg@ietf.org Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 BMWG, At our IETF-77 session, there was support to adopt the subject draft (but few readers present at the meeting). We received advice (from AD-Advisor Ron) that BMWG could add this work item under our current charter. Therefore, we are raising the question again on the list: Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 as a chartered work item? Please *read* and express your opinion on whether or not this Internet-Draft should be adopted as an Informational RFC. Send your comments to this list or acmorton@att.com by April 26th, at 5PM US EDT, 2200 GMT. Al bmwg chair At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: >Content-Type: multipart/related; > type=3D"multipart/alternative"; > boundary=3D"----_=3D_NextPart_001_01CAB185.558EF827" >Content-class: urn:content-classes:message > >Hello WG > >We just submitted a new revision of the draft-asati-bmwg-reset , so=20 >far we incorporated all the comments and feedback received by you,=20 >so please take some time "if possible" to go over the document a and=20 >let us know your thoughts and why not any questions and or concerns=20 >you may have > > >Kind Regards > >Fernando Calabria & Authors > _______________________________________________ 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 From acmorton@att.com Tue Apr 13 09:14:11 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0223A67E3 for ; Tue, 13 Apr 2010 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.278 X-Spam-Level: X-Spam-Status: No, score=-105.278 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJDBra0Yw6pz for ; Tue, 13 Apr 2010 09:14:09 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 942D23A67C1 for ; Tue, 13 Apr 2010 09:14:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1271175210!7272246!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17422 invoked from network); 13 Apr 2010 16:13:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2010 16:13:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DGDG8J025831 for ; Tue, 13 Apr 2010 12:13:16 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DGD9NB025736 for ; Tue, 13 Apr 2010 12:13:10 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3DGDNQm021527 for ; Tue, 13 Apr 2010 11:13:23 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3DGDJah021484 for ; Tue, 13 Apr 2010 11:13:20 -0500 Message-Id: <201004131613.o3DGDJah021484@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100413161319gw100b8ieue>; Tue, 13 Apr 2010 16:13:19 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Apr 2010 12:12:19 -0400 To: "Scott Poretsky" , "Fernando Calabria (fcalabri)" , From: Al Morton In-Reply-To: References: <7F298ACC76CC154F832B6D02852D169F015EED89@XMB-RCD-101.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:14:11 -0000 Scott, Your response seems to match the scope you proposed, rather than the scope of the draft and proposal we are discussing. I think you know the next step now, if not, see the last paragraph of the announcement below. Al At 12:05 PM 4/13/2010, Scott Poretsky wrote: >Fernando, > >I appreciate your sympathy for users experiencing software resets. I >think it is laughable that someone wants to benchmark the duration of a >software reset. A technically-viable standard would first determine the >conditions that cause the device to reset. Let's say hypothetically, >under Condition Set 1 vendor C resets at 180 seconds and vendor J resets >at 24 hours. Vendor C has optimized software to recover from the >software reset in 30 seconds. Vendor J has its software reset achieve >the same level of recovery in 240 seconds. According to your proposed >work Vendor C would have a better reported result, which is wrong. The >mission of BMWG is to provide clarity through the smoke and mirrors, not >enable vendors to create more smoke and mirrors. > >Scott > >-----Original Message----- >From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of >Fernando Calabria (fcalabri) >Sent: Tuesday, April 13, 2010 11:21 AM >To: Fernando Calabria (fcalabri); bmwg@ietf.org >Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 > >Scott, while we sympathize with your request, it is beyond the scope of >the current draft / work > >Rgds > >Fernando Calabria > > > >-----Original Message----- >From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of >Scott Poretsky >Sent: Thursday, April 08, 2010 5:22 PM >To: Al Morton; bmwg@ietf.org >Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 > >I would be much more interested to have a work item to measure the >conditions that cause a networking device's software to reset. > >Scott > >-----Original Message----- >From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of >Al Morton >Sent: Thursday, April 08, 2010 5:07 PM >To: bmwg@ietf.org >Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 > >BMWG, > >At our IETF-77 session, there was support to adopt the subject draft >(but few readers present at the meeting). We received advice >(from AD-Advisor Ron) that BMWG could add this work item under our >current charter. > >Therefore, we are raising the question again on the list: > >Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 >as a chartered work item? > >Please *read* and express your opinion on whether or not this >Internet-Draft should be adopted as an Informational RFC. >Send your comments to this list or acmorton@att.com >by April 26th, at 5PM US EDT, 2200 GMT. > >Al >bmwg chair > > >At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: > >Content-Type: multipart/related; > > type="multipart/alternative"; > > boundary="----_=_NextPart_001_01CAB185.558EF827" > >Content-class: urn:content-classes:message > > > >Hello WG > > > >We just submitted a new revision of the draft-asati-bmwg-reset , so > >far we incorporated all the comments and feedback received by you, > >so please take some time "if possible" to go over the document a and > >let us know your thoughts and why not any questions and or concerns > >you may have > > > > > >Kind Regards > > > >Fernando Calabria & Authors > > > >_______________________________________________ >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 >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From fcalabri@cisco.com Tue Apr 13 09:32:38 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89B93A694C for ; Tue, 13 Apr 2010 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt6nTu51zb54 for ; Tue, 13 Apr 2010 09:32:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 69DDE3A690B for ; Tue, 13 Apr 2010 09:32:37 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABU6xEutJV2c/2dsb2JhbACbS3GjfZofhQ0Egyc X-IronPort-AV: E=Sophos;i="4.52,198,1270425600"; d="scan'208,146";a="101239901" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2010 16:32:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o3DGWUim023939; Tue, 13 Apr 2010 16:32:30 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 11:32:30 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 11:32:29 -0500 Message-ID: <7F298ACC76CC154F832B6D02852D169F015EEE1F@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Thread-Index: AcrXX41kXzxC6S9+SAiOISmK5FHRtwAAZdnAAAAAAaAA7tSZIAAAdnRwAAFguMA= References: <7F298ACC76CC154F832B6D02852D169F015EED89@XMB-RCD-101.cisco.com> From: "Fernando Calabria (fcalabri)" To: "Scott Poretsky" , X-OriginalArrivalTime: 13 Apr 2010 16:32:30.0971 (UTC) FILETIME=[E9B58CB0:01CADB26] Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:32:38 -0000 Scott, my comments / replies inline,,,=20 Rgds=20 Fernando=20 -----Original Message----- From: Scott Poretsky [mailto:sporetsky@allot.com]=20 Sent: Tuesday, April 13, 2010 12:05 PM To: Fernando Calabria (fcalabri); bmwg@ietf.org Subject: RE: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Fernando, I appreciate your sympathy for users experiencing software resets. I think it is laughable that someone wants to benchmark the duration of a software reset. A technically-viable standard would first determine the conditions that cause the device to reset >>> Determine the conditions is really quite complex and vendor "dependant" , each platform specific software implementation is different, and the idea behind all these efforts is to steer away from vendor's specific implementations ....=20 . Let's say hypothetically, under Condition Set 1 vendor C resets at 180 seconds and vendor J resets at 24 hours. Vendor C has optimized software to recover from the software reset in 30 seconds. Vendor J has its software reset achieve the same level of recovery in 240 seconds. According to your proposed work Vendor C would have a better reported result, which is wrong. >>> Why this is wrong ?? apologies but I don't quite follow it , with this work, we are just measuring the amount of packets / traffic lost (duration of the outage) while all vendors implementations are subject to exactly the same failure / condition (in other words the end user experience / overall convergence) without getting into each specific vendor's implementation details / recovery mechanisms / for even Software and or Hardware failures....=20 >>> In the example you just provided one vendor may reset after 24 hours (you are saying that this is better) but maybe no network connectivity or degraded service / performance (traffic loss) was experience for this period of time ... (so now my question is which implementation you think it is better now ??=20 >> Not sure what is more fare than comparing the amount of traffic loss / convergence time after the same set of failure / conditions ?=20 The mission of BMWG is to provide clarity through the smoke and mirrors, not enable vendors to create more smoke and mirrors. >> I sympathize with your comments from the context that there is open room for additional work / drafts when it comes to determine the conditions that cause a device to reset, but this like I mentioned before is outside the scope of the current work , (we don't want to establish any condition, they are fixed in our proposal while some are mandatory and some others optional)=20 Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Fernando Calabria (fcalabri) Sent: Tuesday, April 13, 2010 11:21 AM To: Fernando Calabria (fcalabri); bmwg@ietf.org Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 Scott, while we sympathize with your request, it is beyond the scope of the current draft / work=20 Rgds=20 Fernando Calabria -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Scott Poretsky Sent: Thursday, April 08, 2010 5:22 PM To: Al Morton; bmwg@ietf.org Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03 I would be much more interested to have a work item to measure the conditions that cause a networking device's software to reset. Scott -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Al Morton Sent: Thursday, April 08, 2010 5:07 PM To: bmwg@ietf.org Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03 BMWG, At our IETF-77 session, there was support to adopt the subject draft (but few readers present at the meeting). We received advice (from AD-Advisor Ron) that BMWG could add this work item under our current charter. Therefore, we are raising the question again on the list: Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03 as a chartered work item? Please *read* and express your opinion on whether or not this Internet-Draft should be adopted as an Informational RFC. Send your comments to this list or acmorton@att.com by April 26th, at 5PM US EDT, 2200 GMT. Al bmwg chair At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote: >Content-Type: multipart/related; > type=3D"multipart/alternative"; > boundary=3D"----_=3D_NextPart_001_01CAB185.558EF827" >Content-class: urn:content-classes:message > >Hello WG > >We just submitted a new revision of the draft-asati-bmwg-reset , so=20 >far we incorporated all the comments and feedback received by you,=20 >so please take some time "if possible" to go over the document a and=20 >let us know your thoughts and why not any questions and or concerns=20 >you may have > > >Kind Regards > >Fernando Calabria & Authors > _______________________________________________ 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 From dromasca@avaya.com Thu Apr 15 00:20:34 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6A13A6B5C for ; Thu, 15 Apr 2010 00:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja7LUlV5g-Ls for ; Thu, 15 Apr 2010 00:20:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A374E3A6B74 for ; Thu, 15 Apr 2010 00:19:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="184418012" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Apr 2010 03:19:32 -0400 X-IronPort-AV: E=Sophos;i="4.52,211,1270440000"; d="scan'208";a="464784118" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Apr 2010 03:19:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 09:19:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal Thread-Index: AcrbFQm5yYR2l+ViRIuv+j3BMnzbwwAAPbRAABhEkfAAPSQ+QA== References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> <201004131424.o3DEON7K030394@alpd052.aldc.att.com> From: "Romascanu, Dan (Dan)" To: "Eric Gray" , "Al Morton" Cc: bmwg@ietf.org Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 07:20:34 -0000 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com]=20 > Never-the-less, it is probably best to include a list=20 > of the RFCs referred to in the text Al proposes - especially=20 > if it is (as I believe) just these two RFCs. This would be my preference too. It's good to be clear, especially when communication with another organization whose participants are not that familiar with the BMWG core work.=20 Dan =20 From dnewman@networktest.com Thu Apr 15 09:17:04 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA9E3A6A27 for ; Thu, 15 Apr 2010 09:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYTgH5Tz0dxF for ; Thu, 15 Apr 2010 09:17:03 -0700 (PDT) Received: from mail3.networktest.com (mail3.networktest.com [69.55.234.60]) by core3.amsl.com (Postfix) with ESMTP id AD4A83A693F for ; Thu, 15 Apr 2010 09:17:03 -0700 (PDT) Received: from localhost (localhost [69.55.234.60]) by mail3.networktest.com (Postfix) with ESMTP id 3340A95960; Thu, 15 Apr 2010 09:16:56 -0700 (PDT) Received: from mail3.networktest.com ([69.55.234.60]) by localhost (mail3.networktest.com [69.55.234.60]) (amavisd-maia, port 10024) with ESMTP id 55583-01; Thu, 15 Apr 2010 09:16:56 -0700 (PDT) Received: from mail.networktest.com (localhost [69.55.234.60]) by mail3.networktest.com (Postfix) with ESMTP id 8D9029590D; Thu, 15 Apr 2010 09:16:55 -0700 (PDT) Received: from 66.129.224.36 (SquirrelMail authenticated user dnewman@networktest.com) by mail.networktest.com with HTTP; Thu, 15 Apr 2010 09:16:55 -0700 Message-ID: <6b1faf96685fa85e7bdb9eb4d45fd57e.squirrel@mail.networktest.com> In-Reply-To: References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> <201004131424.o3DEON7K030394@alpd052.aldc.att.com> Date: Thu, 15 Apr 2010 09:16:55 -0700 From: dnewman@networktest.com To: "Romascanu, Dan (Dan)" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Al Morton , bmwg@ietf.org, Eric Gray Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:17:04 -0000 >> Never-the-less, it is probably best to include a list >> of the RFCs referred to in the text Al proposes - especially >> if it is (as I believe) just these two RFCs. > > This would be my preference too. It's good to be clear, especially when > communication with another organization whose participants are not that > familiar with the BMWG core work. OK. The throughput definition in 1242 -- the one we're saying is not meaningful for DCB devices -- gets referenced in quite a lot of bmwg work. RFC1242-style throughput is a significant metric in at least these RFCs, and possibly others: 1242 2285 2432 2544 2889 3511 3918 And the tests proposed in this ID use concepts discussed in: 1242 2285 2544 2889 4689 dn From acmorton@att.com Thu Apr 15 09:50:13 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27AE3A683B for ; Thu, 15 Apr 2010 09:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.382 X-Spam-Level: X-Spam-Status: No, score=-105.382 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7OVfYheD7bm for ; Thu, 15 Apr 2010 09:50:12 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id DB14E3A6A40 for ; Thu, 15 Apr 2010 09:50:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-129.messagelabs.com!1271350204!8011165!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 30420 invoked from network); 15 Apr 2010 16:50:04 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Apr 2010 16:50:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3FGoFCp030421 for ; Thu, 15 Apr 2010 12:50:16 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3FGoBFc030327 for ; Thu, 15 Apr 2010 12:50:11 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o3FGnwFx000873 for ; Thu, 15 Apr 2010 12:49:59 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o3FGnrbl000619 for ; Thu, 15 Apr 2010 12:49:54 -0400 Message-Id: <201004151649.o3FGnrbl000619@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-31-223.vpn.west.att.com[135.70.31.223](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100415164950gw100b8iove>; Thu, 15 Apr 2010 16:49:53 +0000 X-Originating-IP: [135.70.31.223] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Apr 2010 12:48:50 -0400 To: dnewman@networktest.com, "Romascanu, Dan (Dan)" From: Al Morton In-Reply-To: <6b1faf96685fa85e7bdb9eb4d45fd57e.squirrel@mail.networktest .com> References: <201004121609.o3CG9FCJ028321@alpd052.aldc.att.com> <201004131424.o3DEON7K030394@alpd052.aldc.att.com> <6b1faf96685fa85e7bdb9eb4d45fd57e.squirrel@mail.networktest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: bmwg@ietf.org, Eric Gray Subject: Re: [bmwg] Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 16:50:13 -0000 Also worth noting, the Title of the Liaison calls-out 2544 and 2889 (both methodologies that depend on terms). I'll try a revised paragraph later today... Al At 12:16 PM 4/15/2010, dnewman@networktest.com wrote: > >> Never-the-less, it is probably best to include a list > >> of the RFCs referred to in the text Al proposes - especially > >> if it is (as I believe) just these two RFCs. > > > > This would be my preference too. It's good to be clear, especially when > > communication with another organization whose participants are not that > > familiar with the BMWG core work. > >OK. The throughput definition in 1242 -- the one we're saying is not >meaningful for DCB devices -- gets referenced in quite a lot of bmwg work. > >RFC1242-style throughput is a significant metric in at least these RFCs, >and possibly others: > >1242 >2285 >2432 >2544 >2889 >3511 >3918 > >And the tests proposed in this ID use concepts discussed in: > >1242 >2285 >2544 >2889 >4689 > >dn From acmorton@att.com Thu Apr 15 12:28:40 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D857E3A67FC for ; Thu, 15 Apr 2010 12:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.434 X-Spam-Level: X-Spam-Status: No, score=-105.434 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evddZblZRFx3 for ; Thu, 15 Apr 2010 12:28:39 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1131728C1CA for ; Thu, 15 Apr 2010 12:28:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1271359705!46749926!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2446 invoked from network); 15 Apr 2010 19:28:26 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Apr 2010 19:28:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3FJSBgi028511 for ; Thu, 15 Apr 2010 15:28:11 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3FJS6Ml028419 for ; Thu, 15 Apr 2010 15:28:06 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3FJSKop026693 for ; Thu, 15 Apr 2010 14:28:20 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3FJSHGM026666 for ; Thu, 15 Apr 2010 14:28:17 -0500 Message-Id: <201004151928.o3FJSHGM026666@klpd017.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-128-210.vpn.mwst.att.com[135.70.128.210](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100415192816gw100b8iq7e>; Thu, 15 Apr 2010 19:28:17 +0000 X-Originating-IP: [135.70.128.210] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Apr 2010 15:26:21 -0400 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dan Romascanu , Eric Gray Subject: [bmwg] 2nd Draft Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 19:28:40 -0000 BMWG, Below is the 2nd draft Liaison to IEEE 802.1 describing the proposal to update RFCs 2544 and 2889 to address the Per-Flow Control capabilities of IEEE 802.1Qbb. Thanks to David Newman and Eric Gray (IETF Liaison Manager for 802.1) and Dan Romascanu for their research, comments, and suggestions. Remaining comments by April 26, 2010, on the bmwg-list, please. Al bmwg chair --------------------------------------------------------------- To: IEEE 802.1 Tony Jeffrey, WG Chair tony@jeffree.co.uk and Pat Thaler, DCB TG Chair pthaler@broadcom.com From: IETF-BMWG Al Morton, WG Chair acmorton@att.com For Action/Comment Deadline: August 1, 2010 Title: Proposal to update RFCs 2544 and 2889 to address the Per-Flow Control capabilities of IEEE 802.1Qbb The purpose of this Liaison is to inform you of a new work proposal in the Benchmarking Methodology Working Group (BMWG) of the IETF, and seek your comments. BMWG is considering adding a charter work item to update several of our foundation RFCs, described in detail in the memo by D.Newman and T.Player: http://tools.ietf.org/html/draft-player-dcb-benchmarking-01 In this proposal, there is an intersection between IETF benchmarking practice and new IEEE standardization work. Benchmarks for Ethernet switch performance based on RFCs 1242, 2285, 2544 and 2889 (these represent BMWG's foundation RFCs that are referenced frequently in our work) are recognized as industry standards. The terminology and methodology described in these memos have been in widespread use by test equipment vendors, networking device manufacturers, enterprises and service providers for more than a decade. Some key concepts from our 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. There are related cases where other existing metrics can be extended or replaced. See the list of affected RFCs attached below. The Internet-Draft seeks to recognize the importance of these new IEEE specifications in the context of data center switch benchmarking. The draft seeks to extend rather than replace existing industry standard practices for benchmarking switch performance characteristics in the lab, and it does so by defining new terms and metrics relevant to recent IEEE work on data center bridging. The charter of BMWG strictly limits our work to laboratory characterization. Therefore, live network performance testing, manageability, MIB module development, and other operational/functional testing are beyond our scope. http://www.ietf.org/dyn/wg/charter/bmwg-charter Before considering this work proposal further, we seek your comments on: - whether there is overlapping work planned in 802.1 - whether a liaison relationship (between the BMWG and IEEE 802.1 WG) could be beneficial to complete this work - the proposal details, as currently described sincerely, Al Morton bmwg chair ------------------------------------------------------------------------- RFC1242-style throughput is a significant metric in at least these RFCs, and possibly others: 1242 2285 2432 2544 2889 3511 3918 And the tests described in the new DCB proposal Internet-Draft use concepts discussed in: 1242 2285 2544 2889 4689 --------------------------------------------------------------------------- From rbonica@juniper.net Sat Apr 24 14:39:29 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D843A691D for ; Sat, 24 Apr 2010 14:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnhIKgfVUCzK for ; Sat, 24 Apr 2010 14:39:28 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2A11E3A6800 for ; Sat, 24 Apr 2010 14:39:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS9NlBKWTsoJxO4v+BSleED1GP0uiLNPi@postini.com; Sat, 24 Apr 2010 14:39:17 PDT Received: from P-EMHUB01-HQ.jnpr.net (172.24.192.35) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sat, 24 Apr 2010 12:29:24 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sat, 24 Apr 2010 10:48:08 -0700 Received: from [172.28.134.28] (172.28.134.28) by p-emfe02-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server id 8.1.436.0; Sat, 24 Apr 2010 13:48:08 -0400 Message-ID: <4BD32ED7.2000004@juniper.net> Date: Sat, 24 Apr 2010 13:48:07 -0400 From: Ron Bonica User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "bmwg@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [bmwg] protection terminology draft X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 21:39:29 -0000 Al, I have reviewed the protection terminology draft and have only one concern. The draft defines many terms that are in the domain of the CCAMP and MPLS WGs. I think that it would be prudent to ask for some kind of review from those WGs. Please contact the CCAMP and MPLS chairs and agree on what kind of cross area review is required. Once that review has occurred, I will be happy to progress the draft. Ron From acmorton@att.com Thu Apr 29 12:21:43 2010 Return-Path: X-Original-To: bmwg@core3.amsl.com Delivered-To: bmwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821ED3A6B79 for ; Thu, 29 Apr 2010 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ-auW99bJTF for ; Thu, 29 Apr 2010 12:21:41 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id D9CD028C1F3 for ; Thu, 29 Apr 2010 12:21:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1272568870!22787613!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31160 invoked from network); 29 Apr 2010 19:21:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Apr 2010 19:21:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3TJKsCk006108 for ; Thu, 29 Apr 2010 15:20:55 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3TJKpmw006054 for ; Thu, 29 Apr 2010 15:20:51 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3TJL6Nq003323 for ; Thu, 29 Apr 2010 14:21:06 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o3TJL5ow003304 for ; Thu, 29 Apr 2010 14:21:06 -0500 Message-Id: <201004291921.o3TJL5ow003304@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100429192105gw100b8ibqe>; Thu, 29 Apr 2010 19:21:05 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Apr 2010 15:19:31 -0400 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [bmwg] Fwd: Liaison to IEEE 802.1 on DCB proposal X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 19:21:43 -0000 FYI - the liaison statement to IEEE 802.1 went out today. >Date: Thu, 29 Apr 2010 12:23:09 -0400 >To: tony@jeffree.co.uk, pthaler@broadcom.com >From: Al Morton >Subject: Liaison to IEEE 802.1 on DCB proposal >Cc: Eric Gray , Ron Bonica >, "Dan Romascanu" , >ietf-secretariat@ietf.org > > >--------------------------------------------------------------- >To: IEEE 802.1 > Tony Jeffrey, WG Chair >and Pat Thaler, DCB TG Chair > >From: IETF Benchmarking Methodology Working Group (BMWG) >CC: Ron Bonica, OPS Area Director, BMWG Advisor, > Dan Romascanu, OPS Area Director, > Eric Gray, IETF Liaison Manager for IEEE 802.1, > IETF Secretariat, > >Response Contacts: Al Morton, BMWG Chair, > and >Technical Contact: > >Title: Proposal to update RFCs 2544 and 2889 to address the > Per-Flow Control capabilities of IEEE 802.1Qbb > >Purpose: For Action/Comment >The purpose of this Liaison is to inform you of a new work proposal >in the Benchmarking Methodology Working Group (BMWG) of the IETF, >and seek your comments. > >Deadline: August 1, 2010 > >--------------------------------------------------------------- > >BMWG is considering adding a charter work item to update several of our >foundation RFCs, described in detail in the memo by D.Newman and T.Player: >http://tools.ietf.org/html/draft-player-dcb-benchmarking-01 >In this proposal, there is an intersection between IETF benchmarking >practice and new IEEE standardization work. > >Benchmarks for Ethernet switch performance based on RFCs 1242, 2285, >2544 and 2889 (these represent BMWG's foundation RFCs that are referenced >frequently in our work) are recognized as industry standards. The >terminology and methodology described in these memos have been in >widespread use by test equipment vendors, networking device manufacturers, >enterprises and service providers for more than a decade. > >Some key concepts from our 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. >There are related cases where other existing metrics can be extended >or replaced. See the list of affected RFCs attached below. > >The Internet-Draft seeks to recognize the importance of these new IEEE >specifications in the context of data center switch benchmarking. >The draft seeks to extend rather than replace existing >industry standard practices for benchmarking switch performance >characteristics in the lab, and it does so by defining new terms >and metrics relevant to recent IEEE work on data center bridging. > >The charter of BMWG strictly limits our work to laboratory characterization. >Therefore, live network performance testing, manageability, MIB module >development, and other operational/functional testing are beyond our scope. >http://www.ietf.org/dyn/wg/charter/bmwg-charter > >Before considering this work proposal further, we seek your comments on: > - whether there is overlapping work planned in 802.1 > - whether a liaison relationship (between the BMWG and IEEE 802.1 WG) > could be beneficial to complete this work > - the proposal details, as currently described > >sincerely, >Al Morton >bmwg chair > >------------------------------------------------------------------------- > >RFC1242-style throughput is a significant metric in at least these RFCs, >and possibly others: > >1242 >2285 >2432 >2544 >2889 >3511 >3918 > >And the tests described in the new DCB proposal Internet-Draft >use concepts discussed in: > >1242 >2285 >2544 >2889 >4689 > >--------------------------------------------------------------------------- From wwwrun@core3.amsl.com Fri Apr 30 10:08:03 2010 Return-Path: X-Original-To: bmwg@ietf.org Delivered-To: bmwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 04D983A6AD4; Fri, 30 Apr 2010 10:07:59 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100430170800.04D983A6AD4@core3.amsl.com> Date: Fri, 30 Apr 2010 10:07:55 -0700 (PDT) Cc: bmwg@ietf.org Subject: [bmwg] Last Call: draft-ietf-bmwg-protection-term (Benchmarking Terminology for Protection Perfor) to Informational RFC X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 17:08:06 -0000 The IESG has received a request from the Benchmarking Methodology WG (bmwg) to consider the following document: - 'Benchmarking Terminology for Protection Performance ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-bmwg-protection-term-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15276&rfc_flag=0