Received: from cnri by ietf.org id aa05273; 3 Jul 97 8:10 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA27125 for ; Thu, 3 Jul 1997 08:09:21 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id FAA23523 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/06/05-I) with ESMTP id FAA28431 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id IAA20139; Thu, 3 Jul 1997 08:02:14 -0400 for bmwg-outgoing Received: from mailhost.BayNetworks.COM (addme [134.177.1.107]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id IAA20133; Thu, 3 Jul 1997 08:02:12 -0400 for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/06/05-I) with ESMTP id FAA16527 Posted-Date: Thu, 3 Jul 1997 05:02:06 -0700 (PDT) Received: from pestilence.engeast (pestilence [192.32.180.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id IAA20124; Thu, 3 Jul 1997 08:02:02 -0400 for Date: Thu, 3 Jul 1997 08:02:02 -0400 From: Kevin Dubray Message-Id: <199707031202.IAA20124@pobox.engeast.BayNetworks.COM> To: bmwg@baynetworks.com Subject: Security Workplan Adopted Cc: dnewman@mcgraw-hill.com, mo@uu.net, jcurran@bbn.com, jis@mit.edu Sender: owner-bmwg@baynetworks.com Precedence: bulk Folks, There's consensus to have the BMWG adopt the network security device benchmarking work action proposed by Newman et al. The BMWG agenda for Munich reflects this feat. The agenda can be accessed via the URL: ftp://ftp.ietf.org/ietf/bmwg/bmwg-agenda-97aug.txt -Kevin   Received: from cnri by ietf.org id aa07326; 8 Jul 97 9:57 EDT Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA06052 for ; Tue, 8 Jul 1997 09:55:57 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id KAA26164 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id GAA28638 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id JAA03994; Tue, 8 Jul 1997 09:49:34 -0400 for bmwg-outgoing Received: from mailhost2.BayNetworks.COM (baynet.corpwest.baynetworks.com [134.177.3.20]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id JAA03988; Tue, 8 Jul 1997 09:49:32 -0400 for Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id GAA16239; Tue, 8 Jul 1997 06:44:35 -0700 (PDT) for Posted-Date: Tue, 8 Jul 1997 06:44:35 -0700 (PDT) Received: from netop3.harvard.edu (netop3.harvard.edu [128.103.205.103]) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) with SMTP id JAA18621 for ; Tue, 8 Jul 1997 09:47:26 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by netop3.harvard.edu (8.6.12/8.6.12) with SMTP id JAA25927 for ; Tue, 8 Jul 1997 09:49:45 -0400 Received: from ietf.ietf.org by ietf.org id aa07055; 8 Jul 97 9:53 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: bmwg@harvard.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-lanswitch-05.txt Date: Tue, 08 Jul 1997 09:53:25 -0400 Message-ID: <9707080953.aa07055@ietf.org> Sender: owner-bmwg@baynetworks.com Precedence: bulk --NextPart A Revised 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 Terminology for LAN Switching Devices Author(s) : B. Mandeville Filename : draft-ietf-bmwg-lanswitch-05.txt Pages : 19 Date : 07/07/1997 This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. Although it might be found useful to apply some of the terms defined here to a broader range of network interconnect devices, this document primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It defines terms in relation to the traffic put to use when benchmarking switching devices, forwarding performance, latency, address handling and filtering. Internet-Drafts are 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-lanswitch-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-lanswitch-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-lanswitch-05.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970708091709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-lanswitch-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-lanswitch-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970708091709.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa17180; 8 Jul 97 16:47 EDT Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA07986 for ; Tue, 8 Jul 1997 16:46:08 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id QAA15756 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id NAA08811 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id QAA29500; Tue, 8 Jul 1997 16:41:21 -0400 for bmwg-outgoing Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id QAA29485; Tue, 8 Jul 1997 16:41:19 -0400 for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id NAA08758 Posted-Date: Tue, 8 Jul 1997 13:41:15 -0700 (PDT) Received: from pestilence.engeast (pestilence [192.32.180.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA29475; Tue, 8 Jul 1997 16:41:08 -0400 for Date: Tue, 8 Jul 1997 16:41:08 -0400 From: Kevin Dubray Message-Id: <199707082041.QAA29475@pobox.engeast.BayNetworks.COM> To: bmwg@baynetworks.com Subject: New BMWG draft Cc: mo@uu.net, jcurran@bbn.com Sender: owner-bmwg@baynetworks.com Precedence: bulk Folks, As you may have noticed, the IETF secretariat has issued a new version of the LAN switch benchmarking terminology draft, . As the editor believes the draft is ready to forward for RFC consideration, please have a good read. Please bring any outstanding issues to this list's attention as soon as possible, as I would like to test consensus in the next week or so depending on comments/revisions. For those that missed the notice, the draft can be accessed from: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bmwg-lanswitch-05.txt Thanks, in advance, for your participation. -Kevin   Received: from cnri by ietf.org id aa09434; 15 Jul 97 10:04 EDT Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA04115 for ; Tue, 15 Jul 1997 10:03:33 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id GAA24112 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id GAA22202 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id JAA05103; Tue, 15 Jul 1997 09:51:11 -0400 for bmwg-outgoing Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id JAA05097; Tue, 15 Jul 1997 09:51:09 -0400 for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id GAA21974; Tue, 15 Jul 1997 06:51:09 -0700 (PDT) for Posted-Date: Tue, 15 Jul 1997 06:51:09 -0700 (PDT) Received: from membrane.engeast (membrane [192.32.182.132]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA05093; Tue, 15 Jul 1997 09:51:08 -0400 for Date: Tue, 15 Jul 1997 09:51:08 -0400 From: Charles Winter Message-Id: <199707151351.JAA05093@pobox.engeast.BayNetworks.COM> To: bmwg@baynetworks.com Subject: comment on draft lanswitch-05.txt Sender: owner-bmwg@baynetworks.com Precedence: bulk Sirs, Some feedback on the draft "Benchmarking Terminology for LAN Switching Devices", (bmwg-lanswitch-05.txt): The term "bidirectional multi-port test", used in Subsection "3.3.3 - Fully meshed traffic" of the draft is not included in the terminology definition. It's use to compare multiple switching device traffic loads between itself and "fully meshed traffic" is unclear. This term should either be defined in the terminology, or pertinent text containing this term should be cut out of the draft. Charles Winter, Bay Networks   Received: from cnri by ietf.org id aa22244; 17 Jul 97 22:09 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA14294 for ; Thu, 17 Jul 1997 22:07:44 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id TAA16482 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id TAA12290 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id VAA26291; Thu, 17 Jul 1997 21:57:17 -0400 for bmwg-outgoing Received: from mailhost1.BayNetworks.COM (southpass.corpwest.baynetworks.com [134.177.3.16]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id VAA26285; Thu, 17 Jul 1997 21:57:15 -0400 for Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id SAA16340; Thu, 17 Jul 1997 18:57:14 -0700 (PDT) for Posted-Date: Thu, 17 Jul 1997 18:57:14 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id VAA09217 for bmwg@baynetworks.com; Thu, 17 Jul 1997 21:57:04 -0400 (EDT) Date: Thu, 17 Jul 1997 21:57:04 -0400 (EDT) From: Scott Bradner Message-Id: <199707180157.VAA09217@newdev.harvard.edu> To: bmwg@baynetworks.com Subject: draft-ietf-bmwg-lanswitch-05.txt Sender: owner-bmwg@baynetworks.com Precedence: bulk Hi Bob & all I'm (belatedly) taking a look at draft-ietf-bmwg-lanswitch-05.txt and have some comments --------------- 3.1.1 Device under test (DUT) Discussion: A single stand-alone or modular unit generally equipped with its own power supply. -- I don't think the reference to a power supply is needed I'd say something like: A single stand-alone or modular unit which forwards frames of data from one or more interfaces to one or more interfaces. -------------- 3.2.1 Unidirectional traffic Definition: Frames presented to a DUT/SUT such that the receiving and transmitting interfaces are mutually exclusive. 3.3.2 Partially meshed traffic Definition: Frames forwarded between mutually exclusive sets of input and output interfaces of a DUT/SUT. -- I'm a bit confused by this pair of definitions - they do not seem to say something different - I'm not quite sure how to change somthing to fix the definitions - in general the 3.2 section and the 3.3 sections seem to overlap and need to have some reworking and the discussions do not clarify things for me - I suggest that the Partially meshed traffic def & discussion should be worked on to clarify things ----------------- 3.2.1 Unidirectional traffic Discussion: I think the discussion could be clarified to some degree - I took a cut at part of it It is useful to distinguish traffic orientation and traffic distribution when considering traffic patterns used in device testing. Unidirectional traffic, for example, is traffic orientated in a single direction between mutually exclusive sets of source and destination interfaces of a DUT/SUT. Such traffic, however, can be distributed between interfaces in different ways. When traffic is sent to two or more interfaces from an external source and then forwarded by the DUT/SUT to a single output interface the traffic orientation is unidirectional and the traffic distribution between interfaces is many-to-one. Traffic can also be sent to a single input interface and forwarded by the DUT/SUT to two or more output interfaces to achieve a one-to-many distribution of traffic. -- Such traffic distributions can also be combined to test for head of line blocking or to measure forwarding rates and throughput when congestion control is active. -- the See Also section should include 3.7.3 Head of line blocking and 3.7 Congestion control ------------------ 3.2.2 Bidirectional traffic Definition: Frames presented to a DUT/SUT such that the interfaces of the DUT/SUT both receive and transmit. -- I'd change just a bit Frames presented to a DUT/SUT such that each of the interfaces of the DUT/SUT both receive and transmit. ------------------- 3.2.2 Bidirectional traffic Discussion: This definition conforms to the discussions in sections 14 and 16 of RFC 1944 on bidirectional traffic and multi-port testing. Bidirectional traffic MUST be offered when measuring throughput on full duplex interfaces of a switching device. -- all RFCs wich use the terms like "MUST" "MAY" etc should now contain a reference to RFC 2119 - the exact form of the reference is in the RFC -------------------- 3.3.3 Fully meshed traffic It should be noted that bidirectional multi-port traffic can load backbone connections linking together two switching devices more than meshed traffic. -- it would be nice to expand on this a bit ---------------------- 3.3.3 Fully meshed traffic Bidirectional meshed traffic on half duplex interfaces is inherently bursty since interfaces must interrupt transmission whenever they receive frames. This kind of bursty meshed traffic is characteristic of real network traffic and can be advantageously used to diagnose a DUT/SUT by exercising many of its component parts simultaneously. Additional inspection may be warranted to correlate the frame forwarding capacity of a DUT/SUT when offered meshed traffic and the behavior of individual elements such as input or output buffers, buffer allocation mechanisms, aggregate switching capacity, processing speed or medium access control. -- it might be good to add that analysis of the results of such tests can present a chalenge since you need to take into account the actual rate at which data was presented to the DUT/SUT rather than just the rate that the tester attempted to send. (i.e. the offered vs intended load) - the see also should point to them ----------------------- 3.4.2 Burst size Discussion: Burst size can range from one to infinity. In unidirectional traffic there is no theoretical limit to burst length. -- I'd tweak this a bit Burst size can range from one to infinity. In unidirectional traffic and in bidirectional or meshed bursts on full duplex interfaces there is no theoretical limit to burst length. ----------------------- 3.4.3 Inter-burst gap (IBG) Bidirectional and meshed traffic are inherently bursty since interfaces share their time between receiving and transmitting frames. External sources offering bursty traffic for a given frame size and burst size must adjust the inter-burst gap to achieve a specified rate of transmission. -- I'd tewak this a bit External sources offering bursty traffic for a given frame size and burst size must adjust the inter-burst gap to achieve a specified average rate of frame transmission. ----------------------- 3.5.1 Intended load (Iload) In the case of Ethernet an external source of traffic must implement the truncated binary exponential back-off algorithm to ensure that it is accessing the medium legally. -- I'd change the "must" to "MUST" the See Also should include references to the burst & interburst gap sections ------------------------ 3.5.2 Offered load (Oload) I'd also note that analysis of testing where offered ~= intended must that the difference into account ----------------------- 3.5.4 Overloading I'd add that information obtained through this type of test can present opportunities for abuse by marketeers ----------------------- 3.7 Congestion control I'd also note the dificulity of understanding performance results in devices that include congestion control --------------------- 3.7.3 Head of line blocking Definition: Frame loss observed on an uncongested output interface whenever frames are received from an input interface which is also attempting to forward frames to a congested output interface. -- not just loss, also added delay --------------------- 3.10.1 Broadcast forwarding rate Definition: The number of broadcast frames per second that a DUT/SUT can be observed to deliver to all interfaces located within a broadcast domain in response to a specified offered load. -- I'd tweak The number of broadcast frames per second that a DUT/SUT can be observed to deliver to all interfaces located within a broadcast domain in response to a specified offered load of frames to the broadcast MAC address. what about multicast? ----------------------- 4. Security Considerations This document raises no security issues. -- the iesg will no longer OK RFCs that have this type of Security Considerations section - it need to say things like Documents of this type do not directly effect the security of the Internet or of corporate networks as long as testers implementing tests of this type are not connected to operating networks. Scott   Received: from cnri by ietf.org id aa23842; 28 Jul 97 18:48 EDT Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA19140 for ; Mon, 28 Jul 1997 18:47:07 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id SAA18890 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id SAA06152; Mon, 28 Jul 1997 18:00:59 -0400 for bmwg-outgoing Received: from mailhost1.BayNetworks.COM (southpass.corpwest.baynetworks.com [134.177.3.16]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id SAA06146; Mon, 28 Jul 1997 18:00:58 -0400 for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id PAA10331; Mon, 28 Jul 1997 15:00:55 -0700 (PDT) for Posted-Date: Mon, 28 Jul 1997 15:00:55 -0700 (PDT) Received: from pestilence.engeast (pestilence [192.32.180.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA06142; Mon, 28 Jul 1997 18:00:55 -0400 for Date: Mon, 28 Jul 1997 18:00:55 -0400 From: Kevin Dubray Message-Id: <199707282200.SAA06142@pobox.engeast.BayNetworks.COM> To: bmwg@baynetworks.com Subject: Switch draft Q&A Sender: owner-bmwg@baynetworks.com Precedence: bulk Hi Scott and all, I have given your remarks a lot of consideration as I think you will see from the amendments I have made to the document. I have commented on your comments and annotated them in the reply message below. Each of my comments starts with ''. In general I think that you will find that your comments have led me to say things more simply and, I hope, more clearly. In a rush of optimism I have taken out the time to 'freeze' the document by formatting it as per the Guideline RFC. Thanks for the comments and have a good read. Bob [from Scott] Hi Bob & all I'm (belatedly) taking a look at draft-ietf-bmwg-lanswitch-05.txt and have some comments --------------- 3.1.1 Device under test (DUT) Discussion: A single stand-alone or modular unit generally equipped with its own power supply. -- I don't think the reference to a power supply is needed I'd say something like: A single stand-alone or modular unit which forwards frames of data from one or more interfaces to one or more interfaces. < Bob replies: Agreed. I have reworked the discussion and included what I think is an essential reference to addressing information. Discussion: A single stand-alone or modular unit which receives frames on or more of its interfaces and then forwards them to one or more interfaces according to the addressing information contained in the frame. > -------------- 3.2.1 Unidirectional traffic Definition: Frames presented to a DUT/SUT such that the receiving and transmitting interfaces are mutually exclusive. 3.3.2 Partially meshed traffic Definition: Frames forwarded between mutually exclusive sets of input and output interfaces of a DUT/SUT. -- I'm a bit confused by this pair of definitions - they do not seem to say something different - I'm not quite sure how to change somthing to fix the definitions - in general the 3.2 section and the 3.3 sections seem to overlap and need to have some reworking and the discussions do not clarify things for me - I suggest that the Partially meshed traffic def & discussion should be worked on to clarify things ----------------- 3.2.1 Unidirectional traffic Discussion: I think the discussion could be clarified to some degree - I took a cut at part of it It is useful to distinguish traffic orientation and traffic distribution when considering traffic patterns used in device testing. Unidirectional traffic, for example, is traffic orientated in a single direction between mutually exclusive sets of source and destination interfaces of a DUT/SUT. Such traffic, however, can be distributed between interfaces in different ways. When traffic is sent to two or more interfaces from an external source and then forwarded by the DUT/SUT to a single output interface the traffic orientation is unidirectional and the traffic distribution between interfaces is many-to-one. Traffic can also be sent to a single input interface and forwarded by the DUT/SUT to two or more output interfaces to achieve a one-to-many distribution of traffic. -- Such traffic distributions can also be combined to test for head of line blocking or to measure forwarding rates and throughput when congestion control is active. -- the See Also section should include 3.7.3 Head of line blocking and 3.7 Congestion control ------------------ 3.2.2 Bidirectional traffic Definition: Frames presented to a DUT/SUT such that the interfaces of the DUT/SUT both receive and transmit. -- I'd change just a bit Frames presented to a DUT/SUT such that each of the interfaces of the DUT/SUT both receive and transmit. ------------------- 3.2.2 Bidirectional traffic Discussion: This definition conforms to the discussions in sections 14 and 16 of RFC 1944 on bidirectional traffic and multi-port testing. Bidirectional traffic MUST be offered when measuring throughput on full duplex interfaces of a switching device. -- all RFCs wich use the terms like "MUST" "MAY" etc should now contain a reference to RFC 2119 - the exact form of the reference is in the RFC -------------------- 3.3.3 Fully meshed traffic It should be noted that bidirectional multi-port traffic can load backbone connections linking together two switching devices more than meshed traffic. -- it would be nice to expand on this a bit ---------------------- 3.3.3 Fully meshed traffic Bidirectional meshed traffic on half duplex interfaces is inherently bursty since interfaces must interrupt transmission whenever they receive frames. This kind of bursty meshed traffic is characteristic of real network traffic and can be advantageously used to diagnose a DUT/SUT by exercising many of its component parts simultaneously. Additional inspection may be warranted to correlate the frame forwarding capacity of a DUT/SUT when offered meshed traffic and the behavior of individual elements such as input or output buffers, buffer allocation mechanisms, aggregate switching capacity, processing speed or medium access control. -- it might be good to add that analysis of the results of such tests can present a chalenge since you need to take into account the actual rate at which data was presented to the DUT/SUT rather than just the rate that the tester attempted to send. (i.e. the offered vs intended load) - the see also should point to them ----------------------- 3.4.2 Burst size Discussion: Burst size can range from one to infinity. In unidirectional traffic there is no theoretical limit to burst length. -- I'd tweak this a bit Burst size can range from one to infinity. In unidirectional traffic and in bidirectional or meshed bursts on full duplex interfaces there is no theoretical limit to burst length. ----------------------- 3.4.3 Inter-burst gap (IBG) Bidirectional and meshed traffic are inherently bursty since interfaces share their time between receiving and transmitting frames. External sources offering bursty traffic for a given frame size and burst size must adjust the inter-burst gap to achieve a specified rate of transmission. -- I'd tewak this a bit External sources offering bursty traffic for a given frame size and burst size must adjust the inter-burst gap to achieve a specified average rate of frame transmission. ----------------------- 3.5.1 Intended load (Iload) In the case of Ethernet an external source of traffic must implement the truncated binary exponential back-off algorithm to ensure that it is accessing the medium legally. -- I'd change the "must" to "MUST" the See Also should include references to the burst & interburst gap sections ------------------------ 3.5.2 Offered load (Oload) I'd also note that analysis of testing where offered ~= intended must that the difference into account ----------------------- 3.5.4 Overloading I'd add that information obtained through this type of test can present opportunities for abuse by marketeers ----------------------- 3.7 Congestion control I'd also note the dificulity of understanding performance results in devices that include congestion control --------------------- 3.7.3 Head of line blocking Definition: Frame loss observed on an uncongested output interface whenever frames are received from an input interface which is also attempting to forward frames to a congested output interface. -- not just loss, also added delay --------------------- 3.10.1 Broadcast forwarding rate Definition: The number of broadcast frames per second that a DUT/SUT can be observed to deliver to all interfaces located within a broadcast domain in response to a specified offered load. -- I'd tweak The number of broadcast frames per second that a DUT/SUT can be observed to deliver to all interfaces located within a broadcast domain in response to a specified offered load of frames to the broadcast MAC address. what about multicast? ----------------------- 4. Security Considerations This document raises no security issues. -- the iesg will no longer OK RFCs that have this type of Security Considerations section - it need to say things like Documents of this type do not directly effect the security of the Internet or of corporate networks as long as testers implementing tests of this type are not connected to operating networks. The document points out that switching devices may violate the IEEE 802.3 standard by transmitting frames below the minimum interframe gap or unfairly accessing the medium by inhibiting the backoff algorithm. Although such violations do not directly engender breaches in security, they may perturb the normal functioning other interworking devices by obstructing their access to the medium. Scott Bob   Received: from cnri by ietf.org id aa16823; 30 Jul 97 10:19 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA24534 for ; Wed, 30 Jul 1997 10:18:09 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id HAA12599 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id HAA28545 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id KAA13314; Wed, 30 Jul 1997 10:00:00 -0400 for bmwg-outgoing Received: from mailhost1.BayNetworks.COM (ext-ns2.baynetworks.com [134.177.3.16]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id JAA13308; Wed, 30 Jul 1997 09:59:59 -0400 for Received: from ietf.org (ietf.org [132.151.1.19]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with SMTP id GAA11943; Wed, 30 Jul 1997 06:59:57 -0700 (PDT) for Posted-Date: Wed, 30 Jul 1997 06:59:57 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa07939; 30 Jul 97 9:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: bmwg@baynetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-secperf-00.txt Date: Wed, 30 Jul 1997 09:38:38 -0400 Message-ID: <9707300938.aa07939@ietf.org> Sender: owner-bmwg@baynetworks.com Precedence: bulk --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 Terminology for Network Security Devices Author(s) : D. Newman, H. Holzbaur, J. Hurd, S. Platt Filename : draft-ietf-bmwg-secperf-00.txt Pages : 16 Date : 07/29/1997 Despite the rapid rise in deployment of network security devices such as firewalls and authentication/encryption products, there is no standard method for evaluating the performance of these devices. Internet-Drafts are 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-secperf-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-secperf-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-secperf-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970729163656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-secperf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-secperf-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729163656.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa16835; 30 Jul 97 10:19 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA24536 for ; Wed, 30 Jul 1997 10:18:30 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id HAA12636 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id HAA28550 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id KAA13530; Wed, 30 Jul 1997 10:00:32 -0400 for bmwg-outgoing Received: from mailhost1.BayNetworks.COM (ext-ns2.baynetworks.com [134.177.3.16]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id KAA13515; Wed, 30 Jul 1997 10:00:31 -0400 for Received: from ietf.org (ietf.org [132.151.1.19]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with SMTP id HAA11990; Wed, 30 Jul 1997 07:00:28 -0700 (PDT) for Posted-Date: Wed, 30 Jul 1997 07:00:28 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa07955; 30 Jul 97 9:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: bmwg@baynetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-lanswitch-06.txt Date: Wed, 30 Jul 1997 09:38:41 -0400 Message-ID: <9707300938.aa07955@ietf.org> Sender: owner-bmwg@baynetworks.com Precedence: bulk --NextPart A Revised 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 Terminology for LAN Switching Devices Author(s) : B. Mandeville Filename : draft-ietf-bmwg-lanswitch-06.txt Pages : 25 Date : 07/29/1997 This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. Although it might be found useful to apply some of the terms defined here to a broader range of network interconnect devices, this document primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It defines terms in relation to the traffic put to use when benchmarking switching devices, forwarding performance, latency, address handling and filtering. Internet-Drafts are 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-lanswitch-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-lanswitch-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-lanswitch-06.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970729164453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-lanswitch-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-lanswitch-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729164453.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa10341; 31 Jul 97 10:21 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA28548 for ; Thu, 31 Jul 1997 10:19:34 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id HAA28783 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id HAA08357 Posted-Date: Thu, 31 Jul 1997 07:15:40 -0700 (PDT) Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id KAA03034; Thu, 31 Jul 1997 10:12:11 -0400 for bmwg-outgoing Received: from pestilence.engeast (pestilence [192.32.180.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA03027; Thu, 31 Jul 1997 10:12:10 -0400 for Date: Thu, 31 Jul 1997 10:12:10 -0400 From: Kevin Dubray Message-Id: <199707311412.KAA03027@pobox.engeast.BayNetworks.COM> To: bmwg@engeast Subject: Cell/Call Draft Discussion Sender: owner-bmwg@baynetworks.com Precedence: bulk Colleagues, Due to a forseen event, the Cell/Call Draft will not be revised for the Munich BMWG meeting; this item will be be dropped from the meeting's agenda. -Kevin   Received: from cnri by ietf.org id aa22985; 31 Jul 97 18:00 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA00492 for ; Thu, 31 Jul 1997 17:59:26 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id OAA23541 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id OAA15276 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id RAA08320; Thu, 31 Jul 1997 17:54:53 -0400 for bmwg-outgoing Received: from mailhost.BayNetworks.COM (addme [134.177.1.107]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id RAA08314; Thu, 31 Jul 1997 17:54:52 -0400 for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id OAA12582 Posted-Date: Thu, 31 Jul 1997 14:54:49 -0700 (PDT) Received: from pestilence.engeast (pestilence [192.32.180.194]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA08311; Thu, 31 Jul 1997 17:54:49 -0400 for From: Kevin Dubray Message-Id: <199707312154.RAA08311@pobox.engeast.BayNetworks.COM> Subject: Re: bmwg timetable To: bmwg@baynetworks.com Date: Thu, 31 Jul 1997 17:47:26 -0400 (EDT) Cc: mo@uu.net, jcurran@bbn.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-bmwg@baynetworks.com Precedence: bulk > > Kevin, > > Today's IETF agenda lists only one hour for the bmwg > session in Munich. Is that correct > Partially. In order to accommodate for more WG sessions, the IETF Secretariat provided for shorter (hour-long) sessions on Tuesday. To avoid, conflicts with other related WGs, we were given 2 consecutive, one-hour slots. The BMWG will meet Tuesday, 12 August, from 1300 to 1515h. There won't be an intermission. ;-) -Kevin