HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:16:41 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 07 Oct 1999 08:48:00 GMT ETag: "3ddc7e-4295-37fc5e40" Accept-Ranges: bytes Content-Length: 17045 Connection: close Content-Type: text/plain IETF Secretariat N. Bourbaki INTERNET-DRAFT IETF draft-ymbk-termroom-op-02.txt 99.10.06 IETF Meeting Network Infrastructure Lore This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 0. Abstract Creating and running the 'terminal room' for an IETF meeting is tantamount to building, running, and dismantling a small computer center. Although this is a well-known area of operations, the unique environment and its ephemeral nature warrant passing on the lore in a mildly organized fashion. It is expected that this document will be updated regularly. As the IETF can ill afford failure of these facilities, it is assumed that the host and organizers have the experience and resources to build such environments, understand power facilities, cabling, WAN and LAN building, workstation provisioning, etc. So this document does not attempt to detail how to build computer facilities or carry out prudent project management. Rather it concentrates on the unique aspects of the IETF 'terminal room'. N. Bourbaki Expires 00.04.05 [Page 1] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 1. External Network Connectivity The picky and analytic nature of a large number of IETF participants means that the connectivity and performance of that connectivity will be measured, whined about, ... Not to worry. Move the packets well, and the nit pickers will pick each other to death. 1.1 Bandwidth consumption is approximately 5kbps per attendee. So currently 10mbps of external connectivity seems sufficient. Unicast peaks at about five, and multicast at three. The addition of streaming services may require more bandwidth, especially if they are not cached off-site. 1.2 If possible, diverse physical and logical paths should be provided. It is understood that few conference centers have connectivity, let alone diversity. But it is prudent to coordinate with the ISP to get as much redundancy as reasonably possible. Redundant and diverse paths out of the local provider's POP(s) are advised when possible. 1.3 It has been suggested that multicast WAN connectivity would benefit from being separated from unicast. This has been tried and worked, though it is not believed to be necessary. 2. The Internal Network This has been the transport area of most concern at recent meetings. 2.1 As they seem to interfere with each other, at least three separately routed LAN segments SHOULD be used for the terminal room, wireless ethernet, and multicast services. In particular, the high speed multicast feed exceeds the capacity of the wireless ethernet, and therefore MUST be separate. In case multicast causes wireless problems, be prepared to keep multicast traffic off the wireless LAN. 2.2 The registration desk SHOULD be provisioned to accommodate three or four laptop users. 2.3 Two of the meeting rooms MUST be provisioned for multicasting. The IETF Secretariat will specify which shortly before setup. 2.4 A scattering of power outlets in all meeting rooms is much appreciated by laptop-based attendees, as will a few power strips in the lobby, bar, and other places laptop users congregate. N. Bourbaki Expires 00.04.05 [Page 2] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 2.5 Drops to connect the wireless ethernet base stations SHOULD be supplied at strategic locations throughout the facility. The primary targets should be large gathering areas with seating, e.g. the lobby and bar. Also all meeting rooms SHOULD have wireless coverage if at all possible. The wireless ethernet equipment that has been in use for the last few years operates on various frequencies: 915MHz and 2.4GHz. Where local communications regulations permit, both frequencies SHOULD be made available. Among the 2.4GHz family of frequencies, 2.422GHz SHOULD be used. If a different frequency is chosen, adequate notice of the operating frequency SHOULD be given. The wired-to-wireless bridges have parameters global to all bridges which SHOULD be set as follows: Domain ID: 0x1 Beacon key: 0x1E1F The wired-to-wireless bridges have parameters unique to each bridge which SHOULD be set as follows: the first location's bridge (or bridges, if multiple frequencies are in use) NWID (network ID) SHOULD be 0xAAAA; the second's 0xBBBB, the third's 0xCCCC, the fourth's 0xDDDD, and so forth. If parameter values are chosen which are different from those above, at least one week's public notice prior to the meeting SHOULD be given. For users whose laptops do not support roaming, a map detailing the location of each bridge and its associated NWID SHOULD be provided. It is assumed that attendees using wireless use end-to-end encryption or are suicidal. So the wireless network itself is run in the clear. The new 802.11 wireless is becoming more popular. There seem to be 802 different incompatible cards for it. 2.6 IETF networks have been crippled when very long ad hoc fiber runs have been inadvertently smashed by workfolk and others, and no spare cable was available. Spares should be kept, and it might be advisable to mark the runs with caution tape, etc. N. Bourbaki Expires 00.04.05 [Page 3] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 3. Network Services A lot of stress is put on DHCP, printing, and ... 3.1 Laptop users outnumber users needing desktop UNIX and/or MS- Windows platforms. Currently one terminal room 10baseT drop per 15 attendees is comfortable. 10baseT is sufficient, as 10base2 has all but disappeared. 3.2 DCHP SHOULD be provided by a very standards-conformant server. Wide or ISC DHCP running on a UNIX platform is strongly recommended until non-UNIX DHCP servers have demonstrated better compatibility. The address pool MUST be large enough to avoid shortages given constant connection churn. Some experience indicates that it is desirable to have a sufficiently large pool on standby to permit rolling over DHCP servers without making a mess. The DCHP server will likely have to serve multiple subnets. This will also require router configuration. The DHCP lease timeout must be set short enough to roll over leases quickly, while not overwhelming the network with packets attempting to renew a lease. A lease life of one hour appears to work well. Too long a lease time followed by address pool shortage has been a problem at meetings. So short lease times are recommended. 3.3 A pool of address for static assignment to laptop users without DHCP is necessary for approximately one client per 100 attendees. There SHOULD be a mechanism at the help desk to allocate and register their use. Providing for allocation by email before the meeting is kind to those with serious security issues at home. 3.4 Printer services are very like those in a small computer center. Two paper printers SHOULD be provided, and a third for spare is advisable. The printing rate is about .05 PPM / attendee, and an attendee prints approximately 15 pages during the meeting. One transparency printing facility MUST be provided. The transparency printing rate is about .01 PPM / attendee, and an attendee prints approximately 1.5 pages during the meeting. An open lpr printer is a convenience for laptop users. Non-printer transparencies MUST NOT be available, or someone will put them in a printer and ruin it. N. Bourbaki Expires 00.04.05 [Page 4] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 An alternative to a transparency printer is a copier machine with transparencies loaded. Macs and MS-Windows systems need a print spooling server, either samba- or NT-based. 3.5 The cost of transparencies and their tendency to jam printers often warrants manual queue operation. It is kind to train a local a nocturnal denizen or two in queue running to reduce whining at three in the morning. 3.6 A local SMTP server SHOULD be available for those whose home servers will not do mail forwarding for clients with strange DNS names and/or unknown addresses. 3.7 A local NTP server SHOULD be available to serve ntpdate requests for users and to chime with locals who wish NTP peering. 3.8 Consider splitting the UNIX server functions over more than one machine. Print spooling or X duty may bog down a single server. Consider one server for print queue and Xhost, another for DHCP and SMTP relay and DNS caching. Isolate the critical and non- critical server functions on different machines so a non-critical function, like print queuing, if it stalls or hangs the machine, won't stop DHCP and DNS. 3.9 The help desk SHOULD be staffed from early morning to late evening by people of patience and clue. As many attendees are rather experienced, their questions can be rather technical. Of course, like the typical user population, they also have less sophisticated needs and temperaments. An emergency contact number SHOULD be available when the help desk is not staffed. 3.10 A small stash of office supplies such as staplers, tape, markers, etc. is often much appreciated. It has been suggested that a lively market could develop in RJ4x adapters, RJ11 kits, AC plug converters, local phone to RJ11 adapters, etc. Small ether hubs have also proven useful. 3.11 While it is tempting for a host/vendor to show off fancy technology at an IETF, this audience runs and uses the most arcane assortment of services, and is a very poor place to find out that your fancy new switch breaks when someone tries to run IPv42 through it. Run a simple production network. N. Bourbaki Expires 00.04.05 [Page 5] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 4. Computer Systems There seems to be a general preference for both UNIX and MS-Windows platforms, though there have been successful terminal rooms with only one or the other. Many users are agnostic. But UNIX and Linux bigotry is increasing, and some folk need Microsoft Office to prepare presentations. Approximately one workstation per twenty attendees seems comfortable. Some months before the meeting, the IETF Secretariat gives the local host an estimate of the number of attendees. 4.1 The software needed on all desktops MUST be at least the following: a web browser and an ssh client. X-Windows is desirable on MS-Windows hosts, and contributes to OS indifference. 4.2 A dozen desktops with MS-Windows and presentation tools SHOULD be provided for those very few working on presentations at the last moment in full panic. These SHOULD have floppy drives for folk who must use sneaker-net. 4.3 Air conditioning for the terminal room SHOULD be sufficient for the time of year, the heat load from the machines, and a lot of people. 5. Documentation As the users' needs mature, so do their expectations of documentation. 5.1 Some weeks before the meeting, the network prefixes to be used SHOULD be announced on the IETF list. This allows users with security issues to have their home networks adjusted if necessary. 5.2 A single-page document SHOULD be included in the attendees' registration packets explaining the network layout, addressing, workstation facilities, printing facilities, etc. 5.3 A short presentation is usually given at the opening session. 5.4 A full on-site mirror of the RFC and I-D directories will lower demand on the circuits as well as the associated servers. The address of the mirror should be stated loudly in all documentation. N. Bourbaki Expires 00.04.05 [Page 6] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 6. Security Considerations As in most computer facilities, physical as well as network security is important. 6.1 Physical security is difficult, with attendees walking in and out with laptops and other gear at all hours. The guards SHOULD be told to expect strange things, but to not let large equipment walk out without a green badge. 6.2 Network security is traditional, see the Site Security Handbook [RFC2196]. The IETF network has been attacked from the outside a number of times. 6.3 Secure on-site storage for boxes and equipment makes life a lot easier. 7. Prudence Spares of all critical components, workstations, switches, routers, etc. SHOULD be on-site. "A fool and their data are soon parted." -- M Williams 8. References [RFC2196] Site Security Handbook. B. Fraser. September 1997. 9. Acknowledgments The author is indebted for very constructive contributions by a num- ber of IETF local hosts, the IETF Secretariat, a NANOG local host, some operators of large networks, a Dutch geek, and of course Mr. (sorreeee) Wireless. 10. Author's Address N. Bourbaki 666 Rue le Jour Sophia-Antipolis nbourbaki@ops.ietf.org 11. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. N. Bourbaki Expires 00.04.05 [Page 7] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.10.06 12. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. N. Bourbaki Expires 00.04.05 [Page 8]