Minutes IETF114: manet
minutes-114-manet-01

IETF-114 Joint Babel / ROLL / MANET WG meeting agenda
When: Friday, July 29, 2022, Session 1, 10:00 - 12:00 EDT (14:00 - 16:00 UTC)
Where: Freedom G + online
Meetecho: https://meetings.conf.meetecho.com/ietf114/?group=manet&short=&item=1
Chat: https://zulip.ietf.org/#narrow/stream/manet
Notepad: https://notes.ietf.org/notes-ietf-114-manet
Chairs: Ines Robles (ROLL), Dominique Barthel (ROLL), Donald Eastlake (Babel),
Don Fedyk (MANET), Ronald in 't Velt (MANET)

1. Chairs’ Introduction (5 min)
* Note Well, etc.
* Agenda bashing

2. Introduction to joint session - joint chairs (5 min)
* Purpose

3. Multicast in MANETs - Ronald in 't Velt (15 min)
* Juliusz Chroboczek: caution about the assumption that radio is slower than
computer. Especially with processing in user space. * Zhaohui Zhang: given the
constraints you mentioned, BIER would be a good solution for multicast for
MANET. See presentation later in this session.

4. Let's talk about the IP multicast data plane - Henning Rogge (15 min)
* David Lamparter: Linux Multicast designed to deal with consistent broadcast
  domains. The fact that one restriction is lifted (outgoing IF) does not make
  it valid for MANET multicast. Not intended for MANET, concerned that things
  would break if it were used for this purpose.
* David L: do you really want to do duplicate detection? scaling problem.
Usually not the right thing to do. Also, part of normal operation for some
protocols, that you are going to break. IP forwarding is not meant to eliminate
duplicates. You should not / cannot do that. This also applies to multicast
routing. It should not contain duplicate detection. * Henning: I agree with
most things you say, but I don't think we break less things by doing raw
sockets. * David: We have more tools coming * Juliusz: I liked the talk until
slide 16. You said let's not do code in the kernel, then you do eBPF (extended
Berkeley Packet Filter) code which is in the kernel. The problem is we don't
know what we want the kernel to do. Our problem is there is too strong a
coupling between the control plane and the data plane. We don't have a good API
for Multicast that will work for all protocols. We don't have a good idea what
we want the kernel to do for our needs. * Henning: It would be nice to have
some API in the kernel I do agree, but it depends on what type of network we
have. Depends on the radio characteristics. High speed Wifi, low speed VHF/UHF
radio. We might deploy something different in these cases. * Juliusz: we don't
fully understand the problem yet. * Henning: Agree. * Donald Eastlake:
Duplicate detection can't just be based on the packet; it needs to be where it
entered the network, not just that, packets need to be binary identical. *
Ronald: SMF adds an extension header, an IPv6 extension header. * Lou Berger:
would be helpful to discuss how end-hosts and routers fit into the solution. In
RAW, the wireless network is just part of the overall network. One of things
I've been grappling with is how do you integrate all your routing information
in a wider routed network and allow them to be separate but allow for example
for transit traffic. * Ronald: Yes, that adds an extra dimension, makes it even
more complicated * Henning: Yes, there are transit routes for unicast an
multicast and we don't even know how to handle multicast in the MANET. We
should not forget external networks, but we first need a good data plane. If we
don't have this we have trouble even figuring out what we need. This is a good
point to start with. * Rick Taylor: I like the presentation. These are great
tips and tricks to prototype. Some radio segments (?) I think in MANET we have
the bandwidth to figure out what those protocols should be. I need a multicast
domain that spans my fixed network and my wireless network. It might be more
than a laptop connected to the network but even a small subnetwork. A
heterogenous network like Ronald's diagram early on is more relevant for the
working group than how we beat Linux into submission. * About duplicate
packets, radio systems are becoming smarter, doing a lot of duplicate
elimination anyway. The naive way of not doing duplicate elimination at IP
layer is the right way to go. If the lower level determines there are two
packet that are identical, the IP lay should just forward those. It is not the
IP layer's business to do the deduplication.  We need to keep that separate. *
Henning: I don't think we can push the problem down to layer 2. It is not
always helpful not with multiple-radios. * Rick: Always been the problem with
MANET at the IETF we are supposed to be L3-focussed but should not ignore
what's going on at L2.

5. Multicast in IEEE 802.11s - Donald Eastlake (15 min)
* Donald was chair of IEEE 11s working group for half of its existence.
* David: One spanning tree for all traffic.
* Donald: Yes as I recall.
* Henning: 11s reportedly only works for a few nodes it did not scale. The
older adhoc mode does not work well for MANET. * Donald: I do not support the
current path selection algorithm. There could be better alternative for routing
in 802.11s. * Juliusz: Slide 16, conversion of Multicast to Unicast.  Are you
slamming the whole mesh? * Donald: You are serially unicasting to a list of
peers.

