Minutes interim-2020-roll-04: Fri 13:00
minutes-interim-2020-roll-04-202006261300-00

ROLL IETF Interim Meeting 20200626

Jabber room:  roll@jabber.ietf.org  -- information for setting
https://www.ietf.org/how/meetings/jabber/

https://datatracker.ietf.org/meeting/interim-2020-roll-04/materials/
https://ietf.webex.com/ietf/j.php?MTID=mf9250059100987f251de5701729cc8e2

Slides: https://datatracker.ietf.org/meeting/interim-2020-roll-04/session/roll

+--------------------------------+
|   PARTICIPANTS - BLUESHEET -   |
+--------------------------------+
Ines Robles - (Logged as ROLL WG)
Dominique Barthel
Rahul Jadhav
Remous-Aris Koutsiamanis - IMT Atlantique, France
Michael Richardson
Pascal Thubert (logged as LPWAN WG)
Alvaro Retana - Futurewei Technologies
Georgios Papadopoulos - IMT Atlantique (psilos as alias)
Dimitrios Sourailidis - IMT Atlantique

Webex:
Jabber:  people

AGENDA:

https://datatracker.ietf.org/doc/agenda-interim-2020-roll-04-roll-01/

+----------------------------------------------------------------------------------+
|                               ROLL Interim  Meeting                          
   |
+----------------------------------------------------------------------------------+
|                                      AGENDA                                  
   | |                                                                         
        | |                               Friday, June 26, 2020                
             | |                                                               
                  | |    Etherpad:
https://etherpad.ietf.org:9009/p/notes-ietf-roll-interim-20200626   | |        
     Github where the link to the recording will be posted:              | |   
   https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20200626       |
|                                                                              
   | | Material:
https://datatracker.ietf.org/meeting/interim-2020-roll-04/session/roll |
+------------------+---------------------------------------------+-----------------+
|    Time (UTC)    |                    Topic                    |    Presenter
   |
+------------------+---------------------------------------------+-----------------+
|  13:00 - 13:30   |                  WG Status                  | 
Ines/Dominique | |     [30 min]     |                                          
  |                 | |                  |         -  status of unaware-leaves 
       |                 | |                  |   -  status of capabilities
draft  (Rahul)  |                 | |                  |        -  status of
mopex draft    (Rahul)  |                 | |                  |          - 
status of useofrplinfo          |                 |
+------------------+---------------------------------------------+-----------------+
|  13:30 - 13:50   |       status of DIS Modification draft      |     Georgios
   | |     [20 min]     |                                             |        
        |
+------------------+---------------------------------------------+-----------------+
|  13:50 - 14:10   |  draft-thubert-roll-eliding-dio-information |      Pascal 
   | |      [20 min]    |                                             |        
        |
+------------------+---------------------------------------------+-----------------+
|  14:10 - 15:00   |                  Open Floor                 |     Everyone
   | |      [50 min]    |                                             |        
        |
+------------------+---------------------------------------------+-----------------+

1PM UTC meeting starts

1:05 going through agenda and milestones
1:07 Going through the status of WG drafts submitted to IESG
* RPL AODV: coments from Alvaro, new tickets. New authors to address problems
raised * Unaware: pruned the tree of possibilities. Made consistent with NP_DAO
draft. Also some cleanup.
  Provide comments in the next few days for a chance to get them in before
  Alvaro processes the doc.
* MOPEX: moved Extended Control Option bit to msb.
  Discussion on 1 bit or 2 bits to distinguish Extended vs legacy options. Any
  comment, please chime in? Extended Options work as a replacement for legacy
  options (albeit costing 1 more byte), but not vice-versa. Probably reserve
  192 Extended options, and 64 legacy options.
* CAPabilities:
  Pascal: currently, list has all caps or none. A way to send a few ones,
  specifically? Pascal: related to the abbreviated options. Will come back to
  this later in the meeting. List of capabilities in query. If absent,
  responder will send a list of all capabilities. Pascal: needs to beexplained
  that node asking for Cpa1 and Cap3, only receiving Cap1, can use a timeout
  and request Cap3 again. Pascal: case of Root querying all nodes. Would like
  something "tell me if you don't support Cap5". No strong garantee since the
  query message might get lost anyway. Rahul: should this be done through DAO
  or CAPQ? Pascal: Trickle-style or diffusion-style. CAPs need more reliablity
  than routing info. Pascal: another example is Root querying for available
  memory in nodes. MCR: assuming Root already has a complete list of nodes? so
  that it knows it has got a complete answer. If not, how does it know when it
  is done? Pascal: could go unicast for the nodes it knows and hasn't received
  an answer from.
* UseOfRPLInfo:
  Alvaro: change log is several hundred lines, ten revisions. Unsure what to do
  with IESG. MCR: most changes relate to unaware-leaves. You could tie this
  draft to the review of that one. Alvaro: will advertise list of real changes
  with IESG, and see if another review is needed Pascal: thorough review done
  at the WG. Alvaro: IoT directorate did not review this. Could add an IOTDir
  review to executive summary of changes, to expedite it through IESG. Ines:
  will do.
* Ines goes quickly through other drafts.
* RootAck draft: Rahul will update based on advances on unaware-leaves.

1:49 DIS modifications draft (Georgios)
  * need feedbak on use cases. will show results of DIS modifications.
  * goes briefly through the 4 current use cases.
  * any more use cases, please let us know!
  * goes through proposed modifications to DIS.
  * shows examples of network topologies and benefit.
  * shows simulation results (Cooja/Contiki NG).
  * Debate:
  * Pascal: MC option is tricky to use. You don't know what value to put in the
  request. * Pascal: Electrical meter reboot use case. Suggest to use Trickle
  to cancel sending a DIS. * Dominique:  we use the delay spread option for
  unicast answer. * Rahul: Imin 12 (4 seconds). DIS sent within 4 seconds. If
  high network density, root keeps resetting Trickle period. * Pascal:
  rephrasing the issue: * Rahul: was discussed on the mailing list. * Pascal:
  already discussed difference between resetting the period of the Trickle
  timer to Imin and resetting the timer at 0. * Rahul: We wont be restarting
  the I if the timer is already in Imin. Then, the shutdown issue is still
  there. * Pascal:  in the Electrical Meter boot use case, meters should
  realize that the DIS sent by neighbors is a duplicate of theirs. * Questions:
  use-cse draft stays separate or becomes merged into solution draft? Merged. *
  As Appendix or into main part? Pascal: advocates for main part. * Currently
  two docs with modifications to DIS. What merge/split? To be discussed offline

2:46 draft-thubert-roll-eliding-dio-information (Pascal)
  * RPLv1 was designed for fixed configurations.
  * RPLv2 targeted to imporve network operation, add features while nextwork is
  running. Without bringing it down and restart * great review of draft by
  Rahul. * elaborates on comments * explains benefit of AOO. More code
  complexity (remember RCSS per option) but saves on DIO size. * alternative
  would be to have all options constitute THE context with one RCSS.
  More/larger DIOs. * Alternative would be AOO is a capability, must be known
  from parent, so that they know what to send. * Rahul: would prefer option 3
  (slide 3), i.e. dropping the AOO completely. Maintaining RCCS per option is
  quite a complexity. * Rahul: can still introduce it later if really needed.
  Would recommend to go simple right now. * Pascal: agrees that AOO as a CAP is
  going beyond control. Recommend to either do AO or not do AOO. * Pascal:
  historically in RPL, accepted a little more complexit in order to save bytes.
  * Pascal: assume that Rahul's comments only apply to DIO. But we also need to
  consider DAOs. For DAOs, I believe we still want the compression provided by
  the RCSS. * Rahul: get it. Still does not mean we want AOO. * Pascal: do we
  want DIO compression and/or DAO compression? * Rahul: compression is good,
  but AOO state is complex (must be persistent, etc.) * Pascal: if Option and
  RCSS as stored together, they are either in persistent storage or they a
  renot. If they are not, you loose everything and have to restard from
  scratch. * Pascal: looks DIO compression is worth the complexity. * MCR:
  update rate is the issue, getting them to flash. Updating a flash block *
  Pascal: the 5 options and their associated RCSS should go into the same flash
  block. * Pascal: intuition different from Rahul's. But not strongly
  convinced. * Rahul: one update per week is too frequent. * Rahul: as an
  implementer, I want an option to use a single RCSS for the set of 5 options.
  * Pascal: The complexity in code is mainteining 5 values of the controls vs
  just one * Rahul: AOO should not be mandatory to use. * Pascal: where does
  the complexity come from? * Rahul: in RAM, need to store RCSS for each
  option. * Pascal: 10 bytes instead of 2. For the whole RPL network, not per
  peer. * Pascal: seeking advice, just an intuition. * Pascal: also, adoption
  by the WG?

3:16 pm
   Next meeting in September, will send a Doodle out.
   Meeting is closed.