Independent Stream J. Livingood Internet-Draft Comcast Intended status: Informational 17 February 2025 Expires: 21 August 2025 IETF Meeting Network Recommendations draft-livingood-meeting-network-00 Abstract IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 21 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Livingood Expires 21 August 2025 [Page 1] Internet-Draft IETF Meeting Network Recommendations February 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Key Requirements . . . . . . . . . . . . . . . . . . . . . . 2 3. Network Experiments . . . . . . . . . . . . . . . . . . . . . 3 4. Extension of IETF Network to Hotels . . . . . . . . . . . . . 3 5. Wireless Networks . . . . . . . . . . . . . . . . . . . . . . 3 6. Real-Time Reporting . . . . . . . . . . . . . . . . . . . . . 4 7. Post-Meeting Reporting . . . . . . . . . . . . . . . . . . . 4 8. Geo-IP Data . . . . . . . . . . . . . . . . . . . . . . . . . 4 9. Cost Management . . . . . . . . . . . . . . . . . . . . . . . 4 10. Questions About Roles and Responsibilities . . . . . . . . . 5 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 13. Security Considerations . . . . . . . . . . . . . . . . . . . 5 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 5 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 16. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion In the past, approaches to revise network requirements started from the point at which the IETF currently operates. This risks burdening such an exercise with old assumptions and requirements. This analysis, in contrast, is an idealized redesign that asks "if we were building the IETF network from scratch today, what should it look like?". 2. Key Requirements REQ1: Highly reliable and performant network with no experiments that may potentially cause disruptions to mission-critical standards development work (e.g., working group sessions). REQ2: Support for network experiments shall be supported via a functionally separate Hackathon network. Livingood Expires 21 August 2025 [Page 2] Internet-Draft IETF Meeting Network Recommendations February 2025 REQ3: Redundant upstream connectivity to the internet shall be maintained, to hedge the risk of outage in case of path failure. REQ4: Native dual stack shall be supported for all devices on the network - IPv4 and IPv6. REQ5: The most-recent IEEE Wi-Fi standard shall be supported, delivering ubiquitous Wi-Fi available in the entire meeting venue. REQ6: A public ticketing system shall be used to report issues, as well as track/report status or closure to all network users. REQ7: A public network performance dashboard and associated real- time and post-meeting reports shall be maintained, available to all network users. 3. Network Experiments * Network experiments MUST only occur on the Hackathon Network, which is a separate network form the Meeting Network. * The Hackathon Network will run for the entirety of the IETF meeting, not just during the Hackathon. * Participants shall use the public ticketing system (with support for up-voting to support prioritization) to request support for experimental new protocols or other experiments. These requests will thus be decided based on community feedback. 4. Extension of IETF Network to Hotels * Hotel networks are now sufficiently performant that this is no longer the technical limitation that it was 10 or 20 years ago; it is time to move on. * If there are potential issues with filtering, participants can use a VPN (as most do anyway). * Thus, the IETF meeting network MUST NOT be extended to hotel rooms any longer. 5. Wireless Networks * There shall be only one wireless network (Service Set Identifier, SSID) for the Meeting Network: IETF Livingood Expires 21 August 2025 [Page 3] Internet-Draft IETF Meeting Network Recommendations February 2025 * There shall be only one wireless network (SSID) for Network Experiments (unless a special SSID is required as part of an experiment): IETF-Hackathon * The wireless network shall require authentication, using the most recent widely supported standard. 6. Real-Time Reporting * All data concerning the performance of the network should be made available transparently for all participants to see, both during and after the meeting. * The Network Operations Center (NOC) shall provide a real-time or near-real-time dashboard of all key network statistics. * Reporting using IPFIX (NetFlow) that shows the source/destination of network flows. * Bandwidth tracking of peak usage. * Transport protocol tracking (e.g., volume of TCP, UDP, QUIC). * Application protocol tracking (e.g., volume of SMTP, HTTP, etc.). * DSCP mark tracking (e.g., volume by DSCP code point). * ECN tracking (e.g., volume with no ECN, ECT(1), CE). * All aspects of Wi-Fi performance (e.g., by room, specific AP, etc.). 7. Post-Meeting Reporting * Within 1 week of the shut down of the network a final network performance and incident(s) report shall be sent to the community and posted on the IETF website. 8. Geo-IP Data * Geo-IP data shall be updated to the next IETF meeting's location within 1 week of the end of the prior IETF meeting, so that Geo-IP databases pick up the change of geography well before the next IETF meeting. 9. Cost Management Livingood Expires 21 August 2025 [Page 4] Internet-Draft IETF Meeting Network Recommendations February 2025 * Total meeting network cost in 2024 was roughly $850,000. At 1,000 attendees per meeting and 3 meetings per year, 851,000/3,000 = $283 per participant for each meeting. If this cost was reduced, it could enable a material reduction in meeting registration fees. * Cost can be reduced by reducing complexity (see prior sections). * One potential parallel activity could be to have an *independent* team study these costs and make recommendations on how to reduce them. 10. Questions About Roles and Responsibilities * Lines of reporting may benefit from greater clarification. * The community may want to consider asking the NOC Lead contractor to regularly report to the IESG and IETF LLC concerning meeting network operations. * Should the IESG establish an community oversight mechanism for the meeting network operations function (e.g., via GEN Area)? 11. Acknowledgements N/A 12. IANA Considerations This memo includes no requests to or actions for IANA. 13. Security Considerations N/A 14. Revision History RFC Editor: Please remove this section before publication. v00: First draft 15. Open Issues N/A 16. Informative References Author's Address Livingood Expires 21 August 2025 [Page 5] Internet-Draft IETF Meeting Network Recommendations February 2025 Jason Livingood Comcast Philadelphia, PA United States of America Email: jason_livingood@comcast.com Livingood Expires 21 August 2025 [Page 6]