Internet-Draft IETF Network Requirements April 2025
Daley Expires 30 October 2025 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-daley-meeting-network-requirements-00
Published:
Intended Status:
Informational
Expires:
Author:
J. Daley
IETF Administration LLC

IETF Network Requirements

Abstract

This document aims to initiate a conversation to clarify the way forward to address disagreements within the community about the requirements for the IETF meeting network, how it is delivered and whether or not the current cost and effort of providing the network is reasonable.

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 30 October 2025.

▲

Table of Contents

1. Introduction

The network that IETF participants use at an IETF Meeting has been a high-profile feature of IETF Meetings for some time and is now a major part of the behind-the-scenes work and cost of running an IETF Meeting. This network replaces any venue network using equipment donated by suppliers, installed and managed by a mixed team of volunteers and contractors.

There are disagreements within the community about the requirements for this network, how it is delivered and whether or not the current cost and effort of providing the network is reasonable.

The IETF Administration LLC (IETF LLC) has overall responsibility for delivering IETF Meetings to meet community-set requirements including managing the meeting costs and service provision. However, the IETF LLC is unclear on what the path is to resolve these disagreements. This is important because they get to the heart of the requirements for the IETF Network and the resulting provision of that network. The main area of uncertainty is whether this is a community matter that requires a community-led process to determine an outcome such as an RFC, or this is for the IETF LLC to lead on and make decisions through its normal consultative processes.

This document aims to initiate a conversation to clarify the way forward. To do this, it provides a full primer on the facts needed to understand the current situation and the areas of disagreement. This includes It sets out the current high-level requirements for the IETF Network, an overview of how the IETF Network is delivered, how this relates back to the requirements and where the areas of disagreement are.

2. Terms

IETF Network:
Used generically to mean the network used by IETF participants at an IETF meeting, however it is provided.
Remote Participation Services (RPS):
The service and all the parts that go with it that allows remote people to participate in an IETF Meeting.
Meeting Tool:
The tool participants must use during the meeting in order to participate.

3. Background

[BCP226] gives the following relevant mandatory criterion for venue selection:

It MUST be possible to provision Internet Access to the Facility and IETF Hotels that allows those attending in person to utilize the Internet for all their IETF, business, and day-to-day needs; in addition, there must be sufficient bandwidth and access for remote attendees. Provisions include, but are not limited to, native and unmodified IPv4 and IPv6 connectivity, and global reachability; there may be no additional limitation that would materially impact their Internet use. To ensure availability, it MUST be possible to provision redundant paths to the Internet.

It further goes on to give the following important, but not mandatory, relevant criteria:

In summary, this sets out requirements for a meeting network, conceptually split into two networks:

It also sets the the following required attributes for those networks:

4. Requirements that the IETF Network currently aims to meet

4.1. The meeting networks and their purposes

4.1.1. Conference network

The mandatory criterion in [BCP226] is clear that the core purpose of the IETF Network is a conference network, which includes "all their IETF, business, and day-to-day needs".

In addition it requires that "there must be sufficient bandwidth and access for remote attendees". However, in practice this requirement has expanded in scope and importance as it is no longer possible to run an IETF Meeting without full support for the RPS and Meeting Tool:

  • Over time, and boosted by the period during the COVID-pandemic when IETF Meetings went fully online, the level of active remote participation has grown considerably, and IETF Meetings have become dependent on the RPS to support this.
  • Several meeting practices now rely on the Meeting Tool, including the use of the queuing feature for all speakers at the microphone, recording meeting participation and the use of the poll feature to replace humming.

4.1.2. Hotel network

The requirement for a hotel network (irrespective of how it is delivered) is set in [BCP226] as documented above, but this does not explain why this is a requirement.

One possible reason is that IETF participants have a higher dependency on the reliability of the hotel network than other hotel guests due to the nature of IETF participation, explained as follows.

As evidenced by annual community surveys, participation in the IETF is a part-time activity for a very high percentage of participants. During the week of an IETF meeting, participants spend a much higher proportion of their working week on IETF activities than otherwise, which pushes many to work on their day job work and other personal commitments out of hours, from their hotel rooms, thereby increasing their dependency on the hotel network.

4.1.3. Experimental network

In addition to a conference network and a hotel network, the IETF Network also fulfills the purpose of an experimental network.

Running code is a key part of the IETF process. As documented in [BCP205] "there are benefits to the IETF standardization process of producing implementations of protocol specifications before publication as RFCs". Producing protocol implementations is, by definition, experimental on a network and so brings with it specific requirements that would not ordinarily be supported, such as:

  • Running networking equipment with experimental features on them.
  • Providing an SSID which implements an experimental feature.
  • Sending packets that are built in ways that production equipment cannot recognise.

