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