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.