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)
          
          . Opening - 10 min (Chair)
          - Note Well etc.
          - Agenda bashing
          - I-D status
          
          See chair slides.
          
          . 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.
          
          . 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.
          
          . 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
          
          . 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.