Such experimentation can have an adverse impact on a production network and therefore needs to be clearly managed to prevent that.

4.2. Expectations of how these networks should be operated

Only the first of the following expectations is documented in a BCP. The rest have been understood by the IETF NOC, over many years of running the IETF Network, to be the expectations of the IETF community. These latter expectations do not have community consensus and have not been sufficiently reviewed to understand if they are mandatory or just desirable.

These expectations do not equally apply to the conference, hotel and experimental networks. The following table shows where they apply:

Table 1
Conference Hotel Experimental
High performance and robust x x -
Low friction x x -
Good access to network data, without compromising privacy x x x
Every participant needs to be able to participate fully x - -
Early adopter of relevant, production-ready IETF standards x - -
Open, transparent and community-led development x x x

4.2.1. High performance and robust

This expectation is set in [BCP226] and is taken to mean ample bandwidth, WiFi coverage everywhere, and 100% uptime experienced by all participants. In other words, "it just works".

4.2.2. Low friction

The assumed expectation here is that using the network should involve as little friction as possible. This is generally taken as minimising the need for participants to take a manual action to use the network for ordinary purposes.

4.2.3. Good access to network data, without compromising privacy

While not a documented expectation, there have been enough individual requests from IETF participants for good access to data on the IETF Network that this is considered a general expectation. The reasons for these requests vary from general interest to assisting people in assessing if any changes are needed to either the network requirements or how it is delivered.

The general privacy expectations of the IETF community are well documented and it is therefore assumed that access to network data must not compromise privacy.

4.2.4. Every participant needs to be able to participate fully

The expectation is that every participant is fully able to participate, as a requirement of the standards process. In practice, this means that old (legacy) equipment is supported beyond what might be commonly supported.

4.2.5. Early adopter of relevant, production-ready IETF standards

The expectation here is that when a relevant IETF standard reaches the point where it is considered production-ready, work begins to implement it on the IETF Network. "Production ready" means that a number of conditions are met:

  • It is fully supported across all of the equipment that is part of the provision.
  • The IETF NOC has sufficient knowledge and experience to support its use.
  • All vendor support is identified by that vendor as production-ready not experimental support.

4.2.6. Open, transparent and community-led development

It is a general expectation of the IETF community that all of the custom-developed tools and services that it relies on (not off-the-shelf tools and services), are developed in an open and transparent fashion that provides ample opportunity for IETF participants to share their views on how they should be developed, and that this development takes those views into consideration.

5. How the IETF Network is currently delivered

5.1. IETF NOC

The IETF Network is delivered by the IETF NOC, which consists of four parts:

5.2. Conference network

5.2.1. Approach

The IETF NOC provides its own conference network separate from that provided by a venue, by installing equipment and services at the venue.

The reasoning for this approach is based on the experiences of many IETF NOC members (including those who work professionally on conference networks) regarding venue networks:

  • Venue networks are rarely capable of delivering the requirements for the IETF Network, specifically:

    • Rarely able to deliver IPv6
    • Rarely able to cope with the number and variety of different devices (designed for coverage, not density)
    • Rarely provide an onsite helpdesk
    • Rarely support recent wireless standards and features
    • Rarely provide significant privacy protection
    • Rarely able to support HackNet (see below)
    • Rarely provides visibility into network usage
    • Sometimes do not have sufficient bandwidth
    • Sometimes have filtering or other traffic modification
  • It is not possible to test the performance and reliability of venue networks well enough in advance to trust them (too many problems appear with scale and variety of clients)

5.2.2. Equipment and services

The equipment itself is stored between IETF Meetings by the professional conference networking company and shipped to each venue. The volume of this equipment is substantial, taking up a full rack and multiple other boxes.

  • 1Gb/s or 10Gb/s Internet connection*, almost always donated by a local provider. For some venues the provider installs a new fibre into the venue to deliver this connection.
  • Router(s)*.
  • Access points*, controllers* and switches* to provide WiFi coverage over the entire venue.
  • Servers* that provide core services such as DHCP and DNS, and onsite monitoring and management.
  • Raspberry Pis for network monitoring.
  • Cameras, tripods, and A/V control equipment for providing the remote participation services.
  • Dedicated IPv4 and IPv6 address blocks that are ‘owned’ by the IETF.

Items marked with * are donated by IETF sponsors - major equipment providers that are significantly engaged in the IETF.

Most of this equipment is enterprise-grade and there are multiple devices of each class in order to provide a high level of redundancy.

The in-room WiFi equipment is primarily installed by the professional conference networking company and the A/V equipment by the remote participation services provider.

5.2.3. Set up and management

The set up generally takes three to four days or work before the Saturday when the IETF Meeting starts.

