Minutes interim-2019-roll-02: Mon 13:00
minutes-interim-2019-roll-02-201910141300-00

ROLL Interim Meeting - 14 Oct 2019
Hosted by ROLL WG

------------------------------------------------------------------------------------------------------------------------

Webex Details:

Monday, Oct 14, 2019 8:45 am | 2 hours 15 minutes | (UTC-05:00) Eastern Time
(US & Canada) Meeting number: 319 527 168 Password: pxT5tCu6
https://ietf.webex.com/ietf/j.php?MTID=mbf22e8e09dfa7a79eccc8646e17153ec

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 319 527 168

--------------------------------------------------------------------------------------------------------------------

Material: https://github.com/roll-wg/ROLL-Interim-Meeting/tree/master/20191014

----------------------------------------------------------------------------------------------

Participants:
    Michael Richardson
    Ines Robles
    Pascal Thubert
    Rahul Jadhav
    Dominique Barthel
    Rabi Sahoo

----------------------------------------------------------------------------------------------------------------

Agenda:

0) Agenda Bashing
1) Note Well https://www.ietf.org/about/note-well/
2) Discuss about: draft-ietf-roll-mopex-cap-00 Mode of Operation extension and
Capabilities

- Configuration Option Structure
- Cap unaware 6LR
- Capabilities Option structure and semantics

4) AOB

-------------------------------------------------------------------------

Slide-nro 5: Configuration Option Freshness:

How to elide?
-Use counter in Reserved low-4b
-Lollipop counter
--Using just 4b might be an issue?
for restarting it is important to be lolillop?
if the root reboot,  after reboot came with updated information, related with
the counter should be saved by the root. It could have the same behaviour of
similar counters.?

Is 4 bits enough?
Do we need to make this a lollipop counter?  It would need to be saved to NVRAM
(on all nodes) if it is not a lollipop, and it is the root node (DODAG) that we
worry about.

There is no way for a node to know that the root is rebooted. The path sequence
indicatest if the root rebooted

Utility outside conf option: Yes - it is a general counter.
Eliding static fields: e.g. PIO, is same format as ND.
whether PIO carried or not in DIO?

Pascal: Make it 1 byte

We need to think about for lollipop counters, when do have to store it in flash
so that they are not re-used again?   The observation draft says this.

Michael: one byte seque number/conf number and include clarification for loolip
counters, new document: -- Ask Alvaro as new document or joined document with
another one

SET (Static info Eliding counTer)  --- want to count it "SEAL"
Special Elided Attribute Lollipop = SEAL.

-Which doc should this go in?

What should this counter be called?
-SET (Static info Eliding counTer)
-Wanted to call it SEAL but could not think of an appropriate full-form

Slide nro 6: SET Counter Applicability

Elide what?
-Configuration Option
- Future { Cap Option, MOPex }

- What else?
--- Prefix Information Option and other options which rarely change

Pascal: we need to be exlplict which options beforehand.

Rahul: There is no way of saying if the information have retrieved all the
infor or not.

It is not a problem if different nodes elide different options
---- Since a query will still reveal the complete set of info regardless of
what is elided Only the root is allowed to change the counter

Slide nro 7: Capablity Option Syntax

Current draft considers CAPs as sequence of bits, but we are moving towards TLV
format

CAP bits
-Join as router/leaf if cap not understood
--Copy to children :

Michale: Survey of all nodesto find out which supports one

Rabi: Capability of the node not of all network

Rahul: If

----- Why do we need such flag? Individual cap spec should define whether the
node should copy or not.

CAP Info (optional), provides ext info for the CAP

Slide 8:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = TODO | CAP TLVs..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CAPType     |J|C|I|. . . . .| CAPInfo(Opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
J = Join only as leaf if CAP not understood
C = Copy cap to children
I = Cap Info present

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CAPLen      | Cap Info(format decided by individual cap spec)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Michael: Look at current TLV formats. CapType should be bigger.
Rahul: It is better not include the leng if the cap option is not going to be
included

Push bits to the left and make them part of the type. To start we can say we
have data or not, if yes, one byte data.

Slide nro 9 : CAP unaware nodes

- CAP unaware node would strip-off the CAP option

 -Thus a mandatory CAP may be ignored

-How to handle it?
---Should we let CAP be used with only newer MOPs?
Michael: Yes,

Slide nro 10: Other points

Where to carry capabilities?
- Last time we discussed using new messages!

- Shall we allow the node to proactively update the capability set?
- If caps are used for parent selection, then it will result in additional
messaging post parent selection.