< draft-odonoghue-netrqmts-00.txt   draft-odonoghue-netrqmts-01.txt >
Network Working Group K. O'Donoghue Network Working Group K. O'Donoghue
Internet-Draft IETF NOC Team Internet-Draft IETF NOC Team
Intended status: Informational June 24, 2019 Intended status: Informational July 08, 2019
Expires: December 26, 2019 Expires: January 9, 2020
IETF Meeting Network Requirements IETF Meeting Network Requirements
draft-odonoghue-netrqmts-00 draft-odonoghue-netrqmts-01
Abstract Abstract
The IETF Meeting Network has become integral to the success of any The IETF Meeting Network has become integral to the success of any
physical IETF meeting. Building such a network, which provides physical IETF meeting. Building such a network, which provides
service to thousands of heavy users and their multitude of devices, service to thousands of heavy users and their multitude of devices,
spread throughout the event venue, with very little time for setup spread throughout the event venue, with very little time for setup
and testing is a challenge. This document provides a set of and testing is a challenge. This document provides a set of
requirements, derived from hard won experience, as an aid to anyone requirements, derived from hard won experience, as an aid to anyone
involved in designing and deploying such future networks. involved in designing and deploying such future networks.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. External Connectivity . . . . . . . . . . . . . . . . . . . . 3 2. External Connectivity . . . . . . . . . . . . . . . . . . . . 3
3. Meeting Facility . . . . . . . . . . . . . . . . . . . . . . 4 3. Meeting Facility . . . . . . . . . . . . . . . . . . . . . . 4
4. Internal Network . . . . . . . . . . . . . . . . . . . . . . 5 4. Internal Network . . . . . . . . . . . . . . . . . . . . . . 5
5. Terminal Room or equivalent . . . . . . . . . . . . . . . . . 5 5. Terminal Room or equivalent . . . . . . . . . . . . . . . . . 5
6. Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 7 8. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 6
9. Miscellaneous Requirements . . . . . . . . . . . . . . . . . 8 9. Miscellaneous Requirements . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
13. Normative References . . . . . . . . . . . . . . . . . . . . 9 13. Revision comments . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 14. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The IETF Meeting Network has grown and evolved over time as has the The IETF Meeting Network has grown and evolved over time as has the
IETF overall. In addition, the way that the IETF network is build IETF overall. In addition, the way that the IETF network is built
and provisioned has also changed. It is time for the IETF community and provisioned has also changed. It is time for the IETF community
to consider the requirements of this infrastructure and its role in to consider the requirements of this infrastructure and its role in
supporting the mission of the IETF. This document is meant to help supporting the mission of the IETF. This document is meant to help
frame that conversation. Additionally, this document may eventually frame that conversation. Additionally, this document may eventually
be developed to be useful to others outside the IETF in specifying be developed to be useful to others outside the IETF in specifying
and building their own successful event networks. and building their own successful event networks.
This document is currently being revised as part of an IETF community This document is currently being revised as part of an IETF community
discussion on the network requirements for the IETF meeting network. discussion on the network requirements for the IETF meeting network.
Version -00 represents the requirements as articulated the last time Version -00 represents the requirements as articulated the last time
skipping to change at page 3, line 18 skipping to change at page 3, line 18
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. External Connectivity 2. External Connectivity
o A primary and backup link MUST be provided for redundancy. If o A primary and backup link MUST be provided for redundancy. If
technically feasible, these links SHOULD be aggregated or load technically feasible, these links SHOULD be aggregated or load
balanced. balanced.
o The primary link MUST provide at least 45Mb bandwidth in both o The primary and backup links MUST provide at least 1 Gbps
directions, and SHOULD have at least 100Mb bidirectionally. bandwidth in both directions.
(Note: Historically, bandwidth utilization peaked at 80Mb and
averaged 35Mb.
o Recent events have peaked at 50 Mbs and averaged in the 25Mb o Recent events have peaked at roughly 850 Mbs and averaged in the
range.) The backup link MUST have 10 Mb bandwidth in both 100-300 Mbps range.
directions and SHOULD have at least 45 Mb bandwidth in both
directions.
o The backup link SHOULD be supplied by a different Internet service o The backup link SHOULD be supplied by a different Internet service
provider from the primary link. provider from the primary link.
o The primary and backup links SHOULD have physical and logical path o The primary and backup links SHOULD have physical and logical path
diversity. diversity.
o IPv6 MUST be provided (possibly via a tunnel). o IPv6 MUST be provided.
o The transit provided in support of the IETF MUST be capable of o The transit provided in support of the IETF MUST be capable of
providing access to the IPv4 and IPv6 default free zones without providing access to the IPv4 and IPv6 default free zones without
the imposition of content filtering (e.g., URL, Site, application, the imposition of content filtering (e.g., URL, Site, application,
port, or DPI based filtering). port, or DPI based filtering).
o The primary link MUST support BGP peering, and the backup link o The primary and secondary links MUST support BGP peering.
SHOULD support BGP peering.
o Routing MAY be configured to allow the simultaneous usage of the
bandwidth of both the primary and backup links.
o Access to research networks, like those that are part of Internet
2, MAY be provided on one of the external links.
o AS Numbers MAY be supplied by the network provider. If not, the o The provider(s) MUST allow the IETF to advertise (from the IETF AS
network provider MUST use the AS Numbers provided by IETF. number) the IETF IPv4 and IPv6 address ranges.
o The network provider MUST provide at least a /19 of provider o The provider(s) MUST implement IRR (or better) route filtering.
independent public IPv4 space or allow the IETF to advertise their
own space.
o The network provider MUST provide at least a /32 of LIR public o The provider(s) SHOULD carry and advertise full BGP tables.
IPv6 space or allow the IETF to advertise their own space.
o If providing access space, the network provider MUST provide o The provider(s) SHOULD implement BGP communities, especially the
proper IP address delegation for DNS reverse lookups. ability to RTBH.
3. Meeting Facility 3. Meeting Facility
o The facility SHOULD have as much physical separation as possible o The meeting facility SHOULD have physical characteristics that
in the meeting room area to improve the RF environment. In support the deployment of additional wireless networks including
addition, the facility SHOULD avoid using airwalls and other techniques to limit interference where possible (?? or something
partitions with low RF attenuation in the 2.4Mhz spectrum between along those lines).
meeting rooms.
o The facility SHOULD provide a RF environment in all meeting rooms
(as identified by the Secretariat), common gathering spaces around
the meeting rooms, the registration area, and the terminal room
that has a reasonable noise floor in the 2.4Mhz spectrum.
o The meeting facility SHOULD have installed network cabling that o The meeting facility SHOULD have installed network cabling that
can be used to deploy the network infrastructure. can be used to deploy the network infrastructure. (?? is this a
should or must, are we past the days of running cable if we need
to... )
o The meeting facility SHOULD provide the network installation team o The meeting facility SHOULD provide the network installation team
with 24 hour access to key telecom spaces. The meeting facility with 24 hour access to key telecom spaces. The meeting facility
MUST provide the network installation team with access to key MUST provide the network installation team with access to key
telecom spaces from one hour prior to the beginning of sessions to telecom spaces from one hour prior to the beginning of sessions to
one hour after the end of sessions and 9am to 5pm daily during the one hour after the end of sessions and 9am to 5pm daily during the
setup period. setup period. (?? are these the right timeframes)
o All locations for network gear, with the exception of wireless o All locations for network gear, with the exception of wireless
APs, MUST be secure. APs, MUST be secure.
o If wireless will be used for an external link then access to the o If wireless will be used for an external link then access to the
roof or installed location MUST be provided. roof or installed location MUST be provided.
o The meeting facility MUST have adequate ventilation to support the o The meeting facility MUST have adequate ventilation to support the
equipment rooms and the terminal room. equipment rooms and the terminal room.
skipping to change at page 5, line 11 skipping to change at page 4, line 45
its users. This may include 110v/220v requirements in technical its users. This may include 110v/220v requirements in technical
closets, roof locations, and various public and back-of-the-house closets, roof locations, and various public and back-of-the-house
areas. areas.
o The meeting facility The meeting facility SHOULD have UPS power o The meeting facility The meeting facility SHOULD have UPS power
available to support key network infrastructure components, available to support key network infrastructure components,
including at least the core routers, core switches, and hardware including at least the core routers, core switches, and hardware
to maintain the external links. to maintain the external links.
o The meeting facility MUST provide sufficient power in all meeting o The meeting facility MUST provide sufficient power in all meeting
rooms to handle the projected load from users' laptops, using 100% rooms to handle the projected load from users' laptops. The
congruency between the projected number of attendees in each projected load is for simultaneous usage for 100% of the projected
meeting room and the number of laptop users and projecting 70 number of attendees in each meeting room and the number of laptop
watts of power usage per laptop. users and projecting 70 watts of power usage per laptop. (?? do we
want to provide actual power estimates?)
4. Internal Network 4. Internal Network
o Wired Ethernet connections (network drops) MUST be provided in all o Wired Ethernet connections (network drops) MUST be provided in all
the locations used for meeting room audio distribution for the the locations used for meeting rooms to support audio and video
purposes of audio recording and transmission. distribution for the purposes of remote participation.
o Wired network drops MUST be provided to the registration desk. o Wired network drops MUST be provided to the registration desk. (??
need to confirm what the reg desk actually needs)
o The network SHOULD have separate VLANS for wired (primarily o The network SHOULD have separate VLANS for wired (primarily
terminal room and audio) and wireless traffic. terminal room and audio) and wireless traffic.
o The network MUST NOT prohibit end-to-end and external connectivity o The network MUST NOT prohibit end-to-end and external connectivity
for any traffic (no limiting firewalls or NATs). for any traffic (no limiting firewalls or NATs).
o The network SHOULD have mechanisms for detecting and silencing o The network SHOULD have mechanisms for detecting and silencing
rogue servers (DHCP, IPv6 RA's, etc) rogue servers (DHCP, IPv6 RA<92>s, etc)
5. Terminal Room or equivalent 5. Terminal Room or equivalent
o Terminal Room or equivalent A terminal room MUST be provided. o A terminal room or quiet work space MUST be provided. This room
This terminal room MAY be a single room or distributed sites in MAY be a single room or distributed sites in reasonable proximity
reasonable proximity to the meeting rooms. to the meeting rooms.
o The terminal room MUST provide Ethernet 10/100 connectivity with
RJ-45 connectors (approximately 100-150 drops required). (note:
this number should be revised based on terminal room usage
statistics)
o The terminal room SHOULD provide a small number of desktop or
laptop computers for emergency use by attendees (minimum
application requirements are web browsing, word processing,
presentation production, and printing capability).
o The terminal room SHOULD have 24 hour access. This access SHOULD o The terminal room SHOULD provide access to some number of wired
include security, but it MAY not include a 24 hour staffed help Ethernet drops in addition to the standard wireless network.
desk.
o The IETF users MUST have access to the terminal room from one hour o The IETF users MUST have access to the terminal room from ?? to
prior to the beginning of sessions to one hour after the end of ??.
sessions.
o The terminal room MUST provide at least two network connected o The terminal room MUST provide at least one network connected
enterprise class printers. These printers SHOULD have duplex enterprise class printer. These printers SHOULD have duplex
capability. capability.
o A color printer MAY be provided. o A color printer MAY be provided.
o The terminal room MUST have a manned help desk from one hour prior o There SHOULD be a manned help desk from from ?? to ??. The help
to the beginning of sessions to one hour after the end of desk provides technical assistance to attendees, provides one
sessions. The help desk provides technical assistance to potential interface to the trouble ticket system, and maintains
attendees, provides one potential interface to the trouble ticket the printers.
system (see next requirement), and maintains the printers.
o The network supplier SHOULD provide a trouble ticket system to
track attendee network issues. This trouble ticket system SHOULD
be accessible to the help desk staff in addition to NOC staff.
o Power strips MUST be provided in the terminal room. o Power strips MUST be provided in the terminal room.
o Power strips MAY be provided in common gathering areas o Power strips MAY be provided in common gathering areas
(desirable). (desirable).
o The terminal room MUST have physical security (guards) during
operating hours.
6. Wireless 6. Wireless
o The network MUST provide 802.11b coverage in all meeting rooms (as o The network MUST provide Wi-Fi coverage in all meeting rooms (as
identified by the Secretariat), common gathering spaces around the identified by the Secretariat), common gathering spaces around the
meeting rooms, the registration area, and the terminal room. meeting rooms, the registration area, and the terminal room.
o The network SHOULD provide 802.11b coverage in additional common o The network SHOULD provide Wi-Fi coverage in additional common
spaces in the meeting venue. The lobby, bar, restaurant, and most spaces in the meeting venue including the lobby, bar, restaurant,
commonly used hallways of the primary meeting hotels, SHOULD also and most commonly used hallways of the primary meeting hotel(s).
be provide 802.11b access.
o The network SHOULD provide 802.11g in all the spaces identified
above.
o The network SHOULD provide 802.11a coverage in as many of the
above identified spaces as possible focusing on the spaces with
the highest user density first (e.g. plenary meeting room).
o The network design MUST anticipate 100% congruency between the o The network design MUST anticipate simultaneous usage of 100% of
projected number of attendees in each meeting room and the number the projected number of attendees in each meeting room. and the
of wireless network users (historical utilization in excess of number of wireless network users (historical utilization in excess
1000 simultaneous wireless users has been observed during a of 1000 simultaneous wireless users has been observed during a
plenary session). plenary session).
o The network SHOULD provide separate SSIDs for 802.11b and 802.11a o The network MAY provide separate SSIDs for different specific
networks. requirements.
o The network MUST provide fully open (unsecured) wireless access. o The network MUST provide at least one secure SSID and one open
SSID.
o The network MAY provide additional secured (WEP, 802.11i, WPA) o The network MAY provide additional secured wireless access.
wireless access.
o There SHOULD be mechanisms for identifying and silencing rogue o There SHOULD be mechanisms for identifying and silencing rogue
Wireless Access Points. Wireless Access Points.
7. Services 7. Services
o The network MUST provide redundant DHCPv4 servers. o The network MUST provide redundant DHCPv4 servers.
o The network SHOULD provide DHCPv6 service. o The network SHOULD provide DHCPv6 service.
o The network MUST provide local redundant DNS servers. o The network MUST provide local redundant DNS servers.
o The network SHOULD provide NTP. o The network SHOULD provide NTP.
o Printers MUST support IPP and SHOULD support LPR and Windows o Printers MUST support IPP and SHOULD support LPR and Windows
printing. printing.
o The network MUST provide a SMTP server providing relay services o The network MUST provide VMs for the Remote Participation Service.
for the IETF network.
o The network SHOULD provide a full on-site mirror of the RFC and
I-D directories.
8. Network Monitoring 8. Network Monitoring
o The network MUST provide sufficient monitoring to ensure adequate o The network MUST provide sufficient monitoring to ensure adequate
network availability and to detect faults before they impact the network availability and to detect faults before they impact the
user experience. user experience.
o The network SHOULD provide some visibility into the state of the o The network SHOULD provide some visibility into the state of the
network for attendees (e.g. public graphs of network utilization, network for attendees (e.g. public graphs of network utilization,
number of wireless associations, etc.). number of wireless associations, etc.).
skipping to change at page 8, line 15 skipping to change at page 7, line 24
o The network provider SHOULD provide SNMP read-only access to the o The network provider SHOULD provide SNMP read-only access to the
network devices to individuals as identified by the Secretariat network devices to individuals as identified by the Secretariat
for network management and planning purposes. for network management and planning purposes.
9. Miscellaneous Requirements 9. Miscellaneous Requirements
o The network provider SHOULD maintain spares of critical network o The network provider SHOULD maintain spares of critical network
components on-site. components on-site.
o Attendees SHOULD be notified of power connector requirements well o Attendees SHOULD be notified of power connector requirements well
in advance of the meeting via both the IETF meeting web page and in advance of the meeting via both the IETF meeting web page.
the IETF- announce mailing list.
o A document MUST be provided to attendees detailing on-site network o A document MUST be provided to attendees detailing on-site network
configuration information, including wireless configuration configuration information, including wireless configuration
details, services available (e.g. printing, SMTP), instructions on details, services available (e.g. printing), instructions on how
how to report network issues (e.g. trouble ticket system interface to report network issues (e.g. trouble ticket system interface
instructions), etc. Initial versions of this information SHOULD instructions), etc. Initial versions of this information SHOULD
be provided in advance of the meeting. be provided in advance of the meeting.
o The network provider MUST NOT view the IETF network as an o The network provider MUST NOT view the IETF network as an
experimental facility at the risk of impacting the IETF attendee experimental facility at the risk of impacting the IETF attendee
experience. (Do not experiment with his/her favorite pet experience. (Do not experiment with his/her favorite pet
technology.) technology.)
o The network provider SHOULD have attended at least one prior IETF o The network provider SHOULD have attended at least one prior IETF
to observe the IETF network deployment and operation. to observe the IETF network deployment and operation.
skipping to change at page 8, line 50 skipping to change at page 8, line 11
on the original 2009 version. Security requirements (and on the original 2009 version. Security requirements (and
considerations) will be more clearly addressed in subsequent versions considerations) will be more clearly addressed in subsequent versions
of this draft. of this draft.
11. IANA Considerations 11. IANA Considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
12. Acknowledgements 12. Acknowledgements
These requirements are born out of the pain and experience of past These requirements represent past and current NOC teams including
NOC teams including hosts, volunteers, and network staff. All errors hosts, volunteers, and network staff. All errors and misstatements
and misstatements are the responsibility of the current author. are the responsibility of the current author.
Contributors noted in the original 2009 version of this document are
(in no particular order):
o Jim Martin
o Karen O'Donoghue
o Chris Elliott
o Joel Jaeggli
o Lucy Lynch
o Bill "wej' Jensen
o Chris Liljenstoipe Contributors to this draft include Warren Kumari, Clemens Schrimpe,
and Alessandro Amirante.
o Bill Fenner Contributors noted in the original 2009 version of this document are
(in no particular order): Jim Martin, Karen O'Donoghue, Chris
Elliott, Joel Jaeggli, Lucy Lynch, Bill Jensen, Chris Liljenstoipe,
Bill Fenner, Hans Kuhn.
o Hans Kuhn 13. Revision comments
Additional contributions including the current NOC Team will be added Draft -01 incorporated initial comments received from the NOC Team.
in subsequent versions of this draft. These were not fully discussed in advance of publication because of
the looming deadline.
Finally, the author is submitting this draft as an individual to help Draft -00 was literally an import of the text developed in 2009 and
facilitate a conversation and as a long time volunteer member of the put on a website. https://www.ietf.org/how/meetings/admin/meeting-
IETF NOC Team. This draft does not represent any official position network-requirements/. This was to ensure transparency by allowing
of the Internet Society, her current employer. the changes to be viewable in datatracker.
13. Normative References 14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address Author's Address
Karen O'Donoghue Karen O'Donoghue
IETF NOC Team IETF NOC Team
Email: kodonog@pobox.com Email: kodonog@pobox.com
 End of changes. 43 change blocks. 
148 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/