Minutes IETF110: manet
minutes-110-manet-00

MANET WG Minutes IETF-110
=========================

Date: Friday, March 12, 2021
Time: 1530-1630 CET
Location: Meetecho Room 7
Chair: Ronald in 't Velt <ronald.intvelt@tno.nl>
Responsible AD: Alvaro Retana <aretana.ietf@gmail.com>

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.