Minutes interim-2020-roll-02: Mon 11:00
minutes-interim-2020-roll-02-202005251100-00

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.