# IETF 114 - ROLL Meeting 17:30 - 18:30 UTC - Tuesday Session II - 26th July 2022 Material: https://datatracker.ietf.org/meeting/114/materials/ ## Attendance (a.k.a. Blues Sheets) is automatically extracted from Meetecho https://www.ietf.org/proceedings/114/bluesheets/bluesheets-114-roll-202207261330-00.txt ## Agenda +----------------+----------+---------------------------------------+----------------+ | Time - UTC - | Duration | Draft/Topic | Presenter | +----------------+----------+---------------------------------------+----------------+ | 17:30 - 17:45 | 15 min | Introduction - WG Status | Ines/Dominique | +----------------+----------+---------------------------------------+----------------+ | 17:45 - 18:00 | 15 min | draft-ietf-roll-dao-projection | Pascal | +----------------+----------+---------------------------------------+----------------+ | 18:00- 18:20 | 20 min | draft-ietf-6lo-multicast-registration | Pascal | +----------------+----------+---------------------------------------+----------------+ | 18:20 - 18:30 | 10 min | Open Floor | Everyone | +----------------+----------+---------------------------------------+----------------+ ## Action points * Chairs to ping Rahul on the new loop avoidance mechanism and text in dao-projection. * Chairs to ask one last time on ML about dao-projection. * Chairs to involve PIM WG in the 6lo-registration last call. * Pascal: add text about why ROVR not used in multicast (6lo-registration). ## Meeting notes (local time) [13:30] Intro, WG status (Ines/Dominique) * Note Well * Note takers: Ivan and Laurent, jabber scribe: Michael * Agenda bashing - comments? no comments * Draft status * Milestones, Open Issues * There will be a joint meeting Friday morning with MANET and BABEL, on multicast. Also a BOF on multicast. [13:36] draft-ietf-roll-dao-projection (Pascal) * Pascal: DAO projection builds RPL Instances inside a RPL Instance (think of them as overlays). * Overlay is a DODAG, allows to reach destination considered "external" as per RFC9008. * Typically RPL in storing mode inside the "overlay", and non-storing mode overall to connect the overlays. * reminds definition of Segment (serial direct sequence of node), Leg, Track (complex collection of possibilities for a path). * Meant to do traffic engineering for RAW. Root directly installs routing state into a RPL network. * several reviews, 1 issue found and a lot of cleaning up. * comments by Dominique in the draft source code on GitHub, summary of discussion posted on the mailing list. * DAO can contain SIO, happens to extend neighbor knowledge to 2 hops. * Clarification added to explain the scenario (router learns 2-hop destination), amendment to RFC6500 on multicast DAO. * Cisco IPR revolving around this, declared it just to be safe. * discussion on loop avoidance with multi-topology routing: precedence among ways to forward a packet * first: 1-hop neighbor, second: 2-hop neighbor, third: Segment, fourth: Track * Rahul has a Pull Request on the draft text about loop avoidance. Would like to have his view on the new text. * Note that forwarding along a Segment could have used 2-hop neighbour info down the segment (1-hop-loose). * Don't want to change specification now: 1-hop forwarding down the segment, and 2-hop possible only at the egress of the Segment. * makes the whole mechanism sligthly inconsistent, 2-hop forwarding is allowed within Tracks but not withing Segments. * Maybe discuss this again. * Added clarification that multiples instances use separate RIBs. Was already the case in RFC6550, but made it explicit here. * new version -28 will be issued soon with responses to Dominique's comment * Ines: Comments about using the common neighbours for forwarding? * Pascal: similar to next hop discovery protocol. Common neighbour will relay without a loop. RPL was not using it because no notion of sibling with RFC6550. * Ines: about overlapping legs, when will it be needed? Inter-leg Segments (North-South) (see work in RAW). * Pascal: North-South we can't do here. * Pascal: this work is needed for the RAW work. RAW defined Tracks. Tracks is RAW slightly augmented compared to here. * Pascal: RAW wants to do checkpoints on parallel East-West routes, with a North-South link to control replication. * RPL does not have routing through siblings. Was discussed early on but left out. RAW has a little bit more. * Ines: how to differentiate a Track from a "complex" Track? * Pascal: "complex" not a defining term. Just means not serial, has multiple choices for forwarding. * Pascal: similar to upward routing in RPL: node has multiple parents, but forwards packet to only one parent. * Ines: any objection to closing this document at -28? * Dominique: We have been working on this for a while, what is your opinion Pascal about the stability and convergence of the document? * Pascal: There has been a lot of clarifications, but I think it's going in the right direction. * Pascal: even the 2-hop forwarding thing was already in there, but maybe people had not realised. Let see if comments come up after this clarification. * Pascal: last few versions (including large text rework following Toerless'es review) have only been editorial, we are not diverging. * Dominique: Do you think we have converged on this document, can we proceeed? * Pascal: have a question to Alvaro about normative ref to RAW arch document for the terminology. Because it's terminology, made it normative. * Pascal: but RAW arch is still in the works (last call). And, btw, probably going to end up as informational doc. * Pascal: so we have a downref to informational, and delay. Could copy terminology in this document. What do you recommend? * Alvaro (resp. AD) : having a ref to another document for the terminology is the right thing to do, rather than copy in. * Alvaro: don't worry about the downref. Don't worry about the sequencing either. * Pascal: I'll submit -28 then you press the button? * Dominique: unless we hear a strong opinion to the opposite. [14:04] draft-ietf-6lo-multicast-registration (Pascal) * Pascal: A work that started in 6lo that impacts 6lo, 6man and ROLL. Single document addressing all aspects. * presented as 6lo: a poll from the router to maintain the multicast group, prevents the devices to go to sleep. * in IoT networks, we prefer to have the devices sleep on their own schedule and talk to the routers when they need. * RFC8505 already enables devices to register their unicast address, let's extend this behavior to anycast and multicast addresses. * most RPL networks operated in non-storing mode, but only storing mode was specified to allow multicast. * this work introduces multicast in non-storing mode of RPL. In RFC9010, we already know to build a tunnel to a non-RPL node. Egress will do replication. * this will be MOP 5. * this document awaited by Wi-Sun alliance, try to move fast. * A new node uptime option has been added to discover a router reboot. Otherwise, node will not receive packets from router. * Node needs to know that it should send a refresh to the router (after reboot). * Fixed IANA section language. * Router, when it reboots, should send an asynchronous RA. * Uptime option should be defined at 6man, because this is a new option in RA messages. Erik Kline was more inclined to make it a separate doc. * Erik has a task to discuss it with the other ADs. * We can live without the Uptime RA otion because we have the NA. But would still be good to have both. * If this option goes to a separate doc in 6man, this one would have to wait for that one, or that one could update this one. * Implementers of this may not realise there is an RA option and make do with the NA only, unless we add a reference to the RA option, but extra delay? * Going to 6man will make this option more useful to the community. * Pascal: does this make sense? * Alvaro: Yes it makes sense for me. * Alvaro: What is the status of this at 6lo? * Dominique: we agreed with 6lo chairs that we synchronize the WGLC, 6lo remains the home for the document. * Alvaro: Perfect, what about relationship with PIM? * Pascal: Tim responded that this work does replication at the root, not full-blown multicast. * Alvaro: PIM does other things beside the PIM protocol, like MLD. PIN WG working on moving MLD to be an Internet Standard. * Alvaro: would be nice for them to consider, if there's other work needed, if the signalling doesn't came through MLD. * Alvaro: will run this by PIM anyway. * Pascal: mostly interested if there's something we would need to add into this spec. Anything MLD would need from the host so that the router can proxy MLD from the device. * Alvaro: see if other work by PIM could be related to this. * Pascal: if someone from PIM could contribute to the LC, would be great. * Adnan (question in the chat) "Can we use ROVR for all type of address registrations? Second I did not get about the TID future." * Pascal: TID is normally a seq counter. Cannot be used for multicast because newer does not obsolete a previous one. You want all destinations, until expiration. * Pascal: regarding ROVR: the ROVR is not a proof of ownership. Will add text to explain why ROVR is not used, same as TID. * Adnan: do you mean removing TID from the spec? * Pascal: no, just saying it shall not be used for multicast. * Ines: raise hand if willing to review this drat? * Pascal: the draft is pretty small! * Ines: 4 hands raised. [14:30] Meeting adjourns