idnits 2.17.1 draft-odonoghue-netrqmts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 08, 2019) is 1746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. O'Donoghue 3 Internet-Draft IETF NOC Team 4 Intended status: Informational July 08, 2019 5 Expires: January 9, 2020 7 IETF Meeting Network Requirements 8 draft-odonoghue-netrqmts-01 10 Abstract 12 The IETF Meeting Network has become integral to the success of any 13 physical IETF meeting. Building such a network, which provides 14 service to thousands of heavy users and their multitude of devices, 15 spread throughout the event venue, with very little time for setup 16 and testing is a challenge. This document provides a set of 17 requirements, derived from hard won experience, as an aid to anyone 18 involved in designing and deploying such future networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. External Connectivity . . . . . . . . . . . . . . . . . . . . 3 57 3. Meeting Facility . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Internal Network . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Terminal Room or equivalent . . . . . . . . . . . . . . . . . 5 60 6. Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 6 63 9. Miscellaneous Requirements . . . . . . . . . . . . . . . . . 7 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 13. Revision comments . . . . . . . . . . . . . . . . . . . . . . 8 68 14. Normative References . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The IETF Meeting Network has grown and evolved over time as has the 74 IETF overall. In addition, the way that the IETF network is built 75 and provisioned has also changed. It is time for the IETF community 76 to consider the requirements of this infrastructure and its role in 77 supporting the mission of the IETF. This document is meant to help 78 frame that conversation. Additionally, this document may eventually 79 be developed to be useful to others outside the IETF in specifying 80 and building their own successful event networks. 82 This document is currently being revised as part of an IETF community 83 discussion on the network requirements for the IETF meeting network. 84 Version -00 represents the requirements as articulated the last time 85 these requirements was documented by the IETF NOC Team 86 (https://www.ietf.org/how/meetings/admin/meeting-network- 87 requirements/). The current draft plan is to update to a -01 that 88 represents the requirements the IETF NOC Team currently builds to. 89 Versions beyond that will represent input received from the 90 community. A final version of this document may or may not be 91 published depending on the desires of the IETF community and the 92 potential usefulness of a document of this sort outside the scope of 93 the IETF. 95 1.1. Terminology 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 99 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 100 [RFC2119]. 102 2. External Connectivity 104 o A primary and backup link MUST be provided for redundancy. If 105 technically feasible, these links SHOULD be aggregated or load 106 balanced. 108 o The primary and backup links MUST provide at least 1 Gbps 109 bandwidth in both directions. 111 o Recent events have peaked at roughly 850 Mbs and averaged in the 112 100-300 Mbps range. 114 o The backup link SHOULD be supplied by a different Internet service 115 provider from the primary link. 117 o The primary and backup links SHOULD have physical and logical path 118 diversity. 120 o IPv6 MUST be provided. 122 o The transit provided in support of the IETF MUST be capable of 123 providing access to the IPv4 and IPv6 default free zones without 124 the imposition of content filtering (e.g., URL, Site, application, 125 port, or DPI based filtering). 127 o The primary and secondary links MUST support BGP peering. 129 o The provider(s) MUST allow the IETF to advertise (from the IETF AS 130 number) the IETF IPv4 and IPv6 address ranges. 132 o The provider(s) MUST implement IRR (or better) route filtering. 134 o The provider(s) SHOULD carry and advertise full BGP tables. 136 o The provider(s) SHOULD implement BGP communities, especially the 137 ability to RTBH. 139 3. Meeting Facility 141 o The meeting facility SHOULD have physical characteristics that 142 support the deployment of additional wireless networks including 143 techniques to limit interference where possible (?? or something 144 along those lines). 146 o The meeting facility SHOULD have installed network cabling that 147 can be used to deploy the network infrastructure. (?? is this a 148 should or must, are we past the days of running cable if we need 149 to... ) 151 o The meeting facility SHOULD provide the network installation team 152 with 24 hour access to key telecom spaces. The meeting facility 153 MUST provide the network installation team with access to key 154 telecom spaces from one hour prior to the beginning of sessions to 155 one hour after the end of sessions and 9am to 5pm daily during the 156 setup period. (?? are these the right timeframes) 158 o All locations for network gear, with the exception of wireless 159 APs, MUST be secure. 161 o If wireless will be used for an external link then access to the 162 roof or installed location MUST be provided. 164 o The meeting facility MUST have adequate ventilation to support the 165 equipment rooms and the terminal room. 167 o The meeting facility MUST have adequate power available to support 168 the equipment required to support the network infrastructure and 169 its users. This may include 110v/220v requirements in technical 170 closets, roof locations, and various public and back-of-the-house 171 areas. 173 o The meeting facility The meeting facility SHOULD have UPS power 174 available to support key network infrastructure components, 175 including at least the core routers, core switches, and hardware 176 to maintain the external links. 178 o The meeting facility MUST provide sufficient power in all meeting 179 rooms to handle the projected load from users' laptops. The 180 projected load is for simultaneous usage for 100% of the projected 181 number of attendees in each meeting room and the number of laptop 182 users and projecting 70 watts of power usage per laptop. (?? do we 183 want to provide actual power estimates?) 185 4. Internal Network 187 o Wired Ethernet connections (network drops) MUST be provided in all 188 the locations used for meeting rooms to support audio and video 189 distribution for the purposes of remote participation. 191 o Wired network drops MUST be provided to the registration desk. (?? 192 need to confirm what the reg desk actually needs) 194 o The network SHOULD have separate VLANS for wired (primarily 195 terminal room and audio) and wireless traffic. 197 o The network MUST NOT prohibit end-to-end and external connectivity 198 for any traffic (no limiting firewalls or NATs). 200 o The network SHOULD have mechanisms for detecting and silencing 201 rogue servers (DHCP, IPv6 RA<92>s, etc) 203 5. Terminal Room or equivalent 205 o A terminal room or quiet work space MUST be provided. This room 206 MAY be a single room or distributed sites in reasonable proximity 207 to the meeting rooms. 209 o The terminal room SHOULD provide access to some number of wired 210 Ethernet drops in addition to the standard wireless network. 212 o The IETF users MUST have access to the terminal room from ?? to 213 ??. 215 o The terminal room MUST provide at least one network connected 216 enterprise class printer. These printers SHOULD have duplex 217 capability. 219 o A color printer MAY be provided. 221 o There SHOULD be a manned help desk from from ?? to ??. The help 222 desk provides technical assistance to attendees, provides one 223 potential interface to the trouble ticket system, and maintains 224 the printers. 226 o Power strips MUST be provided in the terminal room. 228 o Power strips MAY be provided in common gathering areas 229 (desirable). 231 6. Wireless 233 o The network MUST provide Wi-Fi coverage in all meeting rooms (as 234 identified by the Secretariat), common gathering spaces around the 235 meeting rooms, the registration area, and the terminal room. 237 o The network SHOULD provide Wi-Fi coverage in additional common 238 spaces in the meeting venue including the lobby, bar, restaurant, 239 and most commonly used hallways of the primary meeting hotel(s). 241 o The network design MUST anticipate simultaneous usage of 100% of 242 the projected number of attendees in each meeting room. and the 243 number of wireless network users (historical utilization in excess 244 of 1000 simultaneous wireless users has been observed during a 245 plenary session). 247 o The network MAY provide separate SSIDs for different specific 248 requirements. 250 o The network MUST provide at least one secure SSID and one open 251 SSID. 253 o The network MAY provide additional secured wireless access. 255 o There SHOULD be mechanisms for identifying and silencing rogue 256 Wireless Access Points. 258 7. Services 260 o The network MUST provide redundant DHCPv4 servers. 262 o The network SHOULD provide DHCPv6 service. 264 o The network MUST provide local redundant DNS servers. 266 o The network SHOULD provide NTP. 268 o Printers MUST support IPP and SHOULD support LPR and Windows 269 printing. 271 o The network MUST provide VMs for the Remote Participation Service. 273 8. Network Monitoring 275 o The network MUST provide sufficient monitoring to ensure adequate 276 network availability and to detect faults before they impact the 277 user experience. 279 o The network SHOULD provide some visibility into the state of the 280 network for attendees (e.g. public graphs of network utilization, 281 number of wireless associations, etc.). 283 o The network MUST collect data for future use in scaling IETF 284 meeting network requirements. Minimum required metrics include 285 bandwidth utilization (average and peak) for each external 286 connection and user density per AP and radio. 288 o The network provider SHOULD provide SNMP read-only access to the 289 network devices to individuals as identified by the Secretariat 290 for network management and planning purposes. 292 9. Miscellaneous Requirements 294 o The network provider SHOULD maintain spares of critical network 295 components on-site. 297 o Attendees SHOULD be notified of power connector requirements well 298 in advance of the meeting via both the IETF meeting web page. 300 o A document MUST be provided to attendees detailing on-site network 301 configuration information, including wireless configuration 302 details, services available (e.g. printing), instructions on how 303 to report network issues (e.g. trouble ticket system interface 304 instructions), etc. Initial versions of this information SHOULD 305 be provided in advance of the meeting. 307 o The network provider MUST NOT view the IETF network as an 308 experimental facility at the risk of impacting the IETF attendee 309 experience. (Do not experiment with his/her favorite pet 310 technology.) 312 o The network provider SHOULD have attended at least one prior IETF 313 to observe the IETF network deployment and operation. 315 o The network provider SHOULD supply the IETF network design to an 316 IETF technical review team for comments. 318 10. Security Considerations 320 While security is clearly important to the design and delivery of the 321 IETF meeting network. Draft -00 represents the information captured 322 on the original 2009 version. Security requirements (and 323 considerations) will be more clearly addressed in subsequent versions 324 of this draft. 326 11. IANA Considerations 328 There are no IANA considerations for this document. 330 12. Acknowledgements 332 These requirements represent past and current NOC teams including 333 hosts, volunteers, and network staff. All errors and misstatements 334 are the responsibility of the current author. 336 Contributors to this draft include Warren Kumari, Clemens Schrimpe, 337 and Alessandro Amirante. 339 Contributors noted in the original 2009 version of this document are 340 (in no particular order): Jim Martin, Karen O'Donoghue, Chris 341 Elliott, Joel Jaeggli, Lucy Lynch, Bill Jensen, Chris Liljenstoipe, 342 Bill Fenner, Hans Kuhn. 344 13. Revision comments 346 Draft -01 incorporated initial comments received from the NOC Team. 347 These were not fully discussed in advance of publication because of 348 the looming deadline. 350 Draft -00 was literally an import of the text developed in 2009 and 351 put on a website. https://www.ietf.org/how/meetings/admin/meeting- 352 network-requirements/. This was to ensure transparency by allowing 353 the changes to be viewable in datatracker. 355 14. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 Author's Address 362 Karen O'Donoghue 363 IETF NOC Team 365 Email: kodonog@pobox.com