TSVAREA Agenda
IETF 100
Thursday, 1810-1910 in Panang Room
Administrivia 10
- Note Well ADs
- Agenda Bash ADs
- State of the Area ADs
From the ADs: Thanks to the TSV Area Review Team (TSVART) and the draft triage team for all the help they give us.
Path Aware Networking Research Group: looking for inputs for a draft on link-aware and path-aware networking proposals that haven't worked out well in the past. Spencer will contribute his trigtran experience.
-- NETDEV 2.2 Update Mirja --
Link to presentation at https://datatracker.ietf.org/meeting/100/materials/slides-100-tsvarea-report-from-netdev22-mirja/
Technical conference on Linux networking - NetDev 2.2 was last week in Seoul.
Strong focus on performance and offloading, including eBPF (enhanced Berkeley Packet Filter).
Mirja provided links to a number of interesting presentations at this year's meeting (see her slides for details).
Coordinating Specifications and Interop Testing
- Current practice in HTTP/2 Interoperability Mark Nottingham
See slides at https://datatracker.ietf.org/meeting/100/materials/slides-100-tsvarea-http2-interop-approach-mark/
Interop events at every interim meeting. Designating implementation drafts was important - HTTPbis went from a couple of implementations to 10 implementations.
Version negotiation was very helpful.
What to focus on at interop events is an intelligent judgement call based on state of drafts and sense of where the implementations are and/or could be soon.
Designating interop draft versions provided some focus, but people still implemented to other versions, and that worked at interop testing events because HTTP could negotiate versions well.
Designating implementation drafts turned the conversation from paper discussions to running code discussion.
-- Current practice in QUIC Interop Lars
Slides are at https://datatracker.ietf.org/meeting/100/materials/slides-100-tsvarea-quic-interop-approach-lars/
Based on HTTP/2 experience, but QUIC is more complex than HTTP, so doing more work to keep core drafts in lockstep on version numbers.
Ordered list of features/functionality to test at each interop event helped - implementers with limited resources went down list and focused efforts on items near top of the list.
Headed towards doing testing on an ongoing basis - implementers leave servers up and other implementations can use them for testing.
Mirja asked about a test suite, so that implementers could check that they're getting valid results, both on code they're writing and on code they've modified - regression testing will be more important. Lars said he agreed, although QUIC wasn't ready for that yet - he and EKR both have ideas that might be helpful.
Mirja asked how many Hackathon participants working on QUIC are staying for IETF week. Lars thinks most of them stay, although it's hard to tell - there's overlap with other communities, like TLS, and they had about 17 participants at IETF 100, including remote participants.
We had a diversion during Q&A, although it's an important one, about networks that want to block QUIC.
Lars is seeing different people at interims who don't come to IETF meetings - probably more implementers. They have about 50 people in the room and about two thirds are actually participating in the meeting - and interop testing also happens just before interim meetings.
Brian Trammell observed that this is a new way to run a working group. Really like the idea of automated testing suites, and that would be useful in other places in TSV. Do we need a transport layer tooling "something"? Yes, and not just transport. Perhaps we can steal ideas from the way QUIC does things for other protocols. QUIC is sufficiently encrypted that a test endpoint really need to be a QUIC endpoint, if you want to inject test packets.
Gorry Fairhurst asked how people can understand QUIC when it's moving so fast. Lars says that IETF meetings are useful checkpoints with the rest of the community (for example, the congestion experts are at IETF meetings, but not at QUIC interims). We have no smart ideas, except to focus on one or two topic areas so we can make progress.
Lars mused about the purpose of the various meetings that QUIC could be using - the different types of meetings have different advantages and disadvantages.
-- Semantic versioning - Spencer
Slide is #10 of this link: https://datatracker.ietf.org/meeting/100/materials/slides-100-tsvarea-chair-slides/
Spencer presented a proposal from the YANG community that's being considered to allow YANG models to evolve quickly - faster than changes can move through the normal IETF publication process, so they can keep specifications synchronized with Open Source work.
One key point here is who can approve major revisions, minor revisions, and patches. Benoit has a proposal about that, too.
This isn't what the YANG community is doing now - at least, not yet. But it's something for TSV people to think about.
-- Open Mike - ADs
Brian Trammell said that IPPM has done some interop tests, but they've mostly worked to ensure that different implementations return consistent results. That work hasn't demanded tight tolerances and calibration for testing, but as IPPM evolves, that could change.
Spencer asked people to be thinking about these issues in other working groups, and share what they come up with.
Brian Carpenter pointed out that the protocol number registry has been the subject of neglect for decades, and needs to be cleaned up. If you're motivated to help with this, please contact Brian. Lars thinks that's more work than is worth doing. Mirja agreed that this is a lot of work, but she's in the process of cleaning up the port/service registry now, so let's talk after that.
(Clarification, and thanks to Joe Touch asking the question on the mailing list: Mirja confirmed that what was being discussed on the registry cleanups was not reclaiming values. We are updating the contact information and references to existing RFCs. We will not revoke any registrations.)