During the meeting week, the delivery of the IETF Network is as follows:

  • The NOC Lead has overall operational responsibility, which includes daily meetings, coordinating between the different teams and liaising with the Secretariat, LLC, venue and IETF leadership.
  • The volunteer team manages the network, including all connectivity, WiFi access, and core services such as DHCP and DNS.
  • The professional conference networking company manages the physical side of the equipment - power, location, cabling, etc. They also provide all first line support, including staffing the helpdesk. Throughout the week, room configurations change.
  • The professional remote participation services company delivers the remote participation services.

5.2.4. Multiple SSIDs

The conference network is entirely wireless and delivered as a set of SSIDs, each with different characteristics to support different users:

ietf.
The main SSID. Currently this delivers IPv4 and IPv6 with public addresses assigned to each client. It is expected to move to any IPv6-mostly network in due course. This primarily aims to meet the "High performance and robust" expectation, while slowly evolving to meet the "Early adopter of production-ready IETF standards" expectation.
eduroam.
For existing eduroam users. Eduroam is an international roaming service for users in research, higher education and further education. It provides researchers, teachers, and students network access when visiting an institution other than their own. Users are authenticated with credentials from their home institution, regardless of the location of the eduroam access point. This is implemented to support the "Low friction" expectation above.
ietf-legacy.
A hidden SSID for those with old devices that cannot connect to the main ietf SSID. This is generally used by a very small number of very old participant devices (less than 10). This is implemented to support the "Every participant needs to be able to participate fully" expectation above.

There are also SSIDs used as part of the experimental network, described below.

5.3. Experimental network

The experimental network comprises multiple physical networks.

5.3.1. Test SSIDs

Test SSIDs available across all access points, are generally used for users to test new features before they are implemented on the production ietf SSID. A recent example is ietf-ipv6-mostly, which provides an "IPv6-only preferred" network [RFC 8925]. This supports the "Early adopter of relevant, production-ready IETF standards" expectation above.

Test SSIDs are also used to test new features that might become new production SSIDs, separate from the main production SSID. For example, while not implemented, there was discussion on offering a permanent SSID with OpenRoaming, that would have first been a test SSID.

5.3.2. Hackathon network

The hackathon network is primarily intended to support projects that are part of the IETF Hackathon.

For onsite participants, each of the tables in the hackathon room has a wired switch installed and specific networks are created on a per table/project basis as needed. This averages 2-3 networks per meeting. After the IETF Hackathon finishes, those switches with custom networks are moved to the Shared Workspace so that work on those projects can continue.

For remote participants, the IETF NOC maintains a custom router image that can be used, together with a Datatracker account, to build a cheap router that tunnels to the IETF Hackathon network. This service is called HackNet.

5.3.3. Local experimental networks

Very occasionally, a local network is created, either wired and wireless, to support experimentation that has to be kept entirely separate from the IETF Network.

5.4. Hotel network

The IETF NOC works with the hotel IT provider so that a new SSID is added to the existing hotel network (ietf-hotel) and traffic on that is sent to a small IETF NOC router that then backhauls the traffic to the conference network.

Where this backhaul requires a dedicated circuit (as opposed to just running a cable) this is always donated by the local provider of Internet connectivity, and sometimes includes the installation of new fibre just for this purpose.

Working with the hotel network in this way, often shows up issues with installation and configuration of the hotel networking equipment that the IETF NOC assists the hotel in addressing.

The reasoning for this approach is based on the experiences of many NOC members (including those who work professionally on conference networks) regarding hotel networks:

5.5. Remote participation services

The remote participation services provider has an onsite team who operate and monitor the services throughout the meeting. The onsite equipment needed is partly supplied by the services provider and partly by the venue audio/visual services provider. Generally the latter provides the microphones, speakers and sound desk, with everything else provided and managed by the remote participation services provider.

The remote participation service itself is hosted in the cloud.

5.6. Support

The professional conference networking company runs a staffed helpdesk during the IETF meeting (not all day) and they monitor and respond to tickets submitted by email. These tickets may require escalation to a different part of the IETF NOC, such as the volunteers or remote participation provider.

The reasoning for this approach is:

5.7. Network data

In order to meet the expectation of "Good access to network data, without compromising privacy" some network and session participation data is collected during the meeting but network flows are not monitored and recorded. At the end of the meeting aggregate data is extracted and the source data is deleted.

This data is then made available to the IETF community in a number of ways, though these are not widely known about:

The IETF NOC used to present at each plenary session on the use of the network but this was dropped from the agenda in 2019 or so.

5.8. Cost

The total cost of providing the IETF Network for the three IETF Meetings in 2024 was just over $1,000,000, a significant proportion of the total cost of over $4,500,000. This can be broken down into the following buckets, which are intentionally coarse-grained in order to protect contractual confidentiality:

