MANET WG Minutes IETF-110 ========================= Date: Friday, March 12, 2021 Time: 1530-1630 CET Location: Meetecho Room 7 Chair: Ronald in 't Velt Responsible AD: Alvaro Retana Meetecho: https://meetings.conf.meetecho.com/ietf110/?group=manet&short=&item=1 Note taking: https://codimd.ietf.org/notes-ietf-110-manet Jabber: xmpp:manet@jabber.ietf.org?join (AR = Alvaro Retana, responsible AD; LB = Lou Berger; RT = Rick Taylor; HR = Henning Rogge; AB = Abdussalam Baryun; RitV = Ronald in 't Velt) 1. Opening - 10 min (Chair) - Note Well etc. - Agenda bashing - I-D status See chair slides. 2. DLEP Flow control I-Ds - 10 min (Lou Berger) https://datatracker.ietf.org/doc/draft-berger-manet-dlep-ether-credit-extension/ https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-credit-flow-control/ https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/ https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification/ LB: History of these documents: draft-berger-manet-dlep-ether-credit-extension just got a little bit behind the other ones for no compelling reason. It is really part of the same bunch. LB: Question to chair and WG: Progress or abandon work? RitV: Please continue, I am reviewing and will ask others to do so as well. RT: I fully support progressing these documents. Let's also adopt draft-berger-manet-dlep-ether-credit-extension as a WG document. RitV: In particular, I would like to ask Rick Taylor to review these for consistency with the LID extension (RFC 8703). RT: The mechanisms should be complementary. I had both document (sets) in mind while writing the LID draft. LB: I really appreciate that comment. Henning Rogge had asked me in private about the overlap with the LID extension. Slide 9 of my presentation shows the differences. Queue identification is a little different from link identification; it is possible for different 802.1 priority bit settings or different DSCPs to map to the same queue. We don't want to consider these as multiple links. Rick Taylor and I did once talk about an extension that takes sharing of resources into account, though. HR: I did not work on flow control much, because I had issues with implementing a prototype. Without the ability to test with real routers and radios, it is difficult to form a good opinion on the drafts. I could use suggestions on how to implement flow control in Linux, on the router side. RT: Henning, I agree. I have a presentation later about implementation experience. There may be a need for an informational document to give more advice to implementers. I know the IESG does not like WGs to produce a lot of informational documents, but this one should have real value. AR: We should have the TSV Directorate look at these drafts as well. I will send an email to Ronald on how to initiate that. RT: I seem to recall that TSVWG has on informational document describing which fields in the IP header can be used for the classification of flows. TSV may come back and propose that a more generic approach than just using DSCP be taken. LB: We spent a lot of time on that discussion in the Detnet WG. 6-tuple is the most modern approach. HR: I was not talking about the signaling part of flow control, but about a mechanism to stop the flow on the router side. I have not found a good solution for that. The signaling is the easy part. Treating multiple flows differently is particularly hard to implement. If there is no good way to do the data plane part of flow control, then the signaling is meaningless. RitV: I see what you are saying, but there is not much for the IETF to do on this aspect; it's implementation. LB: I agree that it is not part of standardization, but PPPoE [RFC 5578] implementations have solved this problem by using a custom Linux driver. That is a worst case solution. HR: I have thought about writing a custom queueing discipline. LB: I have not looked at all the disciplines you can configure with 'tc' well enough to know if there is one that does what you want. 3. PHY-related DLEP extension I-Ds - 20 min (Henning Rogge) https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-radio-band/ https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-channel-utilization/ https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-radio-quality/ RT: (on Henning's plans for future extension I-Ds) I wrote a personal draft in 2017 on Service Discovery. I came to the same conclusion that it makes no sense to re-invent the wheel. I would be happy to collaborate, it should be reasonably simple. HR: We have an implementation. It is a just a bootstrapping mechanism that points to existing solutions (e.g., DNS or HTTP=based). RitV: At the moment, we have these three very short PHY-related I-Ds. Even though they could be fleshed out a bit more, the question is whether we keep them as separate documents or merge them. RT: The decision should be guided by the way they are implemented, i.e., whether each of these constitute an extension type. Keeping them separate allows vendors to indicate more clearly which features their implementations support. Use as a guide whether extensions are logically related or not. I believe we want one document per extension type. HR: At the moment, they are different extensions, because they do not seem much connected. Some radios may not support all of them. Iam not sure it is a good idea to merge them. LB: One document per extension / one extension per document makes a lot of sense. RitV: I just had a slight concern that there might be push-back from our AD / the IESG on multiple very short drafts. HR: The Extension ID is 16 bits, so we could have many more. RT: On the other hand, supporting an extension does not mean that you have to support every data type in that extension. "Supporting" means to not terminate the session when you receive that particular TLV. HR: Stating support of a specific extension, e.g. link quality is much more meaningful than stating support for a generic PHY extension. AR: It is up to the WG to decide on this. Less documents make my life easier, but that is not the objective. Declaring support by referring to a specific RFC (Henning's point) makes sense. RitV: Thank you for clearing that up. 4. Proposal for a DLEP clarifications & Lessons Learned I-D - 10 min (Lou Berger + Rick Taylor, Rick presenting) LB: Small comment on transaction handling: It should say "may cause interruption of the data plane" rather than "will cause interruption of the data plane". HR: On RLQ: now you know why I fought so hard to have this item as optional instead of mandatory. RT: I agree. LB: I should have looked at the latest version of the slides, because w.r.t. multicast, I disagree on the need for IGMP snooping. Appendix C3 of RFC 8175 says that routers should be sending Destination Announces and modems should listen to those, so no snooping by modems should be required. RT: You are referring to a non-normative appendix; this point should be clarified in the normative text. LB: I seem to recall that it is there; it is completely unambiguous. That said, I am perfectly happy to have an informative document. HR: I agree that we do not need an 8175-bis document. Most implementers on the radio side just push metrics and are not affected by the problems found. We just need a way to give implementers guidance on the more complicated issues. RitV: What would the status of the proposed document be: informational or standards track? RT: I defer to our AD and others such as Lou on that. Lou introduced me to the concept of a "formal update". LB: The document would be a proposed standard. An Update is something an implementer should go read. However, it does not change the basic protocol formats. AB: For Henning's PHY-related extension we should maybe use the MANET message format (RFC 5444). Also TCP is used, but what about UDP? HR: That discussion is far behind us, let's not re-open it. RitV: We are running out of time. Abdussalam, please take your question to the ML if you want to discuss it further 5. Future work - 10 min (chair, open mic) RitV: We are out of time. I wil bring this agenda item up on the ML. Thanks to all presenters and attendees.