When: Thursday, July 29, 2021, 16:30-17:30 UTC-7
Chairs: Mirja Kühlewind, Jared Mauch
Jeffrey Haas: One of the headaches is that extensibility is hard to prove until you’ve tried to do the first version of that extension. BGP being a flexible protocol, we have to do a lot of inner work to make sure you can do the next thing for the extension. One thing I would encourage is to find a way to prove out the n+1 case.
Bob Hinden: We have a lot experience in IPv6 with extensions headers, hop-by-hop headers, and it’s not been a wild success. I think the particular problem in hop by hop headers, but the worst is middleboxes that filter and don’t want to look at the whole packet. It’s a really hard problem and I am supportive of this work, but it’s going to be challenging.
Eliot Lear: I had a look at this draft when it initially came out, and I reviewed it again. If we didn’t have the reserve space, I’m not sure we’d know what to do about multicast. I think what you’ve done in the IAB in this doc is more applicable at the upper layers than the lower ones. It’s hard to know what’s in use where. I think it’s worth developing that concept a bit in your work.
Toerless Eckert: I think it’s good getting that example with the multicast. The layer difference between 3 and 4 is probably the unit of time that is in the time of “use it” may be orders of magnitude larger. Putting the undesirable middleboxes out of scope, maybe then we can figure out if it’s p2p or multicast.
Tommy Pauly: In previous calls, we did talk about the nature of the problem and what “use” means is different at different layers. I think that’s something we can capture.
Martin Thomson: The draft intro addresses this; it’s predominantly at higher layers of the stack. We do have some examples at lower layers, but they are not necessarily very good. The IP extension header discussion is an ongoing one that I don’t think we can really draw from at this point. I think we’re getting there, but I am not enthusiastic about trying to formalize the difference. One thing is that the cadence at which updates occur may shape the response you have, but that doesn’t mean they are fundamentally different.
Bob Hinden: I think a way to characterize this is, it’s much easier to update or extend when you only have to change 2 hosts. QUIC is a good example of this. It’s harder when you have to change everything along the path in order to do it. It’s not layering, but how many things have to change. With VRRP, it’s 2 boxes. For IPv6, you have to do it globally. There is different kinds of scaling to think about here.
Adrian Farrel: Thanks, that was helpful and clarified a lot for me from the draft. In slide 4, there were 2 things that struck me. One was that the middle box (of the chart), the info that is needed for the task is a really dangerous door to open, because one person’s need is another person’s bad idea. That leads to the consent of parties thing. We see that with the geolocation stuff. An application’s decision is not the same as user consent, and user consent isn’t necessarily the user understanding what they are doing. Please bring these thoughts to the APN BOF, because it’s pertinent.
Jari Arkko: Yes, that was one of the inspirations for this.
Toerless Eckert: It very much looks like what is important but difficult is to make these work over the most difficult scenario, so it would be useful to have a list of different categories of scenarios, from everyone trusts everyone, to the open Internet. We’ve done a lot more security for these limited domain networks, the ANIMA work, hop-by-hop link encryption, secure nodes. There are a lot of options here and would be nice to not only focus on the ones for the Internet. Humongous number of private and limited use domain networks.
Jari Arkko: There is something here about the future that we need to do as well. Thank you.
Jeffrey Haas: I think there is a place in between here that I’m not sure was covered. Part of the problem for the signals is it’s a matter of scoping. Many are designed to go end-to-end and it may vary depending on where you are in the network. Maybe that should be called out as an explicit point.
Ted Hardie: I want to talk to points also being made in chat. In a lot of cases, when we are talking about path signals, we are talking about ones where actions taken as a result of a signal are advisory, not a command. The decision on what action to take is not set in stone. I think in a lot of the cases, what we are trying to work out is what are signals that are useful to send across the path, and are useful to both ends of the flow as well. The most controversial one is the source quench issue; the Internet had it at one point, but it was dangerous so it was dropped. In a well-constructed protocol, the sending side will know that’s happening at some interval and there will be a withdrawal of consent. The question is, if you have a bad sender, is there any advisory mechanism to send to the path to say this is being dropped? The critical thing that stopped this work is it’s difficult to know what signal you can send that isn’t subject to an injection attack. Letting the path know that it’s not an injection attack is very difficult indeed. It’s an “area for research” instead of “engineering” for a good reason, to figure out if there is a mechanism to let those advisory mechanisms demonstrate that they can take the action that they are claiming to take. That’s why there’s not a proposal I-D on this yet. Thanks.
Mark McFadden: I wanted to react to the characterization of Model-T. I went back and looked and the last time the IAB convened a Model-T meeting was exactly a year ago. In that year, the IAB hasn’t convened a meeting, but members of the community have worked on drafts. I think what is missing is rather than an IAB review of the program, putting some energy back into having Model-T meet. There are community members who are willing to contribute.
Mirja Kühlewind: That is true, the leads of the program haven’t set up a meeting and the IAB hasn’t been much involved, but that is also part of the review that the IAB wants to take, because an IAB program needs IAB backing. It’s not a pure community group; we need to have some interest from the IAB to keep it driving. That’s the purpose of the review.
Jari Arkko: I agree with the characterization that it’s a leadership problem for the program, and I’m part of the leadership there. So let’s fix the leadership and do something.
Watson Ladd: In Model-T, there was a big gap in participation, and discussion has really dwindled, and there is little prospect of progress towards those issues. I’d like to see some path forward before we say another round of whatever is going fix it.
Jari Arkko: I also agree with this statement. I think there has been a gap on what exactly it is we’re doing. There is no progress toward a solution. No agreement on what should be produced; there are many alternatives. I am in favor of short high-level RFCs from the IAB. But there has been a lot of interest in looking at the detailed technical solutions. But it’s also a problematic area, so many dependencies, and it’s not an easy thing to tackle. Part of this is baked into the problem.
Mirja Kühlewind: We didn’t have an extensive report on this program because we haven’t had the IAB review yet, but we can report back next time and tell you what we want to do with this.
(End of Open Mic)