Filter by topic and date
IETF 104 Preview
- Alissa Cooper IETF Chair
20 Mar 2019
For our 104th meeting we will be returning to one of the IETF’s favorite cities: Prague, Czech Republic.
We are on track to break our IETF Hackathon attendance record, with more than 275 people signed up to work on more than 40 projects over the weekend of March 23-24. This weekend we will also host the Code Sprint focusing on building tools for the IETF community, a tutorial explaining how to author Internet-Drafts in the new RFC format that is rolling out starting next week, and the HotRFC session featuring lightning talks about new ideas and opportunities for collaboration.
This is also the second time in less than a year that we are benefitting from co-location with Netdev, the technical conference on Linux Networking. Netdev is taking place March 20-22 in Prague and features a variety of talks relevant to IETF protocols, including a keynote by yours truly.
As we move into the meeting week itself, we will have six sessions focused on potential new work, spanning nearly all of the IETF’s technical areas. Check out my previous blog post for details on those.
One of the most compelling aspects of the IETF meeting week is the opportunity for cross-cutting discussions about technology developments that have the potential for broad impact on the networking industry and the Internet. IETF 104 will feature discussions on a number of topics that fit this mold, including:
- Deployment considerations for DNS confidentiality. The last several years have seen the standardization of RFC 7858 (DOT) and RFC 8484 (DOH), new encrypted transports for recursive DNS resolution. A fiery debate about deployment models, resolver selection, and many other aspects has ensued. Expect to see the many facets of these discussions explored in real-time during the DOH, DNS PRIVate Exchange (DPRIVE), and DNS Operations (DNSOP) working group sessions, as well as during one or more side meetings.
- Segment routing (SR). Segment routing is a source-routing paradigm that allows for end-to-end policy to be applied within an operational domain without maintaining flow state in the network. With the architecture, use cases, and other foundational RFCs published, the specific protocol extensions needed to realize SR are moving towards maturity. Check out the discussions in the Source Packet Routing in Networking (SPRING), IPv6 Maintenanc (6MAN), Multiprotocol Label Switching (MPLS), Inter-Domain Routing (IDR), and BGP Enabled ServiceS (BESS) working groups.
- QUIC. The march to standardize an alternative transport protocol to TCP that is more performant, secure, and flexible to deploy continues. In addition to the QUIC working group’s sessions, look for discussion of operational aspects in Transport Area Open Meeting (TSVAREA), HTTP aspects in Hypertext Transfer Protocol working group (HTTPBIS) session, and a research talk in the IRTF Open Meeting (IRTFOPEN).
- In-situ Operations, Administration, and Maintenance (IOAM). IOAM inserts operational and telemetry information in a packet while that packet traverses a network path, allowing for measurement in cases where sending out-of-band measurement traffic is unworkable. The core specification will be discussed in IP Performance Measurement (IPPM) with protocol-specific extensions and encapsulations to be discussed in Service Function Chaining (SFC) and IPv6 Maintenance (6MAN).
- YANG versioning. A design team formed out of the Network Modeling (NETMOD) working group has been hard at work evaluating a variety of requirements and proposals for improving how YANG data models are versioned and updated. Given how pervasive YANG data modeling is becoming, the implications of this effort have the potential for broad impact on configuration, management, and routing.
Those with more of a research focus will be pleased to know that every Internet Research Task Force (IRTF) Research Group (RG) is meeting at IETF 104 (which is a bit unusual since RGs tend to meet elsewhere during the year as well). Of special note will be the quantum Internet tutorial taking place during the Monday afternoon Quantum Internet Proposed Research Group (QIRG) meeting.
Wednesday will be organized a bit differently than at a typical IETF meeting. The IESG is continuing to experiment with inclusion of unstructured time during the meeting week, in response to interest from participants. Wednesday afternoon will feature unstructured time with meeting rooms available for side meetings. During this time we will also host a Technology Deep Dive - Modern Router Architecture session designed to explain how a modern router is architected, and how it differs from the mental model/traditional view of how a router works. We will finish the day with the administrative plenary where we will recognize outgoing IETF leaders and introduce those new to the leadership, including the first presentation and open mic session for the nascent IETF Administration LLC Board of Directors.
Finally, I’m personally excited to see the first meeting of the GitHub Integration and Tooling (GIT) working group in action, where participants are seeking to document a set of policies and practices to support the optional use of GitHub by IETF working groups. Those already making use of GitHub to manage IETF work and those interested in starting should plan on joining.
We always have productive meetings in Prague and IETF 104 is shaping up to be no exception. Many thanks to meeting co-hosts CZ.NIC and Cisco for helping to make this meeting happen. I hope to see everyone in Prague, or participating remotely at IETF 104!
Bibliography
-
[1]RFC 7858
Specification for DNS over Transport Layer Security (TLS)
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage pr…
-
[2]RFC 8484
DNS Queries over HTTPS (DoH)
This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.