From safari@representative.com Sat Mar 04 18:51:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFgX0-00072y-2q for bmwg-archive@lists.ietf.org; Sat, 04 Mar 2006 18:51:26 -0500 Received: from [59.1.160.139] (helo=hpjxrxagohy.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFgWx-0002Ce-Ig for bmwg-archive@lists.ietf.org; Sat, 04 Mar 2006 18:51:26 -0500 Received: from jam by microsoft.com with local (Exim 4.41 (FreeBSD)) id 62-2-8 for jackknife; Sun, 05 Mar 2006 07:01:04 -0500 From: Hunter Greene To: bmwg-archive@lists.ietf.org Subject: Your family Mime-Version: 1.0 X-Mailer: cure Web-Mail 2.19 X-Originating-IP: 192.160.94.181 via proxy [90.135.202.100] Date: Sun, 05 Mar 2006 04:45:06 -0500 Reply-To: Abdul Boyd Message-Id: <0127-3119-57626.elastomer-revival-periwinkle@representative.com> Content-Type: multipart/mixed; boundary="------=271585924820" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 --------=271585924820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit Improved Vision, Speeds injury recovery and helps relieve chronic pain.

Cialis Soft Tabs bestseller.




Viagra Professional bestseller.
Ambien bestseller.


http://au.geocities.com/keelia13592diannne89936/



The man who works for the gold in the job rather than for the money in the pay envelope, is the fellow who gets on. --------=271585924820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you can imagine it, you can achieve it if you can dream it, you can become it.O conscience, upright and stainless, how bitter a sting to thee is a little fault! --------=271585924820-- From bmwg-bounces@ietf.org Mon Mar 06 15:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMlY-0004XX-Da; Mon, 06 Mar 2006 15:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMed-00022F-E3; Mon, 06 Mar 2006 15:50:07 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMed-0001NR-Bf; Mon, 06 Mar 2006 15:50:07 -0500 Received: from [156.154.24.129] (helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGMeY-0002v3-DW; Mon, 06 Mar 2006 15:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko29W019221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeX-00055w-Vx; Mon, 06 Mar 2006 15: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: Mon, 06 Mar 2006 15:50:01 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-ipsec-term-08.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: , 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 IPsec Devices Author(s) : M. Bustos, et al. Filename : draft-ietf-bmwg-ipsec-term-08.txt Pages : 57 Date : 2006-3-6 This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-term-08.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-ipsec-term-08.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-ipsec-term-08.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-3-6104912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ipsec-term-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ipsec-term-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6104912.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 Mon Mar 06 16:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMqS-0001H2-AO; Mon, 06 Mar 2006 16:02:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMeZ-0001tc-03; Mon, 06 Mar 2006 15:50:03 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMeY-0001Lv-Bq; Mon, 06 Mar 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k26Ko2BX024367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMeY-000561-0u; Mon, 06 Mar 2006 15:50:02 -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: Mon, 06 Mar 2006 15:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-ipsec-meth-01.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: , 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 : Methodology for Benchmarking IPsec Devices Author(s) : M. Kaeo, T. Van Herck Filename : draft-ietf-bmwg-ipsec-meth-01.txt Pages : 40 Date : 2006-3-6 The purpose of this draft is to describe methodology specific to the benchmarking of IPsec IP forwarding devices. It builds upon the tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-meth-01.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-ipsec-meth-01.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-ipsec-meth-01.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-3-6105131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ipsec-meth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ipsec-meth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-6105131.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 Tue Mar 07 16:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjEY-0001PW-2Q; Tue, 07 Mar 2006 15:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGj87-0000rS-V4; Tue, 07 Mar 2006 15:50:04 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGj86-00022z-T0; Tue, 07 Mar 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k27Ko20e024726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGj86-0001C2-BA; Tue, 07 Mar 2006 15:50:02 -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: Tue, 07 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-term-10.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: , 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-10.txt Pages : 15 Date : 2006-3-7 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-10.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-10.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-10.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-3-7123757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-igp-dataplane-conv-term-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7123757.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 Tue Mar 07 16:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjpt-0005Ia-2r; Tue, 07 Mar 2006 16:35:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGj88-0000rk-DG; Tue, 07 Mar 2006 15:50:04 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGj87-00023D-Bf; Tue, 07 Mar 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k27Ko29W030637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGj86-0001C7-Bo; Tue, 07 Mar 2006 15:50:02 -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: Tue, 07 Mar 2006 15:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-app-10.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: , 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-10.txt Pages : 6 Date : 2006-3-7 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-10.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-10.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-10.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-3-7125014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-igp-dataplane-conv-app-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7125014.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 Tue Mar 07 16:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGk3p-0003vD-JN; Tue, 07 Mar 2006 16:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGk3n-0003s6-Ho; Tue, 07 Mar 2006 16:49:39 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjFr-0004LN-ON; Tue, 07 Mar 2006 15:58:03 -0500 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGj87-0008VT-64; Tue, 07 Mar 2006 15:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k27Ko29W030638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGj86-0001CC-CW; Tue, 07 Mar 2006 15:50:02 -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: Tue, 07 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-dsmmeth-01.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: , 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 : Methodology for Benchmarking Network-layer Traffic Control Mechanisms Author(s) : S. Poretsky Filename : draft-ietf-bmwg-dsmmeth-01.txt Pages : 9 Date : 2006-3-7 This document describes the methodology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. The methodology is to be applied to measurements made on the data plane to evaluate the performance of the traffic control mechanisms. The methodology permits the specific traffic control mechanisms and configuration commands to vary between DUTs. The methodology uses much of the Terminology defined in [Pp06]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmmeth-01.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-dsmmeth-01.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-dsmmeth-01.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-3-7125343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-dsmmeth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-dsmmeth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7125343.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 Thu Mar 09 16:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSPJ-0005RC-P4; Thu, 09 Mar 2006 16:10:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS5J-00015D-K7; Thu, 09 Mar 2006 15:50:09 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS5J-0007FI-Hu; Thu, 09 Mar 2006 15:50:09 -0500 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHS5D-0005R2-3c; Thu, 09 Mar 2006 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko2BX027065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5C-00008V-PK; Thu, 09 Mar 2006 15:50:02 -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: Thu, 09 Mar 2006 15:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bmwg@ietf.org Subject: [bmwg] I-D ACTION:draft-ietf-bmwg-acc-bench-term-08.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: , 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 Accelerated Stress Benchmarking Author(s) : S. Poretsky, S. Rao Filename : draft-ietf-bmwg-acc-bench-term-08.txt Pages : 26 Date : 2006-3-9 This document provides the Terminology for performing Stress Benchmarking of networking devices. The three phases of the Stress Test: Startup, Instability and Recovery are defined along with the benchmarks and configuration terms associated with the each phase. Also defined are the Benchmark Planes fundamental to stress testing configuration, setup and measurement. The terminology is to be used with the companion framework and methodology documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-acc-bench-term-08.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-acc-bench-term-08.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-acc-bench-term-08.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-3-9133448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-acc-bench-term-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-acc-bench-term-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9133448.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 Tue Mar 14 20:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJKSh-00049h-Ho; Tue, 14 Mar 2006 20:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJKSg-00045r-B8 for bmwg@ietf.org; Tue, 14 Mar 2006 20:06:02 -0500 Received: from mail.veriwave.com ([64.1.198.186] helo=cia.veriwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJKSe-0004Fo-MQ for bmwg@ietf.org; Tue, 14 Mar 2006 20:06:02 -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 k2F15qYH016047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Mar 2006 17:05:57 -0800 Message-Id: <200603150105.k2F15qYH016047@cia.veriwave.com> From: "Jerry Perser" To: Date: Tue, 14 Mar 2006 17:05:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcZHzJwMPy0+8z5HS2yj9rchkRz3zA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [bmwg] Implemeation notes from draft-ietf-bmwg-hash-stuffing-05.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: , Errors-To: bmwg-bounces@ietf.org I am not going to be able to make the next IETF meeting in March, so I thought I share my experiences with implementing draft-ietf-bmwg-hash-stuffing-05. These are thing that I experienced = and should in no way be construed as displeasure of the drafts last call = status. In fact, version 04 was good enough to implement on. 1. Used (RR & 0xFC) instead of (RR & 0xFE) for the MAC addresses first Octet. I do not know the impact of mixing GLOBALLY ADMINISTERED ADDRESS = and LOCALLY ADMINISTERED ADDRESS in the same test. No completely sure if = it's still used. The IEEE 802.3 standard gives no information on the use or issues. I decide to play it safe and only allow GLOBALLY ADMINISTERED ADDRESS. 2. The PP:PP 1-indexed interface number referred to the first interface = that frames are transmitted from. I am dealing with clients that move from = one interface to another (test of wireless LAN roaming). In a list of = possible interfaces, the MAC address refers to the first interface that sees = frames. This complies with the draft. I just wanted to be clear in my implementation. 3. Pseudorandom number runs the risk of repeating during a test. The = odds are 16 million to 1 (roughly), but with my luck it will happen in = February in New England during a test, and I will have to go there. I have implemented some crude code to filter out repeats. Looking for = something better that keeping a table of used addresses. 4. Pseudorandomness is playing havoc with some security devices. I am currently investigating a problem when using a static IP and a = pseudorandom MAC. It seems that this looks like an attack to the SUT/DUT and won't = play with me. If anyone has some suggestions, I'm all ears. Jerry Perser VeriWave Main :=A0 818-338-4000 Direct: 818-338-4112 Fax:=A0=A0=A0 818-338-4005 _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Wed Mar 15 02:02:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQ1d-00051U-4c; Wed, 15 Mar 2006 02:02:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJQ1b-00051P-8N for bmwg@ietf.org; Wed, 15 Mar 2006 02:02:27 -0500 Received: from mail.rhodanewman.com ([64.239.163.238] helo=ns.networktest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJQ1a-0005gs-Ql for bmwg@ietf.org; Wed, 15 Mar 2006 02:02:27 -0500 Received: by ns.networktest.com (Postfix, from userid 1020) id A2DD2171C1; Tue, 14 Mar 2006 23:00:10 -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=2.5 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 058CD171BF; Tue, 14 Mar 2006 23:00:07 -0800 (PST) Message-ID: <4417BBFE.7010501@networktest.com> Date: Tue, 14 Mar 2006 23:02:22 -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] Implemeation notes from draft-ietf-bmwg-hash-stuffing-05.txt References: <200603150105.k2F15qYH016047@cia.veriwave.com> In-Reply-To: <200603150105.k2F15qYH016047@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: b280b4db656c3ca28dd62e5e0b03daa8 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: , Errors-To: bmwg-bounces@ietf.org Hi Jerry, Very glad to hear this is useful, and thanks much for the feedback. I've embedded comments/questions inline. Jerry Perser wrote: > I am not going to be able to make the next IETF meeting in March, so I > thought I share my experiences with implementing > draft-ietf-bmwg-hash-stuffing-05. These are thing that I experienced and > should in no way be construed as displeasure of the drafts last call status. > In fact, version 04 was good enough to implement on. > > 1. Used (RR & 0xFC) instead of (RR & 0xFE) for the MAC addresses first > Octet. I do not know the impact of mixing GLOBALLY ADMINISTERED ADDRESS and > LOCALLY ADMINISTERED ADDRESS in the same test. No completely sure if it's > still used. The IEEE 802.3 standard gives no information on the use or > issues. I decide to play it safe and only allow GLOBALLY ADMINISTERED > ADDRESS. One of the ID authors is a whole lot better than the other at bitwise math. When this topic came up, it took the more knowledgeable author about 9 nanoseconds to observe that ANDing an odd hex digit with 0xFE makes the number even. Hence there's no need to AND with 0xFC or 0xF6 or any of the other one's complements of the various multicast MAC high-order bytes. They're all odd, made even by ANDing them with 0xFE. > 2. The PP:PP 1-indexed interface number referred to the first interface that > frames are transmitted from. I am dealing with clients that move from one > interface to another (test of wireless LAN roaming). In a list of possible > interfaces, the MAC address refers to the first interface that sees frames. > This complies with the draft. I just wanted to be clear in my > implementation. Not sure I follow here. The draft deals with addressing of the transmitting interfaces of the test instrument, not the receivers. For actual clients doing roaming, the client's source MAC wouldn't change as the client roamed from one access point to another. Test instruments should emulate that behavior too. We may be saying the same thing here. If you're doing the same thing as an actual client -- with one source MAC throughout the test -- then we're on the same page. > 3. Pseudorandom number runs the risk of repeating during a test. The odds > are 16 million to 1 (roughly), but with my luck it will happen in February > in New England during a test, and I will have to go there. I have > implemented some crude code to filter out repeats. Looking for something > better that keeping a table of used addresses. The only chance for repetition, however remote, is among source addresses from the same interface of the generator (because of the unique port IDs). For test cases where 0 repetition is needed, filtering out dupes sounds like a sensible way to implement the ID. OTOH, the primary goal is to lessen the effects of hash collisions, and not necessarily to eliminate duplication. Currently, defaults in some test instruments produce 100.00 percent duplication, with a high likelihood of hash collisions. Randomizing addresses (as might be found in production settings) greatly reduces the probability of hash collisions, but it doesn't eliminate that chance altogether. I don't know that 0 percent hash collisions is any more meaningful than 100 percent hash collisions. > 4. Pseudorandomness is playing havoc with some security devices. Pseudorandom patterns wreak havoc with some switches and routers as well. They've been getting off easy with the static addresses we've fed them in lab testing all these years. It's the old tuning-for-benchmarks problem... dn I am > currently investigating a problem when using a static IP and a pseudorandom > MAC. It seems that this looks like an attack to the SUT/DUT and won't play > with me. If anyone has some suggestions, I'm all ears. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Wed Mar 15 10:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXwz-00042Z-NG; Wed, 15 Mar 2006 10:30:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXwy-00042U-Tu for bmwg@ietf.org; Wed, 15 Mar 2006 10:30:12 -0500 Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXwx-0004c1-Jx for bmwg@ietf.org; Wed, 15 Mar 2006 10:30:12 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4F0TP>; Wed, 15 Mar 2006 05:30:59 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA2057D0B78@apollo.adtech-inc.com> From: "Player, Timmons" To: "Newman, David" , Jerry Perser Subject: RE: [bmwg] Implemeation notes from draft-ietf-bmwg-hash-stuffing- 05.txt Date: Wed, 15 Mar 2006 05:30:50 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: bmwg-bounces@ietf.org > > 1. Used (RR & 0xFC) instead of (RR & 0xFE) for the MAC > addresses first > > Octet. I do not know the impact of mixing GLOBALLY ADMINISTERED > > ADDRESS and LOCALLY ADMINISTERED ADDRESS in the same test. No > > completely sure if it's still used. The IEEE 802.3 > standard gives no > > information on the use or issues. I decide to play it safe > and only > > allow GLOBALLY ADMINISTERED ADDRESS. > > One of the ID authors is a whole lot better than the other at > bitwise math. When this topic came up, it took the more > knowledgeable author about 9 nanoseconds to observe that > ANDing an odd hex digit with 0xFE makes the number even. > Hence there's no need to AND with 0xFC or 0xF6 or any of the > other one's complements of the various multicast MAC > high-order bytes. They're all odd, made even by ANDing them with 0xFE. > Actually, this is a different issue than multicast vs. unicast. Multicast vs. unicast is the first bit in the first byte of the MAC address. Global vs. local is the second bit in the first byte of the MAC address. So, ANDing with FC will ensure that both low order bits are "0's." But I've no idea if it makes a difference either... Timmons _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Wed Mar 15 11:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYee-0002OR-1q; Wed, 15 Mar 2006 11:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJYed-0002OM-Hn for bmwg@ietf.org; Wed, 15 Mar 2006 11:15:19 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJYec-0006p0-81 for bmwg@ietf.org; Wed, 15 Mar 2006 11:15:19 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1142439317!7565729!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 3656 invoked from network); 15 Mar 2006 16:15:17 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 15 Mar 2006 16:15:17 -0000 Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060315161517gw1001006re>; Wed, 15 Mar 2006 16:15:17 +0000 Message-Id: <6.2.1.2.0.20060315110010.090d7df8@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 15 Mar 2006 11:15:17 -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: 93238566e09e6e262849b4f805833007 Cc: Kevin Dubray Subject: [bmwg] Tentative Agenda for BMWG at IETF-65 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: , Errors-To: bmwg-bounces@ietf.org BMWG, Our tentative agenda is posted here: http://tools.ietf.org/wg/bmwg/agenda (this is the "Tools Team" site, where all sorts of helpful information is available, including archived drafts (with diff-versions, html versions, etc.) To make our meeting as productive as possible, Please: * READ the drafts * Let us know if you will be participating remotely (and if you are, please visit http://www.ietf.org/meetings/text_conf.html ) * Presenters - Please send your slides by Sunday Night (19th), and we'll post them on the Meeting Materials page: https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=65 Thanks, and See you in Dallas, Kevin/Al BMWG Co-Chairs _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Thu Mar 16 16:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Tw-0008Hs-Fd; Thu, 16 Mar 2006 16:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Tv-0008Hn-Pu for bmwg@ietf.org; Thu, 16 Mar 2006 16:58:07 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0Tv-0002dC-DS for bmwg@ietf.org; Thu, 16 Mar 2006 16:58:07 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2006 16:58:08 -0500 X-IronPort-AV: i="4.03,102,1141621200"; d="scan'208,217"; a="84306800:sNHT51525740" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2GLw6Wi011758; Thu, 16 Mar 2006 16:58:07 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 16:58:05 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 16:58:04 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) To: "Samir Vapiwala ((svapiwal))" , jkarthik@cisco.com, rpapneja@isocore.com Message-Id: <5148DD93-F1F1-4E62-AD97-A00B585D11DB@cisco.com> From: JP Vasseur Date: Thu, 16 Mar 2006 16:57:27 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 16 Mar 2006 21:58:04.0387 (UTC) FILETIME=[B3728B30:01C64944] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: bmwg@ietf.org Subject: [bmwg] Comments on draft-vapiwala-frr-failover-measurement-methodology-02.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="===============0965042536==" Errors-To: bmwg-bounces@ietf.org --===============0965042536== Content-Type: multipart/alternative; boundary=Apple-Mail-48-1030290694 --Apple-Mail-48-1030290694 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here are a few comments: First of all, very useful work. * The ID definitely requires a fair amount of editorial work but useful content * Section 1: In figure 1, TG & TA are Traffic Generator & Analyser respectively. A tester is set outside the node as it sends and receives IP traffic along the working Path, run protocol emulations simulating real world peering scenarios. You may want to detail which variables should be considered in order to gather accurate metrics. For instance, do we want to measure the restoration times and see whether there are any dependencies with the total LSDB size, number of prefixes, ... ? * Section 3.2 Failures on Ethernet technology links such as Gigabit Ethernet rely upon Layer 3 signaling indication for failure. BFD ? * Section 3.2 I would suggest to say a few words to determine/benchmark the failure detection times as it may not always be a negligible component of the overall rerouting time * Section 3.4 It is intended with Fast Reroute that the less than 45msec failover requirement be maintained when scaling the number of protected LSPs. Why 45ms ? * When you refer to MPLS Protection, I guess that you focus on Local Protection (RFC4090) ? * Section 4 - When you mention the number of labels before and after failure, mention where (since this may vary along the backup path if PHP is in use) - With Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in use - I did not read all the scenarios but you may want to mention why testing of each scenario is required * Section 5 - In the procedure you may want to look at the IGP convergence; indeed, there might be scenarios where the IGP convergence will lead to packet drops due to micro-loops. Although this is generally not the case, such packet drops may interfere with MPLS protection depending on the IGP tuning - I did not see anything about the testing of the RSVP refresh (along the backup tunnel path): indeed, if this is not properly handled this may lead to state time-out. JP. --Apple-Mail-48-1030290694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Here are a = few comments:

First = of all, very useful work.

* The ID=A0definitely requires a fair amount of = editorial work but useful content
* Section = 1:

=A0 =A0 = =A0In figure 1, TG & TA are Traffic Generator & Analyser = respectively.=A0
=A0 =A0=A0 A tester is = set outside the node as it sends and receives IP traffic
=A0 =A0=A0 along the working Path, run protocol = emulations simulating real world
=A0 =A0 = =A0peering scenarios.=A0

You may want to detail which variables should be = considered in order to gather accurate metrics. For instance, do we want = to=A0
measure the restoration times = and see whether there are any dependencies with the total LSDB size, = number of prefixes, ... ?
* Section = 3.2
=A0 =A0 =A0=A0 =A0Failures on = Ethernet technology links such as
=A0 =A0= =A0 =A0 Gigabit Ethernet rely upon Layer 3 signaling indication for = failure.
BFD ?
* Section 3.2=A0
I would = suggest to say a few words to determine/benchmark the failure detection = times as it may not always be a negligible component of the overall = rerouting time
* Section 3.4
=A0 =A0 =A0=A0 =A0It is intended with Fast = Reroute
=A0 =A0 =A0 =A0 that the less = than 45msec failover requirement be maintained when
=A0 =A0 =A0 =A0 scaling the number of protected = LSPs.=A0
Why 45ms ?
* When you refer to MPLS Protection, I guess that = you focus on Local Protection (RFC4090) ?
*=A0 = Section 4
- When you mention the number of = labels before and after failure, mention where (since this may vary = along the backup path if PHP is in use)
- With = Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in = use
- I did not read all the = scenarios but you may want to mention why testing of each scenario is = required
* Section 5
- In the procedure you may want to look at the IGP = convergence; indeed, there might be scenarios where the IGP convergence = will lead to packet drops due to micro-loops. Although this is generally = not the case, such packet drops may interfere with MPLS protection = depending on the IGP tuning
- I did not = see anything about the testing of the RSVP refresh (along the backup = tunnel path): indeed, if this is not properly handled this may lead to = state time-out.


= --Apple-Mail-48-1030290694-- --===============0965042536== 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 --===============0965042536==-- From bmwg-bounces@ietf.org Thu Mar 16 17:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0ba-00063c-UO; Thu, 16 Mar 2006 17:06:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0bZ-00063X-Qu for bmwg@ietf.org; Thu, 16 Mar 2006 17:06:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0bY-000342-78 for bmwg@ietf.org; Thu, 16 Mar 2006 17:06:01 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2006 14:05:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,102,1141632000"; d="scan'208,217"; a="23785624:sNHT45512732" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2GM5xVU014792; Thu, 16 Mar 2006 17:05:59 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 17:05:59 -0500 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Mar 2006 17:05:58 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) References: <5148DD93-F1F1-4E62-AD97-A00B585D11DB@cisco.com> Message-Id: From: JP Vasseur Date: Thu, 16 Mar 2006 17:05:22 -0500 To: "Samir Vapiwala ((svapiwal))" , jkarthik@cisco.com, rpapneja@isocore.com X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 16 Mar 2006 22:05:58.0976 (UTC) FILETIME=[CE531400:01C64945] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: bmwg@ietf.org Subject: [bmwg] Correction: comments relate to 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="===============0702855202==" Errors-To: bmwg-bounces@ietf.org --===============0702855202== Content-Type: multipart/alternative; boundary=Apple-Mail-50-1030765099 --Apple-Mail-50-1030765099 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: JP Vasseur > Date: March 16, 2006 4:57:27 PM EST > To: "Samir Vapiwala ((svapiwal))" , > jkarthik@cisco.com, rpapneja@isocore.com > Cc: bmwg@ietf.org > Subject: [bmwg] Comments on draft-vapiwala-frr-failover-measurement- > methodology-02.txt > > Here are a few comments: > > First of all, very useful work. > > * The ID definitely requires a fair amount of editorial work but > useful content > * Section 1: > > In figure 1, TG & TA are Traffic Generator & Analyser > respectively. > A tester is set outside the node as it sends and receives IP > traffic > along the working Path, run protocol emulations simulating > real world > peering scenarios. > > You may want to detail which variables should be considered in > order to gather accurate metrics. For instance, do we want to > measure the restoration times and see whether there are any > dependencies with the total LSDB size, number of prefixes, ... ? > * Section 3.2 > Failures on Ethernet technology links such as > Gigabit Ethernet rely upon Layer 3 signaling indication for > failure. > BFD ? > * Section 3.2 > I would suggest to say a few words to determine/benchmark the > failure detection times as it may not always be a negligible > component of the overall rerouting time > * Section 3.4 > It is intended with Fast Reroute > that the less than 45msec failover requirement be > maintained when > scaling the number of protected LSPs. > Why 45ms ? > * When you refer to MPLS Protection, I guess that you focus on > Local Protection (RFC4090) ? > * Section 4 > - When you mention the number of labels before and after failure, > mention where (since this may vary along the backup path if PHP is > in use) > - With Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in > use > - I did not read all the scenarios but you may want to mention why > testing of each scenario is required > * Section 5 > - In the procedure you may want to look at the IGP convergence; > indeed, there might be scenarios where the IGP convergence will > lead to packet drops due to micro-loops. Although this is generally > not the case, such packet drops may interfere with MPLS protection > depending on the IGP tuning > - I did not see anything about the testing of the RSVP refresh > (along the backup tunnel path): indeed, if this is not properly > handled this may lead to state time-out. > > JP. > > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www1.ietf.org/mailman/listinfo/bmwg --Apple-Mail-50-1030765099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = March 16, 2006 4:57:27 PM EST
To: "Samir = Vapiwala ((svapiwal))" <svapiwal@cisco.com>, jkarthik@cisco.com, rpapneja@isocore.com
=
Subject: = [bmwg] Comments on = draft-vapiwala-frr-failover-measurement-methodology-02.txt

Here = are a few comments:

First = of all, very useful work.

* The ID=A0definitely requires a fair amount of = editorial work but useful content
* Section = 1:

=A0 =A0 = =A0In figure 1, TG & TA are Traffic Generator & Analyser = respectively.=A0
=A0 =A0=A0 A tester is = set outside the node as it sends and receives IP traffic
=A0 =A0=A0 along the working Path, run protocol = emulations simulating real world
=A0 =A0 = =A0peering scenarios.=A0

You may want to detail which variables should be = considered in order to gather accurate metrics. For instance, do we want = to=A0
measure the restoration times = and see whether there are any dependencies with the total LSDB size, = number of prefixes, ... ?
* Section = 3.2
=A0 =A0 =A0=A0 =A0Failures on = Ethernet technology links such as
=A0 =A0= =A0 =A0 Gigabit Ethernet rely upon Layer 3 signaling indication for = failure.
BFD ?
* Section 3.2=A0
I would = suggest to say a few words to determine/benchmark the failure detection = times as it may not always be a negligible component of the overall = rerouting time
* Section 3.4
=A0 =A0 =A0=A0 =A0It is intended with Fast = Reroute
=A0 =A0 =A0 =A0 that the less = than 45msec failover requirement be maintained when
=A0 =A0 =A0 =A0 scaling the number of protected = LSPs.=A0
Why 45ms ?
* When you refer to MPLS Protection, I guess that = you focus on Local Protection (RFC4090) ?
*=A0 = Section 4
- When you mention the number of = labels before and after failure, mention where (since this may vary = along the backup path if PHP is in use)
- With = Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in = use
- I did not read all the = scenarios but you may want to mention why testing of each scenario is = required
* Section 5
- In the procedure you may want to look at the IGP = convergence; indeed, there might be scenarios where the IGP convergence = will lead to packet drops due to micro-loops. Although this is generally = not the case, such packet drops may interfere with MPLS protection = depending on the IGP tuning
- I did not = see anything about the testing of the RSVP refresh (along the backup = tunnel path): indeed, if this is not properly handled this may lead to = state time-out.


bmwg mailing list

= --Apple-Mail-50-1030765099-- --===============0702855202== 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 --===============0702855202==-- From bmwg-bounces@ietf.org Thu Mar 16 21:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4sa-0001fg-5c; Thu, 16 Mar 2006 21:39:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4sY-0001fb-Sq for bmwg@ietf.org; Thu, 16 Mar 2006 21:39:50 -0500 Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4sV-0004Vm-G9 for bmwg@ietf.org; Thu, 16 Mar 2006 21:39:50 -0500 Received: from webmail.avici.com (mailhost.avici.com [127.0.0.1]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id k2H2d0Tt002132; Thu, 16 Mar 2006 21:39:05 -0500 Received: from 10.2.2.223 (SquirrelMail authenticated user vgurudevappa) by webmail.avici.com with HTTP; Thu, 16 Mar 2006 21:39:26 -0500 (EST) Message-ID: <49016.10.2.2.223.1142563166.squirrel@webmail.avici.com> Date: Thu, 16 Mar 2006 21:39:26 -0500 (EST) Subject: RE: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt From: vgurudevappa@avici.com To: svapiwal@cisco.com, jkarthik@cisco.com, rpapneja@isocore.com User-Agent: SquirrelMail/1.4.0-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: bmwg-bounces@ietf.org Hello, I had a chance to go through your draft and had the following comments. Both of them pertain to Traffic Generation section(Sec 3.7). 1.Limiting the users to use 3 streams or for that matter any number is not a good idea. Must leave this to the person Benchmarking. 2. Your example text is confusing. The "middle of the advertised route" could mean the order of the prefix advertised or the prefix that is right in the middle of a data structure which could again differ based on what data structure is used. Vrushi _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Mon Mar 20 00:05:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLCaR-0000fv-UZ; Mon, 20 Mar 2006 00:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLCaQ-0000f5-9f for bmwg@ietf.org; Mon, 20 Mar 2006 00:05:46 -0500 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLCaO-0001Y5-VT for bmwg@ietf.org; Mon, 20 Mar 2006 00:05:46 -0500 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.52) id 1FLCaM-0005MM-IN; Mon, 20 Mar 2006 00:05:42 -0500 Received: from 68.100.78.40 ([68.100.78.40]) by www.isocore.com (Horde MIME library) with HTTP; Mon, 20 Mar 2006 00:05:42 -0500 Message-ID: <20060320000542.4xhoeoqv9tj4wogw@www.isocore.com> Date: Mon, 20 Mar 2006 00:05:42 -0500 From: Rajiv Papneja To: JP Vasseur Subject: Re: [bmwg] Correction: comments relate to draft-vapiwala-bmwg-frr-failover-meth-00.txt References: <5148DD93-F1F1-4E62-AD97-A00B585D11DB@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: jkarthik@cisco.com, "Samir Vapiwala \(\(svapiwal\)\)" , 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: , Errors-To: bmwg-bounces@ietf.org Hello JP, Thanks for your comments, and I really appreciate you spending time in reviewing our draft. Please see my responses inline. Regards, Rajiv Quoting JP Vasseur : > > > Begin forwarded message: > >> From: JP Vasseur >> Date: March 16, 2006 4:57:27 PM EST >> To: "Samir Vapiwala ((svapiwal))" , >> jkarthik@cisco.com, rpapneja@isocore.com >> Cc: bmwg@ietf.org >> Subject: [bmwg] Comments on draft-vapiwala-frr-failover-measurement- >> methodology-02.txt >> >> Here are a few comments: >> >> First of all, very useful work. >> >> * The ID definitely requires a fair amount of editorial work but >> useful content >> * Section 1: >> >> In figure 1, TG & TA are Traffic Generator & Analyser respectively. >> A tester is set outside the node as it sends and receives IP traffic >> along the working Path, run protocol emulations simulating real world >> peering scenarios. >> >> You may want to detail which variables should be considered in >> order to gather accurate metrics. [rp] We will definitely try to clarify this. >> For instance, do we want to >> measure the restoration times and see whether there are any >> dependencies with the total LSDB size, number of prefixes, ... ? [rp] Yes. >> * Section 3.2 >> Failures on Ethernet technology links such as >> Gigabit Ethernet rely upon Layer 3 signaling indication for >> failure. >> BFD ? [rp] Yes, may be. We can consider this. But many vendors currently do not support this feature. BFD could also be used for IGP liveliness detection, for MPLS LSPs failure detection, and Ethernet. This may be the ideal way and we can definitely consider adding this as an option. >> * Section 3.2 >> I would suggest to say a few words to determine/benchmark the >> failure detection times as it may not always be a negligible >> component of the overall rerouting time [rp] Yes, agree. This is very good input. >> * Section 3.4 >> It is intended with Fast Reroute >> that the less than 45msec failover requirement be maintained when >> scaling the number of protected LSPs. >> Why 45ms ? [rp] We can remove the mention of 45ms limit or we can change this to state that how many prefixes or tunnel can get switched in 45ms. >> * When you refer to MPLS Protection, I guess that you focus on >> Local Protection (RFC4090) ? [rp] yes. >> * Section 4 >> - When you mention the number of labels before and after failure, >> mention where (since this may vary along the backup path if PHP is >> in use) [rp] On Point of local repair, we will update >> - With Layer3 VPN, PE to PE TE LSPs, mention that there's no LDP in use [rp] We will mention it. >> - I did not read all the scenarios but you may want to mention why >> testing of each scenario is required [rp] Good point, we will try to add a motivation section to all scenarios >> * Section 5 >> - In the procedure you may want to look at the IGP convergence; >> indeed, there might be scenarios where the IGP convergence will >> lead to packet drops due to micro-loops. Although this is generally >> not the case, such packet drops may interfere with MPLS protection >> depending on the IGP tuning [rp] we will definitely consider >> - I did not see anything about the testing of the RSVP refresh >> (along the backup tunnel path): indeed, if this is not properly >> handled this may lead to state time-out. [rp] We will add this in procedure >> >> JP. >> >> _______________________________________________ >> bmwg mailing list >> bmwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/bmwg > > _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Tue Mar 21 00:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLZfN-0005fo-Ch; Tue, 21 Mar 2006 00:44:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLZfJ-0005Tg-DA for bmwg@ietf.org; Tue, 21 Mar 2006 00:44:21 -0500 Received: from mail.veriwave.com ([64.1.198.186] helo=cia.veriwave.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLZXm-0006Uz-Mc for bmwg@ietf.org; Tue, 21 Mar 2006 00:36:36 -0500 Received: from TomD600 (ip-69-54-135-157.client.bct.org [69.54.135.157]) (authenticated bits=0) by cia.veriwave.com (8.12.8/8.12.8) with ESMTP id k2L5aRYG031178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Mar 2006 21:36:30 -0800 Message-Id: <200603210536.k2L5aRYG031178@cia.veriwave.com> From: "Tom Alexander" To: Date: Mon, 20 Mar 2006 21:41:06 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C64C67.01985220" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXiH3QfP+mBnV8PSVuH0b1mEoPhcwBvdT5QGjMRNvA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: 'Al Morton' , 'Kevin Dubray' Subject: [bmwg] March update on IEEE 802.11T 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: , Errors-To: bmwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C64C67.01985220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit BMWG, Enclosed is an informal update on the latest in the IEEE 802.11T (wireless performance prediction) task group. The next 802.11T meeting is in May 2006, in Florida. The IEEE 802.11T TG chair currently anticipates that the 802.11T draft will go to letter ballot (within the 802.11 working group) some time towards the end of this year, at which point the draft should be available for general review and comment by the 802.11 working group. Additional information is available in presentations and documents in the enclosed doc, along with instructions for retrieving them from the IEEE 802.11 document server. I'll also be present in the BMWG meeting in Dallas if anybody has more questions. Thanks, and best regards, - Tom Alexander ------=_NextPart_000_0000_01C64C67.01985220 Content-Type: text/plain; name="BMWG update Mar 2006.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="BMWG update Mar 2006.txt" Brief Update on IEEE 802.11T (Wireless Performance Task Group) = Activities -------------------------------------------------------------------------= Since the last IETF, the IEEE 802.11T task group has met three times: in November (Vancouver, BC); January (Waikoloa, HI); and in March (Denver, = CO). Eight new proposals for metrics, test environments and background = material were accepted and incorporated, or are being incorporated, into the = draft. The draft document is now at revision 0.6 and stands at about 130 pages = long, and has taken on the shape of the final standard. A total of 15 metrics = and 6 different test environments have been incorporated. The task group is continuing to add new metrics to the draft, revise the existing text, = and generally fill out the incomplete sections. Currently, the 802.11T TG is planning to forward the draft for Working = Group letter ballot in November of 2006 (at which point it can also be made available to BMWG, as per previous discussions), with the intent of = seeking approval for the final standard by January of 2008. The tentative = publication date of the standard would therefore be around mid-2008. The next meeting will be in Jacksonville, FL, from May 14th through = 19th. A list of relevant presentations and draft text proposals have been = provided below, as well as instructions on how to obtain them from the IEEE = 802.11 document server. The IEEE 802.11 process is to incorporate voted-in = draft text proposals into an evolving draft with only editorial changes. Hence = the technical substance of the current draft can be understood by looking at these contributions. Meeting Materials ----------------- A. Procedural, minutes, etc 1. November 2005 Vancouver meeting slides Document 11-05-1140-02-000t 2. November 2005 closing report Document 11-05-1141-02-000t 3. January 2006 Waikoloa meeting slides Document 11-06-0049-02-000t 4. January 2006 closing report Document 11-05-0050-01-000t 5. March 2006 Denver meeting slides Document 11-06-0402-01-000t 6. March 2006 closing report Document 11-05-0403-01-000t B. Draft text proposals and associated presentations The following proposals and accompanying presentations have been voted into the 802.11.2 draft. 1. Document Framework Section Document 11-05-0969-02-000t =09 2. Test Methodology for Measuring BSS Transition Time Document 11-05-0537-02-000t 3. Receiver Sensitivity Metrics in a Conductive Test Environment Document 11-05-1157-01-000t =09 4. Link Layer Metrics Proposal Document 11-05-0638-02-000t 5. TGT Power Consumption Test Environment and Metrics Document 11-06-0007-00-000t 6. Handheld OTA LOS Test Methodology Document 11-05-0078-01-000t 7. Test methodology for Measuring Loss, Delay and Jitter Document 11-06-0004-03-000t 8. Coexistence of Two Overlapping BSSs in Adjacent Channels Document 11-05-0383-00-000t C. Other selected presentations 1. Test Practices and Test Equipment Document 11-05-1043-00-000t 2. Theoretical Throughput Limits Document 11-05-1050-00-000t 3. Latency Sensitive Usage Case Document 11-05-1109-00-000t 4. Video Testing Methodology Document 11-05-1194-00-000t 5. Over-the-air Testing - Comparing Systems with Different Antennas Document 11-06-0026-00-000t 6. Traceable Over-the-air Performance Testing Document 11-06-0131-01-000t 7. Power Consumption for Low Power Devices Document 11-06-0477-00-000t Procedure For Access To IEEE 802.11T Documents ---------------------------------------------- 1. Navigate to http://www.802wirelessworld.com 2. In the top right, it will say: "Welcome Guest! Please login or = register". Click on "register". 3. This will take you to a page requesting an e-mail address (which will also serve as a login ID) and a password of your choice. Type in your e-mail address and a desired password. Any valid e-mail should be acceptable. 4. Once your e-mail and password have been accepted, the system will = request you to actually log in using this information. Log in as directed. 5. The system will now take you to a contact update page. Type in your contact information. 6. After entering your contact info, the system will ask you to select a group of interest. Click on "802.11 WLAN WG" (and any other groups you might be interested in). 7. You will now be shown a meeting attendance, voting status credit, and WG information access web page. Click on "802.11 WLAN WG" under = "Working Groups" in the column on the left to expand the choices for the 802.11 WG. 8. Select "Documents" under "802.11 WLAN WG". This will bring up a WG document listing. Be sure that the tab "Document Listing" is = highlighted, not "Document Control Numbers". If necessary click on the tab to highlight it. 9. Documents are displayed in a 3-column format: date/time of = submission, the Document Control Number (DCN), and the document title assigned by the author. The default sort order for the documents is by date and = time of submission. Pulldowns are available to sort by DCN or by title, and to reverse the order of sort. Typically the easiest method is to leave the documents sorted by date. 10. Document control numbers have a structured format of the form: gg-yy-nnnn-rr-tttt where gg =3D 802 group suffix, in this case "11" for 802.11 yy =3D last 2 digits of year ("06" for 2006) nnnn =3D document number, 1 - 9999, assigned by system rr =3D revision number (starting at 00) tttt =3D Task Group suffix; TGT's suffix is "000t" 11. Scroll down the table of results using the line at the bottom of the table (the line: "Results: 1-25 26-50 51-75 76-100 101-125 Next =BB Last(4616)") You will have to manually navigate until you find the document you = want. 12. Clicking on the document number brings up a dialog box to allow you = to save it to your computer. 13. No search facility is unfortunately available via the web interface. This is being remedied but it appears that it will take quite some time to complete. 14. The bottom of the table displays an FTP host, login and password = that purports to give you access to the same 802.11 documents, but on an FTP server instead. However, be warned that many of the documents shown on the document server web pages do not seem to be present on the FTP server. ------=_NextPart_000_0000_01C64C67.01985220 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_000_0000_01C64C67.01985220-- From bmwg-bounces@ietf.org Tue Mar 21 10:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiPR-0001Sy-Nq; Tue, 21 Mar 2006 10:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiPQ-0001St-UM for bmwg@ietf.org; Tue, 21 Mar 2006 10:04:32 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiPQ-0002nW-NC for bmwg@ietf.org; Tue, 21 Mar 2006 10:04:32 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2006 07:04:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,114,1141632000"; d="scan'208"; a="24087246:sNHT38837388" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LF4TWg019388; Tue, 21 Mar 2006 10:04:30 -0500 (EST) 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, 21 Mar 2006 10:04:36 -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 Subject: RE: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt Date: Tue, 21 Mar 2006 10:03:54 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt Thread-Index: AcZJbAewOuU6cB3NTXikM+U9Ea6+6QAXAEhg From: "Samir Vapiwala \(svapiwal\)" To: , X-OriginalArrivalTime: 21 Mar 2006 15:04:36.0918 (UTC) FILETIME=[C51BED60:01C64CF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpapneja@isocore.com 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: , Errors-To: bmwg-bounces@ietf.org Hi Vrushi Thanks for your comments, Your input is greatly appreciated. Please see inline. Regards Samir -----Original Message----- From: vgurudevappa@avici.com [mailto:vgurudevappa@avici.com]=20 Sent: Thursday, March 16, 2006 9:39 PM To: Samir Vapiwala (svapiwal); jkarthik@cisco.com; rpapneja@isocore.com Cc: bmwg@ietf.org Subject: RE: [bmwg] draft-vapiwala-bmwg-frr-failover-meth-00.txt Hello, I had a chance to go through your draft and had the following comments. Both of them pertain to Traffic Generation section(Sec 3.7). 1.Limiting the users to use 3 streams or for that matter any number is not a good idea. Must leave this to the person Benchmarking. SV: Reason we are limiting 3 streams to get failover time for 1st, middle and last prefixes or tunnel, any number of stream could mean sending traffic in round robin fashion to every prefix or tunnel, which will not give consistence failover time if vendor is using per prefix or tunnel failover method. In next revision I'll provide more info on why we are suggesting 3 streams. 2. Your example text is confusing. The "middle of the advertised route" could mean the order of the prefix advertised or the prefix that is right in the middle of a data structure which could again differ based on what data structure is used. SV: You are right, I shouldn't say ""middle of the advertised route" I'll re-word it in version 1 Vrushi _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg From bmwg-bounces@ietf.org Thu Mar 23 00:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMI3G-0004lV-2w; Thu, 23 Mar 2006 00:08:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMI3F-0004lQ-0J for bmwg@ietf.org; Thu, 23 Mar 2006 00:08:01 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMI3E-0007Lt-JO for bmwg@ietf.org; Thu, 23 Mar 2006 00:08:00 -0500 X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1143090479!10090657!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23220 invoked from network); 23 Mar 2006 05:07:59 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-14.tower-120.messagelabs.com with SMTP; 23 Mar 2006 05:07:59 -0000 Received: from acmt.att.com (unknown[135.70.146.253](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20060323050758gw10010052e>; Thu, 23 Mar 2006 05:07:59 +0000 Message-Id: <6.2.1.2.0.20060323000503.0785f440@postoffice.maillennium.att.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 23 Mar 2006 00:07:58 -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: 2086112c730e13d5955355df27e3074b Subject: [bmwg] WG Chair Shepherding Write-up for dsmterm 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: , Errors-To: bmwg-bounces@ietf.org BMWG, FYI - Here's the shepherding write-up/publication request for the dsmterm draft. ------------------------------------------------------------------ ... 3.1 WG Chair Write-Up for Publication Request Internet-Draft: Terminology for Benchmarking Network-layer Traffic Control Mechanisms http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-12.txt WG Chair Shepherd: Al Morton 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. Note that a few typos have crept into version 12 (in section 3.4.4.5, "Expect" --> "Expected") and there are two very minor nits, considering that this document is being edited as a flat file, with little formatting help: * There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 11) being 59 lines but these can be repaired along with future comments. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, the reviews have been very complete over 5 WG Last Calls. Non-WG members have been consulted, and there are no known concerns. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No, Co-Chair comments have been addressed. 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? This draft precipitated substantial comments from many WG members during its many WG Last Calls. The final comments were resolved as summarized here: http://www1.ietf.org/mail-archive/web/bmwg/current/msg00845.html (then, the primary editor left the group, and it took time to get another editor to correct the I-D nits issues) ... 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Two lines have >72 characters (1 nit), and there is one warning. The nit should not impact AD or IESG review. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes, the references are split and all the normative references are stable. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: The draft is Informational, as are all BMWG RFCs, but we provide the following summary: * Technical Summary This document describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or Diffserv code point criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. New terminology is needed because most existing measurements assume the absence of congestion and only a single per-hop- behavior. This document introduces several new terms that will allow measurements to be taken during periods of congestion. Another key difference from existing terminology is the definition of measurements as observed on egress as well as ingress of a device/system under test. Again, the existence of congestion requires the addition of egress measurements as well as those taken on ingress; without observing traffic leaving a device/system it is not possible to say whether traffic-control mechanisms effectively dealt with congestion. The principal measurements introduced in this document are vectors for rate, delay, and jitter, all of which can be observed with or without congestion of the DUT/SUT. * Working Group Summary This document is a product of the BMWG WG. The WG has consensus to publish this document as an Informational RFC. * Protocol Quality This document does not specify a protocol. 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. (above) _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg