Minutes interim-2019-roll-01: Mon 13:00

Meeting Minutes Routing Over Low power and Lossy networks (roll) WG
Title Minutes interim-2019-roll-01: Mon 13:00
State Active
Other versions plain text
Last updated 2019-10-14

Meeting Minutes

   ROLL Interim Meeting - 23 Sept 2019
Hosted by ROLL WG

Monday, Sep 23, 2019 9:00 am | 2 hours | (UTC-05:00) Eastern Time (US &
Canada) Meeting number: 649 726 882 Password: 44TgnsSv

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 649 726 882

Slides/Materials: https://github.com/roll-wg/ROLL-Interim-Meeting

    1) Michael Richardson
    2) peter van der Stok
    3) Alvaro Retana
    4) Georgios Papadopoulos
    5) Pascal Thubert
    6) Ines Robles
    7) Rahul Jadhav (RJ)
    8) Dominique Barthel

Draft Agenda:

0) Agenda Bashing
1) Note Well    https://www.ietf.org/about/note-well/
2) roll call

3) Disscuss about: draft-ietf-roll-mopex-cap-00 Mode of Operation extension and

MOPex syntax

Capabilities (CAP)
CAP handshake
handling CAP-unaware RPL nodes
CAP Use-cases
Eliding CAP/MOPex/CfgOption

4) NPDAO modifications.
5) AOB


MOPex syntax [Rahul]

Final MOP calculation
[https://mailarchive.ietf.org/arch/msg/roll/uRMEgEZPPiJw0Qujrd5_9NyvKIs] Keep
base MOP as is If MOP=7, then use MOPex value as is If MOP=7 and MOPex < 7
... we allow it? Simple to implement and easy to understand

Ok, with the change keep, things simple
iF MOP<7 and MOPex > 0,should be ignored MOPex.

Keep base MOP as it is (MOP=7 then use MOPex value as it is)
suggestion that with MOP=7, MOPex is a new field with 0 < MOPex < MaxInt
Recommendation MOPex > 7

Pascal: MOPex, it is a new field,

MOPex, to keep:

Using Config Option
8 bits extn possible (8b resv field available)
Eliding MOPex with Config Option possible
MOP is instance config and not DODAG config. Thus not logical place.

Opt2: New RPL Control Option --
Allows extending beyond 8 bits
Eliding criteria can be same a Config Option

Pascal: Option 2 is better

Problem Eliding Options: eliding may result in inconsistent config --> there
is no way for routes to know that the configuration has been disseminated

Pascal: maybe a counter could help, but it is more overhead.
Pascal agrees that this problem is real.
DIO could be used to clarify - 8 bits reserved, sequence counter there,

6.3.1.  Format of the DIO Base Object

        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
       | RPLInstanceID |Version Number |             Rank              |
       |G|0| MOP | Prf |     DTSN      |     Flags     |   Reserved    | <--
       4 lower bits
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |     
                                                                | +            
                                                         + |                   
                                                  | +                          
        DODAGID                            + |                                 
                                    | +                                        
                             + |                                               

MCR: why not use the Version Number?  If we change the configuration, wouldn't
we have to pull the whole DODAG anyway?

Pascal: Semantically is different,
Maybe there are some configuration things that can be applied without
rebuilding the DODAG?

We have agreed to take 4 bits from the DIO Reserved field (lower 4 bits) as
the ConfigurationVersion.  This is incremented (rolling back to 0 or 1?)
whenever the configuration options that could be elided in the configuration.
--> This issue to the ML


Rahul: Capabilities:

Carrying CAP in DIO/DAO
CAP-unaware 6LR  (r2, n1)
Eliding CAP

Pascal suggests that the capabilities flow is not the same as the DIO, and that
we should have a "DCO" (DODAG Capability Object) that has some kind of
"reliable" multicast from parents to children. Maybe Node Capability Object
(NCO) What we have in DUAL. Diffusion Algorithm ((JJ Garcia Luna Aceves) -

mcr: should the root unicast every one of the nodes?

Pascal: set of unicast, or set of multicast,

DUAL never will work in RPL, having the parent wait for all child answers.

1) root wants to pull info from all the nodes.
2) node wants to get info from the root about its capability.
3) root needs to decide on basis of the answers.

1) node pulling from parent
2) node pulling from root
3) node pulling from all children
4) node pulling from all descendants
(and "node" can be root)

Pascal: Configuration option could be in the Cap Option

Defining CAP:
Shall we use same bits for both direction?
Certain CAPs are only indicated from nodes to root
Certain CAPs may be bidirectional

Pascal: two directions are encoded differently.
We need to be able to encode consequences of not understanding the capability.
We need 2 or 3 bits to encode each capability.
 a) can we join as a router or leaf?
 b) should you propogate to children? (copy capability)
 c) {third bit is whether capability is present or not}

four(?) possibilities for CONTROL:
0) capability not on
1) join as leaf if not understood
2) can join as router, if not understood (do not copy to children)
3A) join as router, copy to children, even if not understood
3B) do not join if not understood.
Maybe (2) and (3) are the same, but different envelopes.

Query on capabilities are propogated based upon the envelope (above)

CAP use-case (turnon-8138):

Root signals enable-8138 using ‘T’ flag in DIO Config Option
But before doing that, Root needs to know if all the devices are 8138 capable
Thus the need for nodes to advertise capability
Only need to be sent in DAO

mcr: One query root ask, 8138 capable?
Second query, I am enabling 8138. The Query is a second capability.
When you join, you know if they are capable or not.
turnon8138: it is conf option, not a capability option, it is a command,

11:00 meeting closed.

Pascal’s list of requirements
Express support for exposing siblings Signal supported OFs Express support for
storing P-DAO Express route capacity Approx num of routes that can be installed
Current utilization Expected target utilization Overload bit that means do not
use me for now Same for non-storing P-DAO Avg num of hops per route e.g., 5.
Plus: Max num of hops in route

Eliding CAP/MOPex/CfgOption