IETF110 online meeting - ROLL session
Thursday, 11th March 2021 - 14:30-15:30 UTC (Thursday Session II)
Material: https://datatracker.ietf.org/meeting/110/session/roll

Bluesheet/Attendees:
NOT NEEDED, attendance is recorded in Meetecho
Agenda (times in UTC)
[14:30-14:38] WG Status (Ines/Dominique, 8 mn -> 10 mn)
[14:38-14:53] draft-ietf-roll-dao-projection (Pascal, 15 mn -> 20 mn)
- [14:53-15:13] RFC6550bis status (Michael, 20 mn)
[15:13-15:21] draft-ietf-roll-enrollment-priority (Michael, 8 mn -> 10 mn)
[15:21-15:29] draft-ietf-roll-mopex (Rahul, 8mn -> 10 mn)
[15:29-15:30] Open Floor (as time permits)
[14:30] WG Status (Ines/Dominique)
note well, scribes
since IETF109, 4 drafts now in RFC Ed Queue, 1 submitted to IESG
milestones will need updating
tickets in tracker and mostly on GitHub
[14:33] draft-ietf-roll-dao-projection (Pascal)
since last IETF, simplified mechanism. Tries to make everything look similar.
now, the root of projected DAO is the track ingress
skeleton (main DODAG or Track) is non-storing, can be made loose with storing mode segments inserted
can be used by WiSUN
free bit in HbH header used to signal that packet is on project route
new projected RPI 6LoRH
simplified rules for P-DAO construction
P-DAO is DAO that signals full track, using VIO instead of TIO
UseOfRPLInfo applies unchanged
local root will copy SR-VIO in 6LoRH unchanged
6 profiles
Profile 1 (the original):
hybrid storing / non-storing mode.
Use up the amount of store available in the nodes, but no more.
Bridge the “gaps” with loose hops.
Profile 2 (expressing the segments as non-storing mode)
implies re-encapsulation
Profiles 3-6 do shortcuts
needs feedback from the group on the topics listed
Iliar: could a P-DAO be sent to all nodes, not just the egress
Pascal: can discuss the use cases on the ML
[15:12] draft-ietf-roll-enrollment-priority (Michael)
decided at Jan interim to merge two drafts, this version is the result
exp/mantissa representation of DODAG size
discussion on ML on what is being measured
number of routes, not number of nodes
Pascal: in storing mode, root will only know number of final (currentl active) destinations
Pascal: a same node may have multiple addresses
experiment needed
whole draft to be made experimental?
Pascal: WiSUN needs this information. Luckily, they have one address per node.
MCR: would love to hear feedback from them
[15:22] draft-ietf-roll-capabilities-07 and draft-ietf-roll-mopex (Rahul)
capabilities draft updated after the previous meeting

use cases descvribed in doc, e.g., root want to known what a node is acapable of

one cap is routing resource available in node

new capability options, with TLVs in it

needs feedback from WG on the current features.

MOP extension

draft describes how to handle all MOP values/cominations

how about backward compatibility: by extending RPL Control Options with new flags

flags describe node behaviour if option unknown

took inspiration from CoAP

Pascal: how about a bit combination to specify “dont join at all”, e.g. if option says “must compress” and node does not know.

Lets prioritize MOPex over capabilities, since it is a precursor.

Needed reviews in order to proceed with the WGLC.

[15:33] AOB
RFC6550bis is in github in order to start the work on this topic

[15:33] Adjourn
Summary of action points
Feedback required for draft presented today