IETF Secretariat N. Bourbaki INTERNET-DRAFT IETF draft-ymbk-termroom-op-00.txt 99.06.16 IETF Meeting Network Infrastructure Lore Copyright (C) The Internet Society (1999). All Rights Reserved. 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, 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 99.12.16 [Page 1] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.06.16 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 with 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. 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 ISP's POP 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, radio modems, and multicast. In particular, the high speed multicast feed exceeds the capacity of the radio modems, and therefore MUST be separate. 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. 2.5 Drops to connect the radio modem 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 radio coverage if at all possible. N. Bourbaki Expires 99.12.16 [Page 2] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.06.16 3. Network Services A lot of stress is put on DHCP, printing, and ... 3.1 Laptops 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. 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 are needed, 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 printer is also needed. The transparency printing rate is about .01 PPM / attendee, and an attendee prints approximately 1.5 pages during the meeting. Macs and MS-Windows systems need a 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 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. N. Bourbaki Expires 99.12.16 [Page 3] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.06.16 3.7 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.8 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 RJ48 adapters, RJ11 kits, etc. 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 is minimally: 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 is needed by those very few working on presentations at the last moment in full panic. 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 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. N. Bourbaki Expires 99.12.16 [Page 4] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.06.16 5.2 A single-page document is 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. 6. Security Considerations As in most computer facilities, physical as well as network security are important. 6.1 Physical security is difficult, with attendees walking in and out with laptops and other gear at all hours. The hired 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. References [RFC2196] Site Security Handbook. B. Fraser. September 1997. 8. Acknowledgments The author is indebted to a number of previous local hosts, the IESG Secretariat, a NANOG local host, and some operators of large networks. 9. Author's Address N. Bourbaki 666 Rue de Folie Sophie Antibes nbourbaki@ops.ietf.org N. Bourbaki Expires 99.12.16 [Page 5] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 99.06.16 10. 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. 11. 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 developing 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 99.12.16 [Page 6]