6. BIER for Babel - Zhang Zheng (15 min)
* Jeffrey(Zhaohui Zhang): want to add that BIER achieves efficient multicast
forwarding without building a tree. Most efficient mechanism. * Jeffrey: lack
of hardware-based solution has hindered adoption, but can be implemented in
software, especially for low data rate radios. * Juliusz: No opinion on whether
BIER is a good solution or not. But can you claim that BIER does not suffer
from the duplication detection problem? Does not suffer from the problem that
Ronald points out. * Juliusz: the ideas behind BIER should definitely be looked
at for MANET * David L: Like to point out some points about [BIER] as it would
apply to MANET: it is important to point out that when we have a case where a
mesh node is about to forward a multicast packet to another mesh node that
forwarding in BIER is always unicast.  Whether that is a good thing or bad
thing depends on mesh properties. So you do only send it once. This are could
be worked on. Does not use multicast capabilities of the radio. * David:
comparing to MLD, moving labelling from destination to sender. * David: Another
layer of encapsulation. BTW, 11s is also some sort of encapsulation with the 6
addresses. * David: Should figure what the best encapsulation mechanism is
rather than trying to make it work without encapsulation. The way to avoid the
deduplication is to add a layer and the tend to allow better routing behavior.
* Zhang: BIER with IPv6 uses extension header, not encapsulation. Just read the
next header. * David: I was unclear, but this is what I meant. In BIER Babel
work there is a thing missing is figuring the identifier for the BIER nodes for
the bit positions. * Zhang: Only the edge routing needs to be assigned for
this. * Henning: We just need deduplication for dense mode. BIER uses unicast
trees, keeping track of which * Zhang: Only the topology is carried in the BIER
forwarding and the Egress Routing. * Jeffrey: with BIER, can receive traffic
over one link and forward it over the same link, no problem * Lou: I'm new to
BIER. Is adding a new layer and I think add want to generalize David's question
of encapsulation mechanism to layering mechanism. What layering mechanism we
think about.

7. Multicast in ROLL - Pascal Thubert (15 min)

8. And now for something completely different: Exciting features of the Babel
routing protocol - Juliusz Chroboczek (10 min) * Henning: Source specific
Routing which version is supported. * Juliusz: version 6 only. * 9. Discussion
- all (20 min) * Commonalities / Need for protocol action / Operating System
aspects * David: Ties in to the Babel presentation the hardest problem is
assigning identifiers in BIER. Either mesh becomes its own multicast domain. 
If the signal mechanism can be designed in a protocol agnostic way. Then there
is no problem of transferring this to OSPF or ISIS. * Henning: We need
something in the forwarding plane. Has someone experimented how well MPLS works
in the MANET environment? * Jeffrey: BIER can work with MPLS, but does not
require it. It can work with any L3. * Jeffrey: Regarding in MPLS (BIER?) in
MANET, does not take advantage of multicast of radio. Only neighbor based. BIER
encapsulation is not limited to layer 3. * Juliusz: coming back to David's
points. Alternative to encapsulation is
  duplicate suppression, which breaks protocols that use duplicate (DHCPv4)
and puts unbounded amount of state in control plane. Is there a third
possibility? This would make Lamperter triangle. * Lou: on MPLS, it's a data
plane but also control plane. Data plane perspective Stackable label is a nice
property, could be reused. MPLS control plane is not applicable. * Lou:
Leverage Ethernet address, would be the third leg of the triangle. * Toerless
Eckert: as pointed on the ROLL mailing list, already starting evaluation of
BIER in ROLL, for multicast and also unicast routing with less state. *
Toerless: Also, BIER-TE, now in Auth48. ROLL would benefit from it, but needs
topology information. Like RSVP-TE for MPLS. * Rick Taylor: The churn in MANET
is so high that sending topology information is out of the question. * Rick:
About duplicate detection: generic deduplication in MANET is not what we want.
Specific deduplication in MANET is not what we want. Lous suggestion of use L2
may be interesting. * David: with BIER suggested in ROLL, why was that phased
out? * Michael Richardson: pandemic * David: willing to resume effort ?

10. Wrap-up of multicast session - joint chairs (5 min)
* Ronald: keep discussing this on the Mailing List.
* Alvaro Retana (AD): the WGs have different technologies and different needs.
But keep try to keep the discussion going, instead of returning do our own
stuff * Alvaro: maybe have meetings like this one more often. Keep building up,
not just having an informative meeting every so often.