ROLL IETF Interim Meeting 20200525 Jabber room: roll@jabber.ietf.org -- information for setting https://www.ietf.org/how/meetings/jabber/ https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agenda-interim-2020-roll-02-roll-01 Slides: https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/slides-interim-2020-roll-02-sessa-completeset-roll-interim-20200525 NOTES AND AGENDA, look down +--------------------------------+ | PARTICIPANTS - BLUESHEET - | +--------------------------------+ Webex: 10 Jabber: people NAME --- AFFILIATION Ines Robles -- Aalto University Michael Richardson, Sandelman Software Works Dominique Barthel, Orange Labs Rabi Narayan sahoo, Juniper Networks Georgios Z. Papadopoulos, IMT Atlantique Rahul Jadhav, Huawei Li Zhao, Carsten Bormann, TZI Dimitrios Sourailidis , IMT Atlantique Pascal Thubert, Cisco AGENDA: https://datatracker.ietf.org/meeting/interim-2020-roll-02/materials/agenda-interim-2020-roll-02-roll-01.txt Time in UTC 11:00 - 11:10 [10 min] WG Status --IETF 108: Meeting Format (when we meet? how much time, slots?) -- Ines/Dominique When should we meet? During IETF108? How many slots? After IETF108? * Dominique: rather during IETF108 week. More focussed. * MCR: favors work at interim meeting. Fears 8 tracks at IETF108 will be counter-productive. Not opposed to a (short) meeting during IETF 108 week, though. * Georgios: either option is fine. * Rahul: interim meetings work great. * Dominique: if not during IETF108 week, rather not after, because early August is bad time in year for work meetings * Pascal: like the work done at the interim. Just do the same as did for IETF107, i.e. meeting away from the IETF week. * Ines: to be confirmed on the mailing list. 11:10 - 11:30 [20 min] New Option and Backward compatibility -- Rahul/Everyone Two proposals for option flags. * MCR: would RPLv2 implicitely set the x flag? * Rahul: no. RPLv2 would simply make it mandatory to understand the new flags. * Rabi: RPLv1 nodes behavior? * Rahul: don't understand the new options, will skip them. * Rabi: in RPLv2, could have S fag and ?? bit. Instead of extra one byte, use X to mean mandatory option. * Rahul: seems identical to my proposal. * Carsten: optional option might be confusing. In Coap, used the terms Critical/Elective. Also Safe-to-Forward flag. More flags are CoAP-specific. * Rahul: RPL-specific would be "Join as leave". * Carsten: when x flag present, other flags could be explicit. When x unset, implicit behavior. * Dominique: clarifying that when x flag not present, behavior known from Option Type. * Rahul: indeed. * MCR: witnessing that proposal 1 is not popular. Also, consensus that this spec should appear in MOPEX draft. 11:30 - 11:50 [20 min] Compression for control messages? Applicable for nsa-extension --- Everyone * Ines: Related work presented * Georgios: last time, we said we need compression for all control message. * Georgios: we (Georgios and Aris) are willing to contribute to such compression mechanism. * Rahul: how much of compression can GHC provide to this NSA option? would like to see some numbers. * MCR: GHC provided 50% compression. Did the study long time ago. Could run it again on a library of sample packets. * Rahul: 50% may not be sufficient. Have sample packet sets. * Georgios: we implemented 6LoRH, dont remember exact compression figures. Took 6LoRH out after discussing it at Singapore. * MCR: also need to negotiate compression capability. * MCR: also, we are creating lots of new options. Good if people can rely on compression and worry less about optimizing the uncompressed options. * Dominique: it seems we will need compression for many RPL options, existing or future, and we gamble that we will be able to design efficient compression of a wide range of RPL options * Dominique: therefore, we don't need any hook in NSA to accomodate compression. * Dominique: anybody opposed to the conclusion? none heard. 11:50 [20 min] RPL Observation topics -- Rahul/Everyone Rahul goes through list of points, status and next steps. * point 10: Path Control bits is not implemented by any open source implementation * point 13: persistent storage and RPL. * Pascal: short linear part in lollipop, eliminates need for persistent storage. * Pascal: DIOs dont advance quickly. Could have DIO increment quickly in linear part, to ease reboot detection. * Pascal: another option would be 4-byte random number on boot, inserted in DIO. * Pascal: when ready for 6550-bis, will gather all new drafts and RPL observation fixes. * Rahul: in eliding draft, AOO option has specification that while in linear part of lollipop, keep sending the full options. Very elegant way of solving the problem of reboot in the linear part. Would love to see same type of solution for existing observations. * Pascal: just keep list of things to be solved in RPL v2, your draft very important for that. 12:06 [20 min] draft-thubert-roll-eliding-dio-information -- Pascal Draft unchanged for a while for lack of time to work on it and garner interest. The idea is synching the database of configuration. Repeating is an expensive proposition. One single sequence counter. Limited window for comparing integer numbers, will force transmission without compression when reaching end of window. Changes needed in DIO, DAO, DIS. Also introduced new AO Option, which carries the RCCS for the protection option this option is about. Specifies the 5 options that are protected by the RCSS. DIS has both flags of options sought and RCSS the node was last synchronized to. Not sure both are needed. Maybe only need one of the two. * Rahul: how will RPLv1 nodes behave in the face of RCSS? * Pascal: this will only appear in MOPs above 7. Therefore, only RPLv2 nodes will interpret this. RPLv1 nodes will join as leaves. * Rabi: why not multiple RCSS counters? * Pascal: design point for discussion. looks like overkill, uses resources. * Rabi: so, if any option changed, we should change the global RCSS option of the DIO? For each new option introduced, we have to send the RCSS counter, right? * Pascal: sharing an RCSS counter is fine if protected options rarely change. If one option changes much more frequently than others, it should have its own counter. * Pascal: all options to be sent when RCSS crosses comparison window (proposed to be 16). * Dominique: slight difference between querying by option flag or by RCSS: if a node queries by flag, and the parent breaks the response in multiple messages, the node knows what it does not know (the missing parts of the response). With RCSS, it does not know that the parent is to send more. 12:35 - 12:50 [20 min] RPL Ping -- Rahul/Everyone K flag in DAO to request a RootAck. Pascal: risk of getting a lot of RootAck, if copies of DAO percolate to the root. Rahul: path sequence. Only one RootAck is sent for each version of path sequence. Pascal: ok Rahul: behavior for RUL. RootAck, in asynch fashion, is way to probe node for capabilities. Pascal: last time this was discussed, thought this would be a new message. RootCapQuery and CapResponse. Rabi: agrees this could be kept a separate message. Rahul: do we want a different message? Pascal: yes. 12:50 -13:00 [10 min] Open Floor -- Everyone - do we need another interim before IETF108? About when? - Rahul, Pascal, Dominique would like another interim in June. - Ines will send out a Doodle to find a date/time.