From ntdp-bounces@ietf.org Fri Jun 16 22:30:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQZd-0007wD-LF; Fri, 16 Jun 2006 22:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQZc-0007w8-Ji for ntdp@ietf.org; Fri, 16 Jun 2006 22:30:08 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrQZZ-00020J-4r for ntdp@ietf.org; Fri, 16 Jun 2006 22:30:08 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 17 Jun 2006 08:23:14 -0700 X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="69202768:sNHT35001040" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5H2Rp6D007542 for ; Sat, 17 Jun 2006 10:27:52 +0800 (CST) Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jun 2006 10:30:00 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Jun 2006 10:29:59 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introduction to NTDP Thread-Index: AcaRte36dyWIWuAvQwORo8a6Vv3Yiw== From: "Craig Brown \(crbrown\)" To: X-OriginalArrivalTime: 17 Jun 2006 02:30:00.0921 (UTC) FILETIME=[EEDD0C90:01C691B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [NTDP] Introduction to NTDP X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: define standards for the purpose of scripting of network testing equipment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntdp-bounces@ietf.org Reposting to this new alias. 1. Introduction This initiative is to create a protocol for the automatic control of devices that generate and analyze traffic and/or emulate network protocols for the testing of a network or a specific network device. To perform either network or a network device specific testing, a tester will use a product to generate traffic, emulate routing protocols and emulate network end points, such as a network host or HTTP client. This product is referred to as a network testing device (NTD). The term network testing device should not be confused with the term device under test (DUT). In fact, the network testing device will most likely support the generation and analysis of traffic to validate the performance, scalability, etc of a device under test. Traffic generation can be defined as the sending of stateless traffic, traffic analysis can be defined as the analysis of received packets for some set of measurements, and protocol emulation can be defined as the emulation of one/many devices/applications. This might include, for example, emulation of a router for sending and receiving of routing protocol updates, emulation of a user generating HTTP traffic or making a IP call, or emulation of a device generating security breaches such as malicious attacks. Automatic control is defined as the unattended operation of a test device in a specific manner such that particular traffic is generated/analyzed and particular protocols are emulated. Consider the example of a testbed that is testing network protocols, generating some typical layer 4-7 traffic, placing a call and sending voice traffic, and injecting malicious attacks for security testing. For this example, there is potentially one device for generating the routing protocol traffic, several devices for the emulating clients/ server traffic, one device for the emulating voice traffic, and one device for the generating security testing. Today, the tester must learn the scripting commands for each generation/emulation device, develop separate scripts to manage each those devices, and combine the results of the various tools into one view. This protocol is not intended for the management of the devices within the network. Specifications such as NETCONF, for device configurations are already focused on that area. The purpose of this alias is to discuss the current issues that need resolving and propose a general direction that a new Working Group would move towards. The intention is not to produce an overall solution and explain the intricacies of a design. Some areas will be intentionally left unexplained because that will be the purpose of the proposed Working Group to resolve. 1.1. Existing API specification The history behind what started the creation of this alias is that approximately four years ago, Cisco and several vendors started developing a specification that defined a common API. The purpose of this API was to provide the tester with the ability to control various network testing devices using a standard set of commands. This project has been relatively successful but because of legal constraints, distribution of the API has been limited. The experience has shown us that the concept works but also showed several pitfalls that would be avoided with an improved architectural design. The specification consists of several groupings: session, traffic, and routing protocol APIs. Each protocol has the actions of config, control, info, and stats and to shorten the list below these names have been replaced by one listing with the term action. * Session APIs connect interface_action alarms cleanup_session * Traffic APIs traffic_control * Routing Protocol APIs bgp_action dhcp_action igmp_action isis_action ldp_action l2tp_action mld_action msdp_action multicast_action ospf_action pim_action ppp_action pppox_action rip_action rsvp_action rsvpte_action There is a group working to develop the command sets for layer 4 to 7 starting with the protocols HTTP, FTP, and Telnet. The issues that we found in developing this API and would like to avoid in the creation of a protocol are: A software abstraction layer was required about the API because the variances in implementation by each vendor. The variances occurred because the API was developed on top of the vendor's existing API and therefore there was an additional level of translation from the common API to the proprietary API. Every parameter that was offered by the vendors was placed into the specification. This created a large document which, as it continues to grow, becomes daunting for the tester to interpret. Also, as each vendor does not implement all the parameters, the tester is required to be knowledgeable about each vendor's implementation. The software abstraction layer helps resolve some of this problem - but not completely. Having the ability to learn the capabilities of the device would greatly assist in this problem. Implementation time of the common API lagged behind the implementation of a feature. Testers were able to use the vendor's libraries and GUI when a new feature was available but had to wait for the API specification and for the vendor implementation of that specification. This reduced the incentive for the testers to use the common API and then increased the issues of script portability. The specification was not originally designed for performance and scalability and therefore created testing issues. The eventual design for this specification will include the objective of performance and scalability and with the ability to scale downward to smaller functional testing requirements. 1.1.1. Coding Example This example shows some basic commands used to connect to a device, configure the interface, configure a routing protocol, configure traffic, and disconnect from the device. # Connect to Vendor A vendorA::connect -device 10.1.1.1 -username Craig -port_list {104/1 104/2} # Port handles are returned from the connect command and used for subsequent referencing. # In this example, the port handle is the same as the port name # Configure the port interface vendorA::interface_config -port_handle 104/1 -mode config -intf_ip_addr 10.10.10.2 \ -intf_mode ethernet -netmask 255.255.255.0 -gateway 10.10.10.1 # Create the DHCP emulation port set dhcp_ret [vendorA::emulation_dhcp_config -port_handle 1 -mode create -outstanding_sessions 1] if { [keylget dhcp_ret status] !=3D 1 } {error "Failed to config handle"} set dhcpgrp_ret [vendorA:emulation_dhcp_group_config -handle dhcp_ret \ -mode create -encap ethernet_ii_qinq \ -num_sessions 5 -mac_addr 00.10.95.11.12 -mac_addr_step 0.0.0.0.0.1 \ -vlan_id_outer 1 -vlan_id_step_outer 1 -vlan_id_counter_outer 2 \ -vlan_id 10 -vlan_id_step 1 -vlan_id_count 1 ] if { [keylget dhcpgrp_ret status ] !=3D 1 } {error -Failed to = configure DHCP group?} # Control of the dhcp group, bind all configured groups on the dhcp_ret port handle set dhcpctrl_ret [vendorA::emulation_dhcp_control -port_handle dhcp_ret -action bind] if { [keylget dhcpctrl_ret status] !=3D 1 } { error -Failed to bind DHCP?} # Traffic config using DHCP resolved address information in "normal" mode vendorA::traffic_control -port_handle 1 -mode create -l2_encap ethernet_ii_qinq \ -traffic_src_no 1 \ -dhcp_link 1 \ -dhcp_link_groups 1 \ -mac_src_mode dhcp_emulation \ -mac_dst 00.10.95.22.11.09 \ -l3_protocol ipv4 \ -ip_dst_addr 192.162.2.1 \ -ip_dst_step 0.0.0.1 \ -ip_dst_count 2 # Disconnect from the device vendorA::cleanup_session -port_handle {104/1 104/2} 2. Technology Overview There appears to be some overlap with other standards in the areas of communicating with the test device. To illustrate how NTDP may work, we will use the NETCONF Architecture as a baseline. Layer Example +-------------+ +-----------------------------+ | Content | | Data Structures | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ Similar to NETCONF, we propose a similar transport layer with perhaps a different set of operations commands. The data structures would be divided in categories based on the technologies. For example, the data structure for configuring HTTP will be different from SIP, as would the routing protocols. As we progress in this discussion the topics will include areas such as: - protocols (there's a number of these...) - traffic generation and analysis - infrastructure (chassis connection, alarms, capture buffer, etc.) - syntax rules (general syntactical structure of the protocol, transport layer or transport layer independence, etc.) I hope this begins to clarify the intent and look forward to many discussions. =20 Regards, Craig _______________________________________________ NTDP mailing list NTDP@ietf.org https://www1.ietf.org/mailman/listinfo/ntdp From ntdp-bounces@ietf.org Thu Jun 22 16:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWGN-0008Rq-N3; Thu, 22 Jun 2006 16:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWGL-0008MV-Ll for ntdp@ietf.org; Thu, 22 Jun 2006 16:58:53 -0400 Received: from 64-30-208-245.dsl.linkline.com ([64.30.208.245] helo=ameritec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWGK-0003FH-2Q for ntdp@ietf.org; Thu, 22 Jun 2006 16:58:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 22 Jun 2006 13:58:45 -0700 Message-ID: <64E292383724EA4C84A339DAD98C18F799356C@prime.SBS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Goal clarification thread-index: AcaWPqbx82ZpTNkRTWSx1DW1YHYGgQ== From: "John Zaharychuk" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [NTDP] Goal clarification X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: define standards for the purpose of scripting of network testing equipment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369041595==" Errors-To: ntdp-bounces@ietf.org This is a multi-part message in MIME format. --===============1369041595== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6963E.A81499DF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6963E.A81499DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Morning, =20 I have read through the introductory details posted by Craig and they raise a few points that I would like to discuss. =20 The example testbed described utilizes four different devices to generate the combined test traffic required for the test. Each of these devices generates a different type (or types) of traffic. While I can see a desire to have common commands and scripts across devices that perform identical functions, I am less clear as to how commonality can be achieved across different services. The configuration data for a Voice Call and the collection of MOS metrics is different than the configuration data for an FTP file transfer and the collection of throughput metrics. These differences are independent of the fact that different devices are being used. The same differences would exist if a single superset device was used. Granted, each device that connects to the network shares some common network configuration, but it is the service configuration where the complexity lies.=20 =20 Maybe the goal is to create a common "form" or syntax for the configuration data across both services and devices. It could shorten the learning curve for the tester, but would not eliminate the need to understand the different services and metrics. =20 I look forward to a better understanding and further discussions. =20 JZee =20 "This e-mail and any files transmitted with it are confidential and are for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege or by state or federal laws protecting trade secrets and/or Company Confidential Proprietary information. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mailing error and that any use, dissemination, forwarding, printing, or copying this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify webmaster@ameritec.com via return e-mail." =20 =20 ------_=_NextPart_001_01C6963E.A81499DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Morning,
 
