Minutes IETF110: roll
minutes-110-roll-01

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