ROLL Interim Meeting - 22 May 2024 - 2pm UTC

Chairs: Dominique, Aris, Ines
This meeting aligns with the Note Well, please read it carefully
https://www.ietf.org/about/note-well/
This meeting will be recorded
- Material:
  https://datatracker.ietf.org/meeting/interim-2024-roll-03/session/roll

Agenda:

Time (UTC) - Duration - Draft/Topic - Presenter
14:00 - 14:05 (5 min) - WG Introduction - Chairs
14:05 - 14:30 (25 min) - Status: draft-ietf-roll-rnfd-03 -
Chairs/Authors
14:30 - 14:40 (10 min) - Status: draft-ietf-roll-enrollment-priority-11
-Chairs/Authors
14:40 - 14:48 (8 min) - Status: draft-ietf-roll-mopex-07 -
Chairs/Authors
14:48 - 14:58 (10 min) - Status: draft-ietf-roll-nsa-extension-12
-Chairs/Authors
14:58 - 15:00 (2 min) - Open Floor - Everyone

[14:03] NoteWell, notetaking, Aris new co-chair

[14:05]

Importance of LBR
- But, they do crash
So what happens when they do crash?
- All incoming links need to be detected as dead, so it takes
  time, esp. when it is low traffic case
- Multiple parent changes, inconsistent touting, trickle timer
  resets
What is the proposal
- Explicit coordination to monitor LBR
- Do not proble all links
- Selective checking of crash
How does it work?
- Sentinel node
  - Neighbors to DODAG root that monitor root status (a subset
    of all neighbors)
- Acceptor node
  - Propagate observations
Basic ideas
- Sentinels detect crashed
- Exchange info via DIO + DIS
- Consensus of dead-ness of root based on number of sentinels
  agreeing
Previous reviews in v02
Some of the bigger changes
- Provide alternative solutions and interaction with this draft
- Handling false positives
- Changing the length of CFRCs
- Thresholds?
Next steps?
- Address the comments from Carles
Chairs: We can progress with WGLC
- 2 weeks
- Michael Richardson: shepherd
  - Has already done a part, will revise it if necessary
    ### draft-ietf-roll-enrollment-priority-11 {#draft-ietf-roll-enrollment-priority-11}
    
    [14:21]
Security issues addressed
Michael: WGLC ?
Chairs: OK for WGLC

[14:22]

WIP
Reusing the bits a bit unclear on how to operate
- Reserve the old MOP values in the new MOPEX field
- To be used as new flavor of old mode (some options made
  mandatory, etc.)
As Dominique understood it, Pascal is suggesting to make better use
of bits
- if MOP contains 0..6, use existence of MOPEX and value of MOPEX
  field as extra information bit
- for example, the MOPEX field could contain version number of old
  mode
not well understood, what if a node implementation does not know the
new option?
How to manage the transition
How to / if to use the old values
TODO: Dominique will ask Pascal to clarify his proposals
Chairs: Wait for answer from Pascal

[14:33]

[14:36]