I have = read through=20 the introductory details posted by Craig and they raise a few points = that I=20 would like to discuss.
 
The = example testbed=20 described utilizes four different devices to generate the combined test = traffic=20 required for the test. Each of these devices generates a different type = (or=20 types) of traffic.  While I can see a desire to have common = commands and=20 scripts across devices that perform identical functions, I am less clear = as to=20 how commonality can be achieved across different services. The = configuration=20 data for a Voice Call and the collection of MOS metrics is different = than the=20 configuration data for an FTP file transfer and the collection of = throughput=20 metrics. These differences are independent of the fact that different = devices=20 are being used. The same differences would exist if a single superset = device was=20 used. Granted, each device that connects to the = network=20 shares some common network configuration, but it is the service = configuration=20 where the complexity lies.
 
Maybe = the goal is to=20 create a common "form" or syntax for the configuration data = across both=20 services and devices. It could shorten the learning curve for the = tester, but=20 would not eliminate the need to understand the different services and=20 metrics.
 
I look = forward to a=20 better understanding and further discussions.
 
JZee
 

"This e-mail and any files transmitted with it are = confidential and=20 are for the use of the individual or entity to whom they are = addressed.  This communication may contain = material=20 protected by the attorney-client privilege or by state or federal laws=20 protecting trade secrets and/or Company Confidential Proprietary=20 information.  If you are = not the=20 intended recipient or the person responsible for delivering the e-mail = to the=20 intended recipient, be advised that you have received this e-mailing = error and=20 that any use, dissemination, forwarding, printing, or copying this = e-mail is=20 strictly prohibited.  If = you have=20 received this e-mail in error, please immediately notify = webmaster@ameritec.com=20 via return e-mail."

 

 
------_=_NextPart_001_01C6963E.A81499DF-- --===============1369041595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NTDP mailing list NTDP@ietf.org https://www1.ietf.org/mailman/listinfo/ntdp --===============1369041595==-- From ntdp-bounces@ietf.org Fri Jun 23 02:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfNz-0004f7-OY; Fri, 23 Jun 2006 02:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfNy-0004OG-Pm for ntdp@ietf.org; Fri, 23 Jun 2006 02:43:22 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtfHb-0008Id-7g for ntdp@ietf.org; Fri, 23 Jun 2006 02:36:50 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 23 Jun 2006 12:31:19 -0700 X-IronPort-AV: i="4.06,168,1149490800"; d="scan'208"; a="69654895:sNHT32532624" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5N6ah6D013425; Fri, 23 Jun 2006 14:36:43 +0800 (CST) Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jun 2006 14:36:42 +0800 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: [NTDP] Goal clarification Date: Fri, 23 Jun 2006 14:36:42 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NTDP] Goal clarification Thread-Index: AcaWPqbx82ZpTNkRTWSx1DW1YHYGgQABD6Ow From: "Craig Brown \(crbrown\)" To: "John Zaharychuk" , X-OriginalArrivalTime: 23 Jun 2006 06:36:42.0919 (UTC) FILETIME=[64053370:01C6968F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: define standards for the purpose of scripting of network testing equipment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntdp-bounces@ietf.org JZee, Your right that there will not be commonality across all technologies and to use your term "the goal is to create a common "form" or syntax for the configuration data across both services and devices". There are two parts to this problem; first is the transport layer to communicate with the device and the second is the appropriate data structure/form/syntax to use. The transport layer shouldn't be that difficult because there are already plenty of groups working on similar tasks. The data structure becomes the challenge, and more so how the application that is communicating to the device, using NTDP, interprets what it sends and gets back.=20 The thoughts behind the data structure section can be related to how we view the device. To setup the traffic generation, my view is that I (being the tester) am required to configure characteristics. For HTTP, I would define a user's behavior such as the type of browser, whether cookies are enabled, http version, etc. There may be several different user profiles created. I would then associate how many of iterations of userA will begin over period n. For routing protocols, the characteristics of BGP would be whether to advertise routes, AS number, etc and the associated load then defines how much that profile performs functions such as link flapping, etc. And for voice, the characteristics would be the type of phone SIP, Skinny, H.323, and the variety of capabilities. The association is how many calls to place, put on hold, etc. This is a rough example of defining the characteristics and the associated load generation. The point here is that if we can agree on how the tester interacts with the devices, then the data models should become clearer.=20 Based off our previous experience with routing protocols, here is the structure that we used including the HELLO message (which doesn't exist in our API). This is provided as an example of how we currently group our functions. 1. HELLO -> contact the device <- receive device info including capabilities 2. INFO -> request specific information regarding: i. device hardware ii. device software iii. Feature specific capabilities 3. CONFIGURE -> configuration details (Define the characteristics) i. Device - interface ii. Protocol iii. Client iv. Network - L2 / L3 4. CONTROL -> control the environment (Define the associations and load) i. Traffic ii. Alarms iii. Protocols iv. Clients 5. STATS -> return statistics i. Device - interface ii. Protocols 6. DISCONNECT In this example the commonality is the structure and the data models overlay it. Let's assume the data model falls into place, the bigger issue is then how the tester discovers what is implemented per device and how to interpret extensions to the data model. We can use a HELLO message that returns the device capabilities and features supported. And an INFO requests the detailed capabilities of a supported feature, the arguments supported, and also the details of any vendor extended arguments.=20 But, let's say I send a HELLO message and receive that this device is vendorA and supports BGP, OSPF, and DHCP. I send an INFO message for BGP details and find that this device has version 1.2 of the specification implemented and that the features supported are A, B, and C. My application will then load the v1.2 data structure and understand if any capabilities are missing. This device also returns a flag indicating a vendor extension.=20 How does the application understand what the extension provides? What is meant by an application? In this situation, the term application is being to used to define the program that sends and receives the NTDP messages. This program may be existing vendor APIs, a tester's script, appl. from the open source community, etc. I cannot imagine that a tester would write a script to manage this environment but an tester's company may.=20 Today, some vendors provide APIs to control their devices and these APIs could remain the same and use the new format behind the scenes. Because the vendor knows what there extensions are then they can operate without much confusion. This solves the immediate problem of an existing user base but does not solve the problem that we are trying to achieve which as you say is "to shorten the learning curve for the tester"; the reason is that the tester still ends up using the proprietary API. This is another problem that needs to be discussed further.=20 Not sure if I answered your questions or just raised more of them ;) Cheers, Craig ________________________________ From: John Zaharychuk [mailto:JohnZ@ameritec.com]=20 Sent: Friday, June 23, 2006 6:59 AM To: ntdp@ietf.org Subject: [NTDP] Goal clarification =09 =09 Morning, =20 I have read through the introductory details posted by Craig and they raise a few points that I would like to discuss. =20 The example testbed described utilizes four different devices to generate the combined test traffic required for the test. Each of these devices generates a different type (or types) of traffic. While I can see a desire to have common commands and scripts across devices that perform identical functions, I am less clear as to how commonality can be achieved across different services. The configuration data for a Voice Call and the collection of MOS metrics is different than the configuration data for an FTP file transfer and the collection of throughput metrics. These differences are independent of the fact that different devices are being used. The same differences would exist if a single superset device was used. Granted, each device that connects to the network shares some common network configuration, but it is the service configuration where the complexity lies.=20 =20 Maybe the goal is to create a common "form" or syntax for the configuration data across both services and devices. It could shorten the learning curve for the tester, but would not eliminate the need to understand the different services and metrics. =20 I look forward to a better understanding and further discussions. =20 JZee =20 "This e-mail and any files transmitted with it are confidential and are for the use of the individual or entity to whom they are addressed. This communication may contain material protected by the attorney-client privilege or by state or federal laws protecting trade secrets and/or Company Confidential Proprietary information. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mailing error and that any use, dissemination, forwarding, printing, or copying this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify webmaster@ameritec.com via return e-mail." =20 _______________________________________________ NTDP mailing list NTDP@ietf.org https://www1.ietf.org/mailman/listinfo/ntdp From ntdp-bounces@ietf.org Wed Jun 28 05:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWgc-0007Qt-Ig; Wed, 28 Jun 2006 05:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWgb-0007Qo-Gj for ntdp@ietf.org; Wed, 28 Jun 2006 05:50:17 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvWgZ-00031N-QE for ntdp@ietf.org; Wed, 28 Jun 2006 05:50:17 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 28 Jun 2006 15:45:56 -0700 X-IronPort-AV: i="4.06,187,1149490800"; d="scan'208,217"; a="69982059:sNHT52288068" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5S9oB6D018604 for ; Wed, 28 Jun 2006 17:50:12 +0800 (CST) Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jun 2006 17:50:11 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jun 2006 17:50:09 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting plan Thread-Index: AcaamD3p26+TJlERTmuRcJGPtPmjkQ== From: "Craig Brown \(crbrown\)" To: X-OriginalArrivalTime: 28 Jun 2006 09:50:11.0317 (UTC) FILETIME=[3F3AEA50:01C69A98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [NTDP] IETF Meeting plan X-BeenThere: ntdp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: define standards for the purpose of scripting of network testing equipment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1526544032==" Errors-To: ntdp-bounces@ietf.org This is a multi-part message in MIME format. --===============1526544032== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69A98.3F1E0525" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69A98.3F1E0525 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 For those attending the next IETF meeting in Montreal, we will be holding a bar-BOF to discuss the goals and design for the NTDP I-D. Always looking for a reason to have a beer, we will have the meetings on both Tuesday and Wednesday night to provide the opportunity to fit into everyone's different schedules. The planned time will be 7pm and once we get to Montreal, I will announce the closest location to the conference. =20 If you plan to attend or want to catch up, drop me an email. =20 Cheers, Craig ------_=_NextPart_001_01C69A98.3F1E0525 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
For = those attending=20 the next IETF meeting in Montreal, we will be holding a bar-BOF to = discuss the=20 goals and design for the NTDP I-D. Always looking for a reason to have a = beer,=20 we will have the meetings on both Tuesday and Wednesday night to provide = the=20 opportunity to fit into everyone's different schedules. The planned time = will be=20 7pm and once we get to Montreal, I will announce the closest location to = the=20 conference.
 
If = you plan to=20 attend or want to catch up, drop me an email.
 
Cheers,
Craig
------_=_NextPart_001_01C69A98.3F1E0525-- --===============1526544032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NTDP mailing list NTDP@ietf.org https://www1.ietf.org/mailman/listinfo/ntdp --===============1526544032==--