The equipment and circuits are almost all donated by sponsors and so these costs are excluded from the above costs.

6. Meeting networks at other meetings

The following two examples of meeting networks at other meetings, NANOG and W3C, have been chosen to show two different models for meeting networks from the IETF model. The W3C model is quite different from the IETF and the NANOG model is somewhere in the middle. The information presented has been checked with relevant organisation.

Neither are exact matches to the IETF. For example, while NANOG meets three times a year those meetings are solely in North America and while W3C meets globally, it only has a plenary meeting once a year. While both are hybrid meetings, both have a more limited set of remote participation services than the IETF.

6.1. NANOG

The network at NANOG meetings is provided in a similar way to the IETF network with a new network (APs, controllers, switches) fitted by a professional conference networking company, bypassing the venue network. However, the equipment shipped is much smaller and much cheaper to ship as less of it is enterprise-grade.

The Hotel Network however, is the existing hotel network with no modification or enhancement. NANOG does not rely on the hotel's existing network at all. NANOG looks for available spare fiber into the communications room and if the hotel doesn't have any, then NANOG coordinates with a local ISP to have it installed as a Network Sponsor. In some cases, the hotel has fibre they can use (if they don't have any) and the provider might even add a commercial client.

The professional conference networking company operates the whole network, there is no equivalent of the IETF NOC volunteers.

6.2. W3C

The W3C uses the venue network for the meeting network, but works with the venue for some months before the meeting, testing it and helping them fix any issues that would affect its performance. They often contract for additional bandwidth above what their Internet provider normally serves to the venue. The quality of the existing network and the willingness of the venue to work with them are important factors in venue selection.

Venue staff manage the network, for a fee, and no W3C staff or professional conference networking company are employed to do so.

A/V hardware is provided and managed by W3C staff.

The network has received among the highest scores within the logistics ratings in the feedback surveys for recent annual W3C Conferences (TPAC meetings):

7. Areas of disagreement

There are a number of areas of disagreement within the community about the required purposes and attributes of the IETF Network and how it is delivered. Specific disagreements include:

  1. If the networks installed in meeting venues can meet the requirements for a conference network, including the required attributes.

  2. If all the requirements for the hotel network necessary.

    a.
    If so, then if the networks installed in meeting hotels meet those requirements, including the required attributes.

  3. If the IETF Network should support an experimental network.

    a.
    If so, then if it should support the same three physical networks described above.
  4. If the IETF Network should be an early adopter of relevant, production-ready IETF standards.

  5. If the IETF Network should support old (legacy) equipment beyond what might be commonly supported.

    a.
    If so, then what should be the minimum threshold of supported equipment.
  6. If the current provision of network data provides good access to network data, without compromising privacy.

8. Next steps

As noted above, the IETF LLC is unclear on what the path is to resolve these disagreements. This is important because they get to the heart of the requirements for the IETF Network and the resulting provision of that network. The main area of uncertainty is whether this is a community matter that requires a community-led process to determine an outcome such as an RFC, or this is for the IETF LLC to lead on and make decisions through its normal consultative processes.

9. IANA Considerations

This memo includes no request to IANA.

10. Security Considerations

This document should not affect the security of the Internet.

11. References

11.1. Informative References

[BCP205]
Best Current Practice 205, <https://www.rfc-editor.org/info/bcp205>.
At the time of writing, this BCP comprises the following:
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[BCP226]
Best Current Practice 226, <https://www.rfc-editor.org/info/bcp226>.
At the time of writing, this BCP comprises the following:
Lear, E., Ed., "IETF Plenary Meeting Venue Selection Process", BCP 226, RFC 8718, DOI 10.17487/RFC8718, , <https://www.rfc-editor.org/info/rfc8718>.
Krishnan, S., "High-Level Guidance for the Meeting Policy of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, , <https://www.rfc-editor.org/info/rfc8719>.
Duke, M., "Considerations for Cancellation of IETF Meetings", BCP 226, RFC 9137, DOI 10.17487/RFC9137, , <https://www.rfc-editor.org/info/rfc9137>.
Daley, J. and S. Turner, "IETF Meeting Venue Requirements Review", BCP 226, RFC 9712, DOI 10.17487/RFC9712, , <https://www.rfc-editor.org/info/rfc9712>.

Acknowledgements

Thanks to multiple members of the IETF NOC for their help in ensuring the accuracy of this document, particularly Joe Clarke, Sean Croghan, Colin Doyle, Con Reilly, Simon Pietro Romano. Thanks also to Roman Danyliw and Victor Kuarsingh for their reviews.

Author's Address

Jay Daley
IETF Administration LLC
1000 N. West St, Ste 1200
Wilmington, DE 19801
United States of America