idnits 2.17.1 draft-palet-ietf-meeting-network-requirements-02.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 (March 5, 2018) is 2238 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 The IPv6 Company 4 Intended status: Informational March 5, 2018 5 Expires: September 6, 2018 7 IETF Meeting Network and Other Technical Requirements 8 draft-palet-ietf-meeting-network-requirements-02 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 https://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 September 6, 2018. 37 Copyright Notice 39 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Terminal Room . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. NOC and Network Monitoring . . . . . . . . . . . . . . . . . 8 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 In venues where power is expected fo fail, UPS power should cover 185 beamers, audio equipment, remote participation equipment and the 186 complete wired and wireless network, at least for the average 187 expected failure time per day. 189 o Facilities for AV SHOULD be convenient for the IETF needs: room 190 dimensions for screens (height/width). 192 o SHOULD allow the use of wireless voice communication ("Walkie 193 Talkies" or hand-held radios). In some cases the secretariat can 194 bring its own equipment, but in some occasions it is required to 195 be rented from the hotel. 197 3. Internet Upstream 199 o The facility MUST have good network connectivity, with at least 200 two different providers (main one and backup). Ideally this 201 SHOULD be achieved by means of two fibers with different (physical 202 and logical) paths. A single provider may work with two diverse 203 paths all the way thru different subsequent upstream providers. 205 o IETF network SHOULD be able to run their own BGP, so the different 206 links can be aggregated or load-balanced. 208 o The primary link MUST provide a minimum of 1 Gbit (symmetric). 209 However, higher capacity may be appropriate in the future (10 210 Gbits can be expected as something common in a couple of years). 212 o The backup link(s) SHOULD provide a minimum of 100 Mbit 213 (symmetric). However, higher capacity may be appropriate in the 214 future (1 Gbit). 216 o Native IPv6 unicast MUST be available. IPv6 Multicast SHOULD be 217 available. 219 o IPv4 unicast and IPv4 multicast SHOULD be available, either 220 natively or by means of a tunnel. 222 o The upstream providers MUST provide access to the IPv4 and IPv6 223 default free zones without any kind of filtering or ACLs. 224 Consequently MUST NOT prohibit end-to-end connectivity to any 225 external sites. 227 o The IETF SHOULD be able to use its own AS, IPv4 and IPv6 228 addressing space. Otherwise, the upstream provider MUST supply an 229 AS, an IPv4 /19, IPv6 /32 and reverse DNS delegation for that 230 addressing space. 232 4. Wired Network 234 o Wired links MUST be available for the registration desk/ 235 secretariat with configuration to support the registration desk 236 firewall requirements. 238 o Wired links MUST be available in every meeting room which require 239 network for audio/video as required for remote participation and/ 240 or recording. Wired connectivity for chairs SHOULD be available. 242 o Separate VLANs for wired-terminal room, wired-registration desk/ 243 secretariat, wired-remote participation and wireless traffic, MUST 244 be supported. 246 o MUST support IPv6. 248 o MUST allow end-to-end connectivity, so MUST NOT have any kind of 249 filtering. 251 o SHOULD support multicast (multicast is not currently used to 252 support remote participation, but it may change at any point. 254 o SHOULD support mechanisms for detecting and mitigating rogue 255 protocols/servers (IPv6 RA's, DHCP, etc.). 257 5. Wireless Network 259 o The network MUST provide IEEE 802.11a/b/g service in all the 260 meeting rooms (as identified by the Secretariat), the registration 261 area, the terminal room and common/gathering areas. 263 o The WLAN coverage SHOULD also be sufficient in additional common 264 spaces including lobby, bar(s), restaurant(s), most commonly used 265 hallways, etc. This is applicable to the main conference center 266 and/or the main hotel(s), depending on the specific venue. 268 o IEEE 802.11n/ac coverage SHOULD be also available in as many as 269 the above named spaces as possible, focusing on the most dense 270 user density (plenary meeting room) first. 272 o The WLAN design MUST anticipate 200% usage according to the 273 historical figures of participants in each meeting room, assuming 274 that average attendee uses two devices. 276 o MUST support separate SSIDs for different specific VLANs (2.4GHz, 277 5GHz, NAT64, etc.). 279 o The main(s) hotel(s) SHOULD support the IETF-hotel SSID. This 280 SHOULD be supported by means of a specific IETF provided VLAN. 282 o The WLAN MUST provide fully open (unsecured) wireless access and 283 SHOULD provide additional secured (WEP, 802.11i, WPA) services. 285 o MUST support IPv6. 287 o SHOULD support mechanisms for detecting and mitigating rogue APs. 289 6. Network Services 291 o The network MUST provide local redundant DNS servers (IPv4 and 292 IPv6). 294 o The network MUST provide redundant DHCP (IPv4) servers. 296 o The network SHOULD provide redundant DHCPv6 servers. 298 o The network MUST provide SMTP server (IPv4 and IPv6). 300 o The network SHOULD provide a full on-site mirror of the RFC and 301 I-Ds directories (FTP/WWW, bothIPv4 and IPv6). 303 o IDS and other security issues SHOULD be covered (IPv4 and IPv6). 305 o The network SHOULD provide NTP services (IPv4 and IPv6). 307 o A pool of IP addresses for static assignment, even if discouraged 308 to use, SHOULD be available (IPv4 and IPv6). 310 o Printing services MUST support IPP and SHOULD support LPD/LPR and 311 Windows specific protocols (IPv4 and IPv6). 313 7. Terminal Room 315 o A terminal room or equivalent MUST be provided. It MAY be a 316 single room or a set of smaller ones distributed nearby the 317 meeting rooms. 319 o SHOULD be accessible 24 hours, however help-desk staff MAY not be 320 available all the time. 322 o SHOULD have adequate number of 10/100 Ethernet RJ-45 ports/drops. 324 o Two printers MUST be available. They SHOULD have duplex 325 capability. 327 o A color printer MAY be available. 329 o Power strips MUST be provided. 331 o A help-desk SHOULD be available. 333 o The upstream provider SHOULD provide a trouble ticket system to 334 track participants network issues. This system SHOULD be 335 accessible to the help-desk and NOC staff. 337 8. NOC and Network Monitoring 339 A support group or NOC, is responsible to manage the network and 340 other technical issues, including concrete aspects such as: 342 o Setup and maintain a meeting NOC web page with all the required 343 information. 345 o Document what can be wrong with the WLAN to inform users (FAQs). 346 Provide a document to attendees detailing configuration 347 information (wireless, services such as printing/SMTP) on-site and 348 prior to the meeting if possible (IETF meeting web site and NOC 349 meeting web site). 351 o Make sure to test the network under heavy load. 353 o Primary and backup contacts for all the issues/topics should be 354 available. 356 o Provide stats and info on network status. 358 o WLAN expertise and debugging/monitoring is required. 360 o SHOULD provide a white board with the stats and network status, in 361 visible place, possibly in the terminal room and by means of a 362 participants accesible web page. 364 To cover the issues indicated above and ensure network performance, 365 the NOC will use common network monitoring tools: 367 o The network MUST provide sufficient monitoring to ensure the 368 expected availability/performance and to detect possible faults 369 before they impact users experience. 371 o The network MUST collect data for future use and adequate 372 provisioning of following meetings network. 374 o The upstream providers SHOULD provide SNMP read-only access to the 375 network devices for the NOC. 377 9. Other Technical Criteria 379 Sufficient power strips MUST be available in the meeting rooms. 380 Additional power strips also should be available in common gathering 381 areas. 383 Attendees SHOULD be notified of power connector requirements prior to 384 the meeting (via the IETF meeting web page and IETF-announce mailing 385 list, possibly also via the meeting NOC web page). 387 The upstream provider SHOULD maintain spares of critical network 388 components on-site. 390 TBD. Audio requirements needed. There is a disparity of audio 391 quality from meeting to meeting. 393 10. Multi-property/building meetings 395 It should be noted that in some situations, the facility may be 396 composed of several buildings/properties, such as a main hotel (the 397 one with the meeting rooms) and secondary ones, or a conference 398 center and one or several hotels. 400 This may imply that the technical requirements in this document shall 401 be met by at least by the building actually hosting the meeting 402 rooms, however a subset of the requirements may be also relevant for 403 the main hotel or even several of them. 405 For example, it is desirable that the main facility is connected with 406 a direct optic fiber to other facilities (secondary hotels). This is 407 key in case the main facility is a conference center and there is a 408 main hotel or several ones. This will allow probably setting up in 409 one or several hotels the IETF-hotel SSID providing adequate 410 bandwidth for our needs. 412 There are alternative solutions, such as ensuring that the hotels 413 have sufficient bandwith even if they aren't connected to the IETF 414 network, and the difficulty is to define strict requirements for each 415 of the possible cases. However, the spirit of our needs in case 416 there is not a "main hotel" being the same facility as the meeting 417 rooms facility, should be considered by the on-site-survey team 418 report in order to ensure a close match with our needs. 420 11. Technical Risks and Contingencies 422 TBD. 424 12. Timing and Planning 426 Typically the pre-on-site survey is done by an email questionnaire 427 filled by the facility or even an phone/audio interview. This SHOULD 428 take place several years (around 3) before a possible on-site survey 429 is decided for that venue. 431 The on-site survey MUST take place at least 2-3 years in advance of a 432 possible contract. Whenever possible, several facilities in that 433 venue MAY be surveyed in a single trip. 435 The pre-meeting survey MUST take place 1-2 months in advance of the 436 actual meeting, in order to confirm some technical aspects and deploy 437 a router for some remote testing and monitoring. 439 13. Venue Acceptance/Rejection Report 441 After the on-site survey, the team responsible for that visit will 442 provide a complete report to the IAOC meetings committee. This 443 report will provide inputs regarding both, the venue and the visited 444 facilities. Only those facilities that MAY qualify will be ranked by 445 the survey team. 447 The report MUST include non only technical aspects but also others 448 related to the venue-selection-process itself, from both the venue 449 and the ranked facilities. 451 14. Security Considerations 453 This document does not have any protocol-related security 454 considerations. 456 15. IANA Considerations 458 This document does not have any specific IANA considerations. 460 16. Acknowledgements 462 The author would like to acknowledge the inputs of Brett Thorson, Jim 463 Martin, Joel Jaeggli, Laura Nugent and Karen Odonoghue (alphabetical 464 order). 466 Author's Address 468 Jordi Palet Martinez 469 The IPv6 Company 470 Molino de la Navata, 75 471 La Navata - Galapagar, Madrid 28420 472 Spain 474 Email: jordi.palet@theipv6company.com 475 URI: http://www.theipv6company.com/