From bmwg-bounces@ietf.org Tue Jan 03 11:02:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etobw-0001pN-Hs; Tue, 03 Jan 2006 11:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etobu-0001oO-SH for bmwg@megatron.ietf.org; Tue, 03 Jan 2006 11:02:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14088 for ; Tue, 3 Jan 2006 11:00:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtohB-0008TU-Sd for bmwg@ietf.org; Tue, 03 Jan 2006 11:07:36 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2006 08:00:46 -0800 X-IronPort-AV: i="3.99,326,1131350400"; d="scan'208,217"; a="246481721:sNHT2380018284" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k03G0aZ6013081; Tue, 3 Jan 2006 08:00:46 -0800 (PST) Received: from xmb-rtp-214.amer.cisco.com ([64.102.31.75]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 11:00:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jan 2006 11:00:20 -0500 Message-ID: Thread-Topic: draft-vapiwala-bmwg-frr-failover-meth-00.txt Thread-Index: AcYQfswTup7d5h4bThWxu278UwTXYg== From: "Samir Vapiwala \(svapiwal\)" To: X-OriginalArrivalTime: 03 Jan 2006 16:00:21.0824 (UTC) FILETIME=[CD055400:01C6107E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Rajiv Papneja Subject: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258548083==" Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1258548083== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6107E.CAEE9B75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6107E.CAEE9B75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI =20 Please send your comments on new draft =20 http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-frr-failover-met h-00.txt =20 Thanks Samir Vapiwala, Rajiv Papneja , Jay Karthik =20 ------_=_NextPart_001_01C6107E.CAEE9B75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

Please send your comments on new=20 draft

http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-= frr-failover-meth-00.txt

Thanks

Samir=20 Vapiwala, Rajiv Papneja , Jay Karthik

------_=_NextPart_001_01C6107E.CAEE9B75-- --===============1258548083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg --===============1258548083==-- From bmwg-bounces@ietf.org Fri Jan 06 09:26:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EusYL-0002T2-0v; Fri, 06 Jan 2006 09:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EusYJ-0002My-Og for bmwg@megatron.ietf.org; Fri, 06 Jan 2006 09:26:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04671 for ; Fri, 6 Jan 2006 09:25:31 -0500 (EST) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuseA-0003Go-SN for bmwg@ietf.org; Fri, 06 Jan 2006 09:32:54 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1136557593!7584398!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30940 invoked from network); 6 Jan 2006 14:26:34 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 6 Jan 2006 14:26:34 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060106142633gw100lgggte>; Fri, 6 Jan 2006 14:26:33 +0000 Message-Id: <6.2.1.2.0.20060106091950.0405f6d0@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 06 Jan 2006 09:26:33 -0500 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [bmwg] WG Last Call on Address Hash and Bit Stuffing Draft (04) X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org BMWG: A WG Last Call period for the Internet-Draft on "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking" will be open from 6 Jan 2006 through 3 Feb 2006. A URL for this Internet-Draft is: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-hash-stuffing-04.txt Version 04 (and version 03) incorporates minor changes (change logs have been published on the mailing list). The authors believe that all comments from the working group have been addressed, dating back to July 2004 when version 00 was published. This draft is entering the BMWG Last Call Process. See http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html At this time, we are seeking volunteers to complete the BMWG Last Call Review Template in the message of 4/27/04 titled, "Refinements to the BMWG Last Call Process". Volunteers should contact acmorton@att.com and kdubray@juniper.net A copy of the template is available here: http://home.comcast.net/~acmacm/IDcheck/LastCallTemplate.txt Whether or not you decide to volunteer for the directed review, please *read* and express your opinion on whether or not this Internet-Draft should be given to the Area Directors for consideration as an Informational RFC. Send your comments to this list or acmorton@att.com and kdubray@juniper.net Kevin, Al BMWG Co-Chairs _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Fri Jan 06 18:50:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1LU-0004Rq-Gm; Fri, 06 Jan 2006 18:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1LO-0004La-KZ; Fri, 06 Jan 2006 18:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23051; Fri, 6 Jan 2006 18:48:46 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev1RN-0006a6-GF; Fri, 06 Jan 2006 18:56:13 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ev1LN-0003i1-Je; Fri, 06 Jan 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jan 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-app-09.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Considerations for Benchmarking IGP Data Plane Route Convergence Author(s) : S. Poretsky Filename : draft-ietf-bmwg-igp-dataplane-conv-app-09.txt Pages : 6 Date : 2006-1-6 This document provides considerations for IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence benchmarking terminology [2]. The methodology and terminology are to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-igp-dataplane-conv-app-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-6161645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-igp-dataplane-conv-app-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-6161645.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg --NextPart-- From bmwg-bounces@ietf.org Fri Jan 06 18:50:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1LY-0004UO-Iu; Fri, 06 Jan 2006 18:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1LO-0004Lp-V4; Fri, 06 Jan 2006 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23059; Fri, 6 Jan 2006 18:48:47 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev1RN-0006a8-HO; Fri, 06 Jan 2006 18:56:13 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ev1LN-0003i6-Kf; Fri, 06 Jan 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jan 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-term-09.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Terminology for Benchmarking IGP Data Plane Route Convergence Author(s) : B. Imhoff, S. Poretsky Filename : draft-ietf-bmwg-igp-dataplane-conv-term-09.txt Pages : 15 Date : 2006-1-6 This document describes the terminology for benchmarking IGP Route Convergence as described in Applicability document [1] and Methodology document [2]. The methodology and terminology are to be used for benchmarking Convergence Time and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-igp-dataplane-conv-term-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-6162332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-igp-dataplane-conv-term-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-6162332.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg --NextPart-- From bmwg-bounces@ietf.org Fri Jan 06 18:50:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1Ld-0004WN-So; Fri, 06 Jan 2006 18:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1LQ-0004Mt-GB; Fri, 06 Jan 2006 18:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23056; Fri, 6 Jan 2006 18:48:46 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev1RN-0006aA-Ib; Fri, 06 Jan 2006 18:56:14 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ev1LN-0003iB-Lh; Fri, 06 Jan 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jan 2006 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Methodology for IGP Data Plane Route Convergence Author(s) : S. Poretsky, B. Imhoff Filename : draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt Pages : 15 Date : 2006-1-6 This dpcument describes the methodology for benchmarking IGP Route Convergence as described in Applicability document [1] and Terminology document [2]. The methodology and terminology are to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The terms used in the procedures provided within this document are defined in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-6162534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-6162534.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg --NextPart-- From bmwg-bounces@ietf.org Wed Jan 25 14:20:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qCO-0003nc-4G; Wed, 25 Jan 2006 14:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qCJ-0003nC-Sm for bmwg@megatron.ietf.org; Wed, 25 Jan 2006 14:20:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15184 for ; Wed, 25 Jan 2006 14:19:19 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1qLz-0006N0-IE for bmwg@ietf.org; Wed, 25 Jan 2006 14:30:59 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-10.tower-126.messagelabs.com!1138215525!8889724!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11760 invoked from network); 25 Jan 2006 18:58:55 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-10.tower-126.messagelabs.com with SMTP; 25 Jan 2006 18:58:55 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060125164023gw100100ube>; Wed, 25 Jan 2006 16:40:23 +0000 Message-Id: <6.2.1.2.0.20060125093405.03c4aa48@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 25 Jan 2006 11:40:22 -0500 To: bmwg@ietf.org, David Newman , timmons.player@spirentcom.com From: Al Morton Subject: FW: [bmwg] WG Last Call on Address Hash and Bit Stuffing Draft (04) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: lencia@att.com, Kevin Dubray X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org Hi David and Timmons, A few comments on the 04 version (as a WG participant). Also, I've attached a few comments from one of my colleagues, Len Ciavattone. hth, Al In: >4.1. Problem Statement > > The addresses and port numbers used in a test can have a significant > impact on metrics such as throughput, jitter, latency, and loss. > This is because many network devices feed such addresses into hashing > algorithms to determine which path upon which to forward a given > packet. ... (last paragraph) > The balance of this section offers recommendations for test traffic > patterns, starting at the link layer and working up to the transport > layer. These patterns should overcome the effects of nonrandomness > regardless of the hashing algorithms in use. I thought that a clear(er) statement of the objective of section 4 might be useful to have here (and agree on). So I suggest words to that affect, something like: (last paragraph) Therefore, this memo adds a new consideration for (all?) benchmarking methodologies, to select address patterns that overcome the effects of non-randomness regardless of the hashing algorithms in use. The balance of this section offers recommendations for test traffic patterns to avoid these effects, starting at the link layer and working up to the transport layer. In 4.2.1, last paragraph: > When generating traffic with multiple addresses, it is RECOMMENDED > that all addresses use pseudorandom values. There are multiple ways > to use sets of pseudorandom numbers. One strategy would be for the > test instrument to iterate over an array of pseudorandom values > rather than incrementing/decrementing from a starting address. The > actual method is an implementation detail; in the end, any method > that uses multiple addresses and avoids hash table collisions will be > sufficient. So, it's good to peek inside the black box? Or is there another way to ensure that the tester has successfully avoided any affects of using address patterns that are not quite as random as those encountered in the real world? Maybe restate the last sentence something like: ... The actual method is an implementation detail; in the end, any method that uses multiple addresses and avoids the undesired effects of address processing in the Device Under Test will be sufficient. >4.4. Network-layer Addressing > > Routers make forwarding decisions based on destination network > address. Since there is no hashing of source and destination > addresses, the requirement for pseudorandom patterns at the network > layer is far less critical than in the Ethernet MAC address case. The "no hashing" sentence appears a bit too strong, see the info Len provided in response to this section, below. If it's acceptable to mention the possible need for Network Layer Address randomization, then should also mention the special addresses and ranges to avoid, as in the other sections. 5.2 PPP Bit Stuffing Len has a comment on the first few paragraphs, below. Also, it seems possible that the "Type of Service" field (now the combination of DSCP and ECN bits) has the potential to produce five 1's in a row. None of the currently assigned DSCPs/CSs fit the bill, but a precedence of 7 or 3 and the necessary number of set ToS bits can make five 1's. A few small clarifications in Section 5.2.1: because the table is asymmetrical, suggest labeling the header \From| \ | start 1 2 3 4 5 \ | To \ | _____\|_________________________________________________ start | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 1 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0 | 0.5 2 | 0.0 | 0.5 | 0.0 | 0.0 | 0.0 | 0.0 3 | 0.0 | 0.0 | 0.5 | 0.0 | 0.0 | 0.0 4 | 0.0 | 0.0 | 0.0 | 0.5 | 0.0 | 0.0 5 | 0.0 | 0.0 | 0.0 | 0.0 | 0.5 | 0.0 last paragraph, because P(stuff) is used later, suggest defining it here: Thus, for an infinitely long string of random bits, the probability of 5 sequential 1 bits is P(stuff) = P(5 sequential 1 bits) = 1/62. Put another way, we expect to add one stuff bit for every 62 bits of random uniform data. In >5.2.2. Bit Stuffing for Finite Strings > > The above result indicates that for any string of uniformly > distributed random bits, we expect a stuffing event to occur every 62 > bits. So, given a ... suggest the following clarification: 5.2.2. Bit Stuffing for Finite Strings The above result indicates that for any string of uniformly distributed random bits, we expect a stuffing event to occur every 62 bits on average. So, given a ... Len's comments follow: >Subject: FW: [bmwg] WG Last Call on Address Hash and Bit Stuffing Draft (04) >Date: Wed, 25 Jan 2006 07:27:27 -0600 >X-MS-Has-Attach: >X-MS-TNEF-Correlator: >Thread-Topic: [bmwg] WG Last Call on Address Hash and Bit Stuffing Draft (04) >Thread-Index: AcYeCJWUvpEG4GS+SGiHldtLntHmMACGxJpgAE24S/AAFg8moA== >From: >To: > >Al, >I put together a few comments... > >Section 4.4, 4.5 >------------------- >Vendors that support link bundling or composite links (logical links >formed >from several physical links) also use network-layer addresses and >potentially transport-layer port numbers to assign flows to individual >members. This same flow-based methodology is also used in at least one >vendor's core router to assign packets to different paths through the >internal switch fabric. > >Also, with regard to address hashing, the entire source and destination >address are not always used. The specific implementations may only >utilize >certain bits in them (to favor one over the other). > > >Section 5.2 >------------------- >It quotes section 5.2 of RFC1662 as stating that a "0" is inserted prior >to >a sequence of 5 contiguous "1" bits. It then says that this is to avoid >the >"HDLC control character 0x7D, which contains six "1" bits". In the next >paragraph it says "Not shown is the 1-byte flag sequence (0x7D)". > >Well, in 5.2 of RFC1662 it actually states that a "0" is inserted AFTER >all >sequences of 5 contiguous "1" bits. Also, this is done to deal with the >HDLC >flag sequence which is 0x7E (01111110) - six "1" bits. There is no >reference >to 0x7D under "Bit-stuffed framing" (which is for bit-synchronous links) >in >section 5 of that RFC. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Fri Jan 27 09:10:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UJD-0005Rx-Tj; Fri, 27 Jan 2006 09:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Hgw-0003lw-RR for bmwg@megatron.ietf.org; Thu, 26 Jan 2006 19:42:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21655 for ; Thu, 26 Jan 2006 19:40:46 -0500 (EST) Received: from mail.veriwave.com ([64.1.198.186] helo=cia.veriwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Hqw-0000LH-Te for bmwg@ietf.org; Thu, 26 Jan 2006 19:52:42 -0500 Received: from jperserlaptop (jperser_laptop.veriwave.com [10.120.1.195]) (authenticated bits=0) by cia.veriwave.com (8.12.8/8.12.8) with ESMTP id k0R0fwYH000420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Jan 2006 16:42:00 -0800 Message-Id: <200601270042.k0R0fwYH000420@cia.veriwave.com> From: "Jerry Perser" To: Date: Thu, 26 Jan 2006 16:41:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcYi2nmd94D/asxkQSG+tAOAlcsCXA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Jan 2006 09:10:36 -0500 Subject: [bmwg] Question on 'Address Hash and Bit Stuffing Draft(04)' X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org David, Section 4.2 Ethernet MAC Addresses, I assume that this applies to both 802.3 and 802.11 standards. My question is how to handle 802.11 MAC addresses and the fact that wireless clients can roam to different interfaces? If my clients are stationary and do not hop between Access Points, I can map the MAC address to an interface number of the test instrument. In making an 802.11 roaming measurement, the client needs to have a single MAC address, but will reside on 2 or more ports. Would using the original interface number of the test instrument suffice? Curious to know since I am in the process of testing such a beast. Jerry Perser. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Fri Jan 27 11:50:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Wna-0001AQ-Sz; Fri, 27 Jan 2006 11:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WnY-0001AD-Fz for bmwg@megatron.ietf.org; Fri, 27 Jan 2006 11:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25522 for ; Fri, 27 Jan 2006 11:48:35 -0500 (EST) Received: from ns.networktest.com ([64.239.163.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Wxj-0005vI-F5 for bmwg@ietf.org; Fri, 27 Jan 2006 12:00:40 -0500 Received: by ns.networktest.com (Postfix, from userid 1020) id 14F88171BB; Fri, 27 Jan 2006 08:49:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on saronni.int.networktest.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [192.168.1.2] (agoura-cuda2-gen2-68-66-238-223.ventca.adelphia.net [68.66.238.223]) by ns.networktest.com (Postfix) with ESMTP id 2331F171B9; Fri, 27 Jan 2006 08:49:51 -0800 (PST) Message-ID: <43DA4F2E.403@networktest.com> Date: Fri, 27 Jan 2006 08:49:50 -0800 From: David Newman Organization: Network Test Inc. User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Jerry Perser Subject: Re: [bmwg] Question on 'Address Hash and Bit Stuffing Draft(04)' References: <200601270042.k0R0fwYH000420@cia.veriwave.com> In-Reply-To: <200601270042.k0R0fwYH000420@cia.veriwave.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: bmwg@ietf.org X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org Jerry Perser wrote: > Section 4.2 Ethernet MAC Addresses, I assume that this applies to both 802.3 > and 802.11 standards. My question is how to handle 802.11 MAC addresses and > the fact that wireless clients can roam to different interfaces? > > If my clients are stationary and do not hop between Access Points, I can map > the MAC address to an interface number of the test instrument. > > In making an 802.11 roaming measurement, the client needs to have a single > MAC address, but will reside on 2 or more ports. Would using the original > interface number of the test instrument suffice? Good question. The goal of the "PP:PP" designation is to provide a trackable ID that doesn't change during the test. This makes troubleshooting easier by embedding the port number in every packet. Since the (wired or wireless) test instrument's interface number remains static, we believe the interface number of the test instrument would suffice in this case. We can add language in noting that: a) PP:PP refers to the port number of both the DUT/SUT and the test instrument except in cases where the DUT/SUT's port ID may change; and b) in such cases, PP:PP refers to the port number of the test instrument. We hesitate to say simply that PP:PP refers to the test instrument interface alone because, at least in our experience, testers of DUT/SUTs generally are oriented toward the DUT/SUT and not the test instrument as the "center of the universe." This proposed fix would address cases where that center shifts, such as in wireless technologies involving roaming. dn/tcp _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Mon Jan 30 11:23:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3boT-0006Fq-Ek; Mon, 30 Jan 2006 11:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3boO-0006Eb-Oc for bmwg@megatron.ietf.org; Mon, 30 Jan 2006 11:23:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB04601 for ; Mon, 30 Jan 2006 11:21:46 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3bz3-0000gZ-Fz for bmwg@ietf.org; Mon, 30 Jan 2006 11:34:30 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 30 Jan 2006 08:23:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,234,1136188800"; d="scan'208"; a="524516243:sNHT21284652" Received: from [172.28.13.57] ([172.28.13.57]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 08:23:09 -0800 Message-ID: <43DE3D87.9000309@juniper.net> Date: Mon, 30 Jan 2006 11:23:35 -0500 From: Kevin Dubray User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2006 16:23:09.0283 (UTC) FILETIME=[753E4330:01C625B9] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: bwijnen@lucent.com Subject: [bmwg] [Fwd: Proposed removal from BMWG milestone: FIB methodology] X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org Colleagues: Per the BMWG session in Vancouver, the FIB Methodology is proposed to be removed from the WG's milestones. See the proceedings for the minutes of the BMWG session at IETF 64 for more detail. http://www.ietf.org/proceedings/05nov/bmwg.html#cmr Objections or support for this action should be posted to this list or the chairs no later than 6 February. Thanks, Al/Kevin _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Mon Jan 30 11:25:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3bqn-0006eH-V3; Mon, 30 Jan 2006 11:25:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3bkW-0005kB-93 for bmwg@megatron.ietf.org; Mon, 30 Jan 2006 11:19:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04306 for ; Mon, 30 Jan 2006 11:17:45 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3bvA-0000YC-FO for bmwg@ietf.org; Mon, 30 Jan 2006 11:30:29 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 30 Jan 2006 08:19:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,234,1136188800"; d="scan'208"; a="526367197:sNHT24520298" Received: from [172.28.13.57] ([172.28.13.57]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 08:18:46 -0800 Message-ID: <43DE3C80.80800@juniper.net> Date: Mon, 30 Jan 2006 11:19:12 -0500 From: Kevin Dubray User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2006 16:18:46.0837 (UTC) FILETIME=[D8D02E50:01C625B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [bmwg] Review of hash-stuffing-04.txt X-BeenThere: bmwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Benchmarking Methodology Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bmwg-bounces@ietf.org Errors-To: bmwg-bounces@ietf.org I have received review input of the referenced I-D by Robert Craig of Juniper. More detailed information was delivered directly to the WG chairs and the editors. Based on the review template, the reviewer expresses that: the document is a useful benchmarking submission; that IPv4 techniques can be extended to IPv6. The reviewer indicates that he been incorporating several techniques proposed in the I-D for years - he appreciates the formalization. Technically, he feels the I-D would be made stronger if it addressed the Test Payload structure: "Missing from the discussion is the 'Test Payload' optionally inserted in the test frames by test equipment. As measurements of any sophistication require the insertion of the test payload (latency, order, ability to distinguish easily test traffic and protocol traffic), most tests use it. The contents of this payload offer additional opportunities for stuffing to occur. Typically, the payload contains a transmission timestamp and/or sequence number, test equipment port identifier and/or "stream" number, and a CRC over the contents of the test payload or test frame." The reviewer would support advancement of the I-D, if the above were better addressed. Lastly, a few editorial nits were pointed out to the principals. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg