# ROLL session at IETF 113 meeting   {#roll-session-at-ietf-113-meeting}

Meeting Material:

https://datatracker.ietf.org/meeting/113/session/roll

## Agenda (UTC):   {#agenda-utc}

* 12:00 - 12:20 (20 mn) Intro, WG Status (Ines/Dominique)

* 12:20 - 12:35 (15 mn) draft-ietf-roll-dao-projection (Pascal)

* 12:35 - 12:50 (15 mn) draft-ietf-roll-enrollment-priority (Michael)

* 12:50 - 12:55 (5 min) draft-thubert-6lo-multicast-registration
  (Pascal)

* 12:55 - 13:00 (5 mn) Open Floor (Everyone)

# Minutes (UTC):   {#minutes-utc}

## \[12:00\] Intro, WG Status   {#1200-intro-wg-status}

* Note Well, Scribes, Agenda
  
  * no comment on agenda

* WG status
  
  * NSA extension: AD evaluation, revision needed
  * milestones: lagging by a year or 2, time to refresh
  * proposing new dates (in years)
  * Alvaro: my queue is deep, but you should progress as the WG can do,
    and I will manage to reduce queue depth
  * DAO Projection: Pascal: please start WGLC when you can, target
    publication request May 2022
  * Enrollment Priority: MCR: need to resolve what we need to do, doable
    today, even. Sep 2022
  * MOPEX: need several interim meetings to get to a final doc.
    Implementations? Fall 2022.
  * CAPEX: 2023
  * DIS: 2023
  * YANG Model (was driven by Peter).
    
    * MCR: I do not think we are going to finish it.
    * Alvaro: need to change the charter to remove the item
    * Alvaro: real question is how these networks are managed. Is it
      YANG or something else? IESG focussed on manageability.
    * MCR: we don't have on our charter a YANG model for RPL.
    * MCR: this is about MPL, no deployments, do not think I can write a
      management protocol for a protocol I have not implemented.
    * Pascal: MPL used for WiSUN, WiSUN not using YANG. Until we have a
      deployment that uses RPL and MPL and YANG, no resource to develop
      this YANG model.
    * Pascal: WiSUN uses CoAP-based management.
    * Pascal: we could keep this in our charter, but not working on it
      these days.
  
  * Source-Route Multicast: no progress. Pascal will see if it
    integrates with multicast registration and MOP 5.
  * ACTION \[chairs\] update milestones, fix Enrollment Priority title.
    Confirm on ML about YANG model.

* AODV-RPL Status
  
  * open issues from Ben's IESG review and Pascal' s review
  * Pascal: spent quite some time on this, 3 reviews. Slow progress from
    the authors.
  * Pascal believes it is unclear that this protocol works, as
    specified.
  * Pascal: I do not recommend to push the button for publication
    request on this.
  * Pascal: can do another review, but will not contribute.
  * Alvaro: this went through WGLC, IETF LC, IESG evaluation, etc. Ben's
    ABSTAIN can be read as "too much stuff missing, won't invest". Ben
    is stepping down, will not spend more cycles on it.
  * Alvaro: could technically push the button and get it through, but
    it's not the right thing to do. Right thing to do is return it to
    WG. Might sentence the document to death.
  * Alvaro: too much concern has been expressed, have to push back to
    the WG.
  * Chairs agree.

## \[12:26\] draft-ietf-roll-dao-projection (Pascal)   {#1226-draft-ietf-roll-dao-projection-pascal}

* intro: basic RPL is dsitributed distance-vector proactive. AODV-RPL is
  distributed reactive, this work is SDN-like controler-based routing
* slide 2 illustates notion of Track, Leg, Segment.
* RFC9008 specifies encapsulation that is taking place at Ingress of
  Track (destinations are external destinations).
* in RAW, for energy/bandwith reason, need to select a subset of all
  segments providing good enough reliability.
* got three thorough reviews.
* believes -24 fixes all GitHub issues. Multiple Targets left out, too
  complex. Allowed to have multiple target options, but only first one
  garanteed to be reached.
* Remous-Aris'es review still expected, should not block WGLC in the
  meantime.

## \[12:41\] draft-ietf-roll-enrollment-priority (Michael)   {#1241-draft-ietf-roll-enrollment-priority-michael}

* Konrad's observation on interaction between new extension and Trickle
  timer.
* Compromise to set the min priority at the root and not change it down
  the DODAG
* will have to change DTSN if want to change priority
* MCR was reluctant to that
* think can solve the issue with extra lollipop counter, will put in
  next revision
* not confident until put everything into implementation, no resource to
  do this soon.
* Pascal: was one of proponents of setting fixed priority as you
  propoagate down, demonstrated it could not work otherwise.
* Pascal: think lollipop is much needed, because might receive values of
  different ages from different parents, and you don't which is fresh.
* Pascal: it does not balance the DAG, but other proposals did not
  either.
* Pascal: the only way to balance is to look at the network from a
  centralized perspective.
* MCR: worried more about nodes enrolling into parts of the graph that
  do not having the capacity to support them. That is solved, right?
* Pascal: mapping priority into the beacon does. Now how do you do that?
* Pascal: many reasons for not wanting downward nodes to join. Because
  of traffic? reduce traffic; Because of storing mode resources? use
  non-storing; Because of non-storing mode resources? control the
  beacon.
* MCR: could manipulate own beacon to protect own neighbor cache, true.
* Pascal: and descendants of your children not your problem, only
  affects throughput.
* Pascal: keep the document simple. If neighborhodd cache problem,
  control the beacon. If throughput problem, much more global problem.
* MCR: if value not changed from the root, do we still need lollipo
  counter?
* Pascal: think yes, for the reason Konrad explainedd, might get
  different values from different parents.
* MCR: are 4 bits enough?
* Pascal: I hope so. RFC6550 section 7 has 8 bits, do we ned that?
* MCR: two choices: add another byte, or steal from other fields.
* Pascal: to keep it simple, have a byte.
* ACTION MCR: will propose lollipop in -05, similar to 6550 Section 7.
* Ines: implementation on-going? will ask on the list.
* MCR on chat: I will implement, but I have other higher priority bugs,
  so it might be some months before I can start.

## \[12:52\] draft-thubert-6lo-multicast-registration (Pascal)   {#1252-draft-thubert-6lo-multicast-registration-pascal}

* this work allows a node to register into a router and have the router
  advertize address, for anycast and multicast.
* For multicast, we already had that in RPL with MOP 3, but we don't
  have such a thing for non-storing mode.
* 6lo looked at extended 8505 (Extended Rgistration), no objection, now
  extend to RPL. Goal is to extend RFC9010 (RUL) and RFC6550 (RPL).
* WiSUN 1.1 needs this.
* This draft uses MOP 5
* Q&A
* Question to Alvaro and Erik Kline: how do we do this work between ROLL
  (RTG) and 6lo (INT)?
* Alvaro: ROLL chairs to talk to the 6lo chairs, and figure out way to
  work together. One document, or two documents dependant on one
  another.
* Pasacal: do you have preference for one or two documents?
* Alvaro: no preference.
* MCR: it wasn't clear in 6lo that this doc fit their charter. Was
  reason to have several documents.
* Alvaro: it's common to have documents that span several WGs. Leave it
  to you to decide. Will talk to Erik nonetheless.
* Dominique: sure, we'll do.
* Pascal: the big work is on the RPL side.
* ACTION: chairs engage with 6lo chairs.

## \[13:04\] Meeting adjourns   {#1304-meeting-adjourns}

## Online exchanges   {#online-exchanges}

Ines Robles  
Michael, about the red issue (change in min priority - topological
change) in your slide, the answer is no, right?  
13:00:15  
Adnan Rashid  
are not both protocols dependent to each other? I mean rpl and
6lowpan-ND.  
13:01:47  
Carsten Bormann  
6LoWPAN-ND is NOT dependent on RPL.  
13:02:22  
Adnan Rashid  
yes.  
13:02:37  
but rpl is?  
13:02:40  
Ines Robles  
yes.  
13:02:37  
but rpl is?  
13:02:40  
Carsten Bormann  
RPL may want hosts, and needs ND then.  
13:02:52  
Adnan Rashid  
ok