idnits 2.17.1 draft-palet-ietf-meeting-network-requirements-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '... facility MUST be organized, typi...' RFC 2119 keyword, line 132: '... o MUST have a Telecommunications r...' RFC 2119 keyword, line 133: '...ts, etc.). They MUST be secured and p...' RFC 2119 keyword, line 137: '... o MUST have adequate ventilation t...' RFC 2119 keyword, line 140: '... o SHOULD have as much physical sep...' (70 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Meeting Venue J. Palet Martinez 3 Internet-Draft Consulintel, S.L. 4 Intended status: Informational July 3, 2017 5 Expires: January 4, 2018 7 IETF Meeting Network and Other Technical Requirements 8 draft-palet-ietf-meeting-network-requirements-01 10 Abstract 12 This document describe the minimum technical requirements for a 13 facility to be able to host a successful IETF meeting. Includes also 14 requirements for the terminal room and other technical requirements. 16 This documents should be used as the minimum criteria during an on- 17 site facility survey, to ensure the fulfilment of the IETF meeting 18 needs. 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 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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 2. Facility General Technical Requirements . . . . . . . . . . . 3 56 3. Internet Upstream . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Wired Network . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Wireless Network . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Network Services . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Terminal Room . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. NOC and Network Monitoring . . . . . . . . . . . . . . . . . 7 62 9. Other Technical Criteria . . . . . . . . . . . . . . . . . . 8 63 10. Multi-property/building meetings . . . . . . . . . . . . . . 9 64 11. Technical Risks and Contingencies . . . . . . . . . . . . . . 9 65 12. Timing and Planning . . . . . . . . . . . . . . . . . . . . . 9 66 13. Venue Acceptance/Rejection Report . . . . . . . . . . . . . . 10 67 14. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document describes network, terminal room and other technical 75 criteria for the IETF facility selection process, including some 76 details related to the planning. All this details are required in 77 order to accommodate the IETF meeting with technical guarantees of 78 successful working capabilities for the attendees, as a result of 79 previous experience and considering possible new future news in the 80 medium term. 82 This document lists what needs to be evaluated and various 83 alternative solutions, or combinations thereof, that may apply. The 84 document shall be used in several steps of the venue/facility 85 selection: 87 o Pre-on-site survey: Before a facility is qualified, from the 88 technical perspective, for a possible on-site visit, and when non- 89 technical requirements (such as venue requirements and facility 90 meeting space availability) seem to be met already, in order to 91 pre-evaluate that the technical requirements could also be 92 satisfied. 94 o On-site survey: Experience shows that an on-site survey of the 95 facility MUST be organized, typically in conjunction with a 96 general on-site survey for ensuring that both technical and non- 97 technical meeting requirements are met. The participation of a 98 local IETF participant together with the NOC team may be very 99 relevant, in order to ensure that as much information as possible 100 is collected in advance, to facilitate communication issues, and 101 specially to make sure that the all the facility relevant staff is 102 present during the on-site survey. 104 o Pre-meeting: If a facility has been already selected/contracted, 105 around 1-2 months before the actual meeting, a new on-site visit 106 is organized which allows a very detailed scrutiny to nail down 107 possible issues or needs, as well as connecting already an IETF 108 managed router to the Internet upstreams, allowing announcing the 109 IETF networks and doing some remote testing to facilitate 110 resolving any possible issues before the actual meeting. 112 Only if the pre-on-site-survey seems to indicate that the facility 113 match the IETF technical requirements, then the on-site-survey will 114 be organized. In some cases, where several facilities are in the 115 same venue or in a convenient distance, it may make sense to organize 116 also on-site technical surveys for several facilities. 118 Experience shows that things could go wrong when there is too strict 119 a dependence on specific people or equipment and when no alternatives 120 are provisioned for. Consequently, contingencies are a very 121 important consideration across all the process. 123 2. Facility General Technical Requirements 125 The facility being evaluated for hosting IETF, should comply with 126 several generic technical requirements, which will allow an adequate 127 installation of the network, terminal room and some other relevant 128 technical details. The facility chosen can have a dramatic impact on 129 the ability to deliver a quality network to attendees, so the general 130 requirements of this section are of key importance: 132 o MUST have a Telecommunications rooms and/or equivalent spaces 133 (cabinets, etc.). They MUST be secured and provide a mechanism 134 for 24-hours access to the NOC team, even during the network 135 setup. 137 o MUST have adequate ventilation to support the equipment rooms and 138 the terminal room. 140 o SHOULD have as much physical separation as possible in the meeting 141 room area to improve the RF environment. 143 o SOULD avoid air-walls and similar partitions systems, between 144 meeting rooms, with low RF attenuation in the 2.4MHz spectrum. 146 o SOULD provide a RF environment in all the meeting rooms to be used 147 by IETF, common spaces, terminal room and registration area, that 148 has a reasonable noise floor in the 2.4MHz spectrum. 150 o SHOULD provide an appropriate wiring plan (power and data) in 151 order to know the existing infrastructure (fiber, connectors, UTP 152 category/distances) and what can be used, what not, what can be 153 done with it, etc. 155 o SHOULD have installed network cabling which can be used to deploy 156 the IETF network, either by spare fiber pairs (other options may 157 be possible), by sharing by means of VLANs/other means, or by 158 providing exclusive usage to those fibers for the IETF network. 159 The number of fibers required across the facility depends on the 160 physical allocation of the meeting space, distribution structure 161 in different buildings/floors, etc. Some facilities have no 162 wiring and that could be an important inconvenient, especially in 163 order to quickly deploy the wireless network. Feasibility/ 164 facility to setup new cables (fiber/UTP) MUST be considered. 166 o Roof access, in case a WLAN link is required, MUST be provided. 168 o If there is already a WLAN in the facility, SOULD be possible to 169 turn it off at the meeting space area, otherwise dependencies to 170 temperature, lighting, security, access control, POS and other 171 systems MUST be properly evaluated. 173 o MUST have electrical power capacity to support the IETF equipment 174 and terminal room needs. 176 o MUST have electrical power capacity to support the IETF network 177 and its users, including 110/220 VAC in cabinets, roof locations, 178 public areas and back-of-the-house areas. 180 o 24 hours' power SOULD be available by means of UPS power to 181 support key network infrastructure, such as core routers and 182 switches and other devices required for the external connectivity. 184 o Facilities for AV SHOULD be convenient for the IETF needs: room 185 dimensions for screens (height/width). 187 o SHOULD allow the use of wireless voice communication ("Walkie 188 Talkies" or hand-held radios). In some cases the secretariat can 189 bring its own equipment, but in some occasions it is required to 190 be rented from the hotel. 192 3. Internet Upstream 194 o The facility MUST have good network connectivity, with at least 195 two different providers (main one and backup). Ideally this 196 SHOULD be achieved by means of two fibers with different (physical 197 and logical) paths. A single provider may work with two diverse 198 paths all the way thru different subsequent upstream providers. 200 o IETF network SHOULD be able to run their own BGP, so the different 201 links can be aggregated or load-balanced. 203 o The primary link MUST provide a minimum of 1 Gbit (symmetric). 204 However, higher capacity may be appropriate in the future (10 205 Gbits can be expected as something common in a couple of years). 207 o The backup link(s) SHOULD provide a minimum of 100 Mbit 208 (symmetric). However, higher capacity may be appropriate in the 209 future (1 Gbit). 211 o Native IPv6 unicast MUST be available. IPv6 Multicast SHOULD be 212 available. 214 o IPv4 unicast and IPv4 multicast SHOULD be available, either 215 natively or by means of a tunnel. 217 o The upstream providers MUST provide access to the IPv4 and IPv6 218 default free zones without any kind of filtering or ACLs. 219 Consequently MUST NOT prohibit end-to-end connectivity to any 220 external sites. 222 o The IETF SHOULD be able to use its own AS, IPv4 and IPv6 223 addressing space. Otherwise, the upstream provider MUST supply an 224 AS, an IPv4 /19, IPv6 /32 and reverse DNS delegation for that 225 addressing space. 227 4. Wired Network 229 o Wired links MUST be available for the registration desk/ 230 secretariat with configuration to support the registration desk 231 firewall requirements. 233 o Wired links MUST be available in every meeting room which require 234 network for audio/video as required for remote participation and/ 235 or recording. Wired connectivity for chairs SHOULD be available. 237 o Separate VLANs for wired-terminal room, wired-registration desk/ 238 secretariat, wired-remote participation and wireless traffic, MUST 239 be supported. 241 o MUST support IPv6. 243 o MUST allow end-to-end connectivity, so MUST NOT have any kind of 244 filtering. 246 o SHOULD support multicast (multicast is not currently used to 247 support remote participation, but it may change at any point. 249 o SHOULD support mechanisms for detecting and mitigating rogue 250 protocols/servers (IPv6 RA's, DHCP, etc.). 252 5. Wireless Network 254 o The network MUST provide IEEE 802.11a/b/g service in all the 255 meeting rooms (as identified by the Secretariat), the registration 256 area, the terminal room and common/gathering areas. 258 o The WLAN coverage SHOULD also be sufficient in additional common 259 spaces including lobby, bar(s), restaurant(s), most commonly used 260 hallways, etc. This is applicable to the main conference center 261 and/or the main hotel(s), depending on the specific venue. 263 o IEEE 802.11n/ac coverage SHOULD be also available in as many as 264 the above named spaces as possible, focusing on the most dense 265 user density (plenary meeting room) first. 267 o The WLAN design MUST anticipate 200% usage according to the 268 historical figures of participants in each meeting room, assuming 269 that average attendee uses two devices. 271 o MUST support separate SSIDs for different specific VLANs (2.4GHz, 272 5GHz, NAT64, etc.). 274 o The main(s) hotel(s) SHOULD support the IETF-hotel SSID. This 275 SHOULD be supported by means of a specific IETF provided VLAN. 277 o The WLAN MUST provide fully open (unsecured) wireless access and 278 SHOULD provide additional secured (WEP, 802.11i, WPA) services. 280 o MUST support IPv6. 282 o SHOULD support mechanisms for detecting and mitigating rogue APs. 284 6. Network Services 286 o The network MUST provide local redundant DNS servers (IPv4 and 287 IPv6). 289 o The network MUST provide redundant DHCP (IPv4) servers. 291 o The network SHOULD provide redundant DHCPv6 servers. 293 o The network MUST provide SMTP server (IPv4 and IPv6). 295 o The network SHOULD provide a full on-site mirror of the RFC and 296 I-Ds directories (FTP/WWW, bothIPv4 and IPv6). 298 o IDS and other security issues SHOULD be covered (IPv4 and IPv6). 300 o The network SHOULD provide NTP services (IPv4 and IPv6). 302 o A pool of IP addresses for static assignment, even if discouraged 303 to use, SHOULD be available (IPv4 and IPv6). 305 o Printing services MUST support IPP and SHOULD support LPD/LPR and 306 Windows specific protocols (IPv4 and IPv6). 308 7. Terminal Room 310 o A terminal room or equivalent MUST be provided. It MAY be a 311 single room or a set of smaller ones distributed nearby the 312 meeting rooms. 314 o SHOULD be accessible 24 hours, however help-desk staff MAY not be 315 available all the time. 317 o SHOULD have adequate number of 10/100 Ethernet RJ-45 ports/drops. 319 o Two printers MUST be available. They SHOULD have duplex 320 capability. 322 o A color printer MAY be available. 324 o Power strips MUST be provided. 326 o A help-desk SHOULD be available. 328 o The upstream provider SHOULD provide a trouble ticket system to 329 track participants network issues. This system SHOULD be 330 accessible to the help-desk and NOC staff. 332 8. NOC and Network Monitoring 334 A support group or NOC, is responsible to manage the network and 335 other technical issues, including concrete aspects such as: 337 o Setup and maintain a meeting NOC web page with all the required 338 information. 340 o Document what can be wrong with the WLAN to inform users (FAQs). 341 Provide a document to attendees detailing configuration 342 information (wireless, services such as printing/SMTP) on-site and 343 prior to the meeting if possible (IETF meeting web site and NOC 344 meeting web site). 346 o Make sure to test the network under heavy load. 348 o Primary and backup contacts for all the issues/topics should be 349 available. 351 o Provide stats and info on network status. 353 o WLAN expertise and debugging/monitoring is required. 355 o SHOULD provide a white board with the stats and network status, in 356 visible place, possibly in the terminal room and by means of a 357 participants accesible web page. 359 To cover the issues indicated above and ensure network performance, 360 the NOC will use common network monitoring tools: 362 o The network MUST provide sufficient monitoring to ensure the 363 expected availability/performance and to detect possible faults 364 before they impact users experience. 366 o The network MUST collect data for future use and adequate 367 provisioning of following meetings network. 369 o The upstream providers SHOULD provide SNMP read-only access to the 370 network devices for the NOC. 372 9. Other Technical Criteria 374 Sufficient power strips MUST be available in the meeting rooms. 375 Additional power strips also should be available in common gathering 376 areas. 378 Attendees SHOULD be notified of power connector requirements prior to 379 the meeting (via the IETF meeting web page and IETF-announce mailing 380 list, possibly also via the meeting NOC web page). 382 The upstream provider SHOULD maintain spares of critical network 383 components on-site. 385 10. Multi-property/building meetings 387 It should be noted that in some situations, the facility may be 388 composed of several buildings/properties, such as a main hotel (the 389 one with the meeting rooms) and secondary ones, or a conference 390 center and one or several hotels. 392 This may imply that the technical requirements in this document shall 393 be met by at least by the building actually hosting the meeting 394 rooms, however a subset of the requirements may be also relevant for 395 the main hotel or even several of them. 397 For example, it is desirable that the main facility is connected with 398 a direct optic fiber to other facilities (secondary hotels). This is 399 key in case the main facility is a conference center and there is a 400 main hotel or several ones. This will allow probably setting up in 401 one or several hotels the IETF-hotel SSID providing adequate 402 bandwidth for our needs. 404 There are alternative solutions, such as ensuring that the hotels 405 have sufficient bandwith even if they aren't connected to the IETF 406 network, and the difficulty is to define strict requirements for each 407 of the possible cases. However, the spirit of our needs in case 408 there is not a "main hotel" being the same facility as the meeting 409 rooms facility, should be considered by the on-site-survey team 410 report in order to ensure a close match with our needs. 412 11. Technical Risks and Contingencies 414 TBD. 416 12. Timing and Planning 418 Typically the pre-on-site survey is done by an email questionnaire 419 filled by the facility or even an phone/audio interview. This SHOULD 420 take place several years (around 3) before a possible on-site survey 421 is decided for that venue. 423 The on-site survey MUST take place at least 2-3 years in advance of a 424 possible contract. Whenever possible, several facilities in that 425 venue MAY be surveyed in a single trip. 427 The pre-meeting survey MUST take place 1-2 months in advance of the 428 actual meeting, in order to confirm some technical aspects and deploy 429 a router for some remote testing and monitoring. 431 13. Venue Acceptance/Rejection Report 433 After the on-site survey, the team responsible for that visit will 434 provide a complete report to the IAOC meetings committee. This 435 report will provide inputs regarding both, the venue and the visited 436 facilities. Only those facilities that MAY qualify will be ranked by 437 the survey team. 439 The report MUST include non only technical aspects but also others 440 related to the venue-selection-process itself, from both the venue 441 and the ranked facilities. 443 14. Security Considerations 445 This document does not have any protocol-related security 446 considerations. 448 15. IANA Considerations 450 This document does not have any specific IANA considerations. 452 16. Acknowledgements 454 The author would like to acknowledge the inputs of Brett Thorson, Jim 455 Martin, Joel Jaeggli, Laura Nugent and Karen Odonoghue (alphabetical 456 order). 458 Author's Address 460 Jordi Palet Martinez 461 Consulintel, S.L. 462 Molino de la Navata, 75 463 La Navata - Galapagar, Madrid 28420 464 Spain 466 Email: jordi.palet@consulintel.es 467 URI: http://www.consulintel.es/