Minutes IETF101: roll
minutes-101-roll-00

ROLL meeting
Thursday 21 March; 9h30 - 12h00

Peter and Ines: Introduction (10 minutes)             .

Papadopoulos: object function             (15 Minutes)
draft: draft-ji-roll-traffic-aware-objective-function-00

Papadopoulos: RPL DAG Metric Container    (15 minutes)
draft: draft-koutsiamanis-roll-nsa-extension-01

Rahul: discussion of open problems          (30 minutes)
draft-rahul-roll-rpl-observations-00

Carsten (and Pascal) use of BIER in RPL uni- and multicast (45 minutes)
draft-ietf-roll-ccast-01
draft-thubert-roll-bier-01

Michael (and xxxx): Parent selection before or after enrollment (30 minutes)
draft-richardson-6tisch-roll-enrollment-priority-00

5 MINUTES open MIC to discuss continuation

Note takers
- Dominique Barthel, Georgios Papadopoulos
- more welcome!

Meeting notes

[9:30] Meeting starts
[9:30] Introduction (chairs)
    * Note Well, note takers, blue sheets, Note Well
    * updated the milestone list to more realistic target dates
    * Active internet drafts
    * notice IPR on two drafts, mail was sent out. Please react
    * Peter: this time, long ROLL meeting. Many topics to discuss. Want to get
    some feedback on the length of this meeting

[9:36] draft-ji-roll-traffic-aware-objective-function-00
    Aris: is presenting his draft on Load Balancing
    * new routing metric container proposed.
    * simulation results
    * the proposal is developed over Contiki OS (and Cooja simulator)
    * number of DIOs sent as a measure of network stability: this proposal does
    a bit better than state of the art (i.e., MRHOF, Child Count draft) * open
    questions: packets or bytes? time units? assumption of homogeneous
    forwarding cpapacity of nodes, should we send capacity as well in DIO? *
    how to relate energy consumption to packets/bytes sent? * * Shall this
    value be integrated with EB/IE, * Giorgios: this is layer 3 info, should
    not get into EB * Rahul: interesting work, done something similar * Aris:
    let compare notes * MCR: your diagram on slide 12, how do you ensure node 7
    attaches to 4 in order to allow 5 to accommodate 8? * Michael: there should
    be more experiments with more children per parent, to see the impact of
    overloaded children per device * Rahul: OF here only takes packet
    transmission rate into account. * Aris: would use other metric as well, and
    this one as a secondary metric. * Charlie Perkins: * Charlie: study
    stability

[9:49] RPL DAG Metric Container (MC) Node State and Attribute (NSA) object
type, extension (Aris)
    * New TLV proposed in NSA object, for packet replication and elimination
    * already presented at Singapore
    * aim is determinism for reliability
    * The employed mechanism is the so-called Packet Replication and
    Elimination (PRE)
   * key point is to select the alternate parent to send replica to
   * idea is to pick alternate parent that has common ancestor with best parent.
   * new TLV contains IPv6 addresses so that ancestors can be learnt
   * wireshark dissector was written
   * drawback is size of IPv6 addresses that are sent. Compressed out some of
   it. * The idea is to keep the default parent and alternative parent so that
   to have the parents as close as possible to allow overhearing * MCR: to
   compress IPv6 addresses, look at 6LoRH header, code available * Carsten:
   your draft has NSA in the title ;-) * Peter: how does your proposal co-exist
   with other parent selection draft? * Aris: this is just a Constraint, not a
   metric. Can work with OFs * Pascal: the OF at IETF are simple, but more
   metrics exposed. OF should be piece of logic. Your OF would be one with high
   level of intelligence. * Peter: would be nice if this draft reflects how it
   interacts with OFs * Ines: this is of interest to ROLL, also needed by
   6TiSCH * Pascal: 6TiSCH does not *need* this, but a solution that benefits
   from 6TiSCH would also benefit from this.

[10:01] draft-rahul-roll-rpl-observations-00 (Rahul)
    * just observations of issues, no solution here
    * Smart Meter networks, 60 hops, thousands of nodes
    * issues mostly related to storing mode
    * how to handle DTSN increment? want to also check how BIER does
        * issue is DAO not getting through to the Border Router. Need for some
        redundancy. Re-transmit at every DIO Trickle timer interval? * has seen
        10% of nodes not joined, for a long time. * on parent switch, should
        node increment DTSN
*  * (Dilemma 2) On parent switch, should node increase its DTSN?
        * DAO-ACK: could be a solution if were handled properly. Current RPL
        spec has multiple interpretations possible. * Contiki (new) implemented
        DAO-ACK hop-by-hop. RioT implements end-to-end. * RPL spec say
        aggregated target is possible, but how to handle failure? * problem
        will show on multiple hops, not simple one-hop network * third
        proposal: downside is aggregated ACKs is not possible.
    * handling node reboots: how is RPL state is maintained.
        * not acceptable to write to flash repeatedly (endurance issue).
        Incrementing DTSN 5 times a day is a problem, reportedly * Carsten:
        what level of ?? are you considering? * Rahul: numbers in the draft,
        please look at them and comment
    * handling resource unavailability
        * neighbor cache full, routing table full: how do you signal it?
        * impacted packet delivery rate in this experiment. Some ideas for
        workaround, but would like to hear about other's experience.
    * MCR: excellent work, should adopt it. Lots of useful points. Hadn't
    realized that the spec was ambiguous. * MCR: one document with solution:
    e.g. DTSN increment is clearly a bug in the spec. * MCR: another document
    to discuss issues we don't have a solution for. * Pascal: agrees to thank
    for the work, not so much for the rest that michael said. * Pascal: a bit
    of history: left a few things open when writing spec because did not know
    what to decide. Don't rush to immediate solution. * Pascal: RPL is not just
    for wireless. It's a routing protocol. Also used on wires. * Pascal:
    explains thinking about DAO-ACK. We need something to solve the end-to-end
    delivery. * Pascal: version rebuilds everything, DTSN " repaints" the
    DAODAG. Discrepancy is found when seeing traffic from unknown node. *
    Pascal: wanted capability to rebuild the network intelligently by having a
    timer that is long enough so that ...., never specified that. * MCR: seems
    Pascal agrees. Just clarified a lot of things. 6550 did not capture that
    clearly. Low hanging fruit document should only include non-controversial
    points. * MCR: a bunch of knowledge just exposed, glad it's captured on
    tape. Want to capture it in text quickly. * Rahul: will go to the mailing
    list to get consensus on what is non-controversial * Ines: a document for
    the problem statement and links to solutions * Pascal: problem statement
    does not need to be published * Peter: draft could expire. * Rahul:
    understand could maintain this draft as long as needed, and develop
    solutions in other documents? * Carsten: in the past in RoHC WG, have kept
    a standing doc for 5 years.

[10:31] draft-ietf-roll-ccast-01 (Carsten)
    * this is more than 5 years old.
    * thought it would be good to have multicast for non-storing mode.
    * result of a " constrained-cast"  reseach project.
    * in 2014, BIER appeared, revived interest.
    * Carsten shows tutorial slide. Efficient representation of lists of data.
    Bloom filters, dating back 1970's. * False positives create spurious
    transmissions, energy consumption. How bad is it? In dense network, gets
    worse. Still, can leave with some of it * False positives depend on number
    of bits allocating. Two many bits is also a problem. * Matt Gillmore
    (Itron):

[10:40] draft-thubert-roll-bier-01 (Pascal, Toerless Eckert)
    * has backup slides to explain how BIER works with RPL, look at them at the
    back of the presentation or ask me to present them * can be used in storing
    or non-storing, unicast or multicast * Carsten: *set* vs. *sequence* *
    Pascal: set out to write a doc showing how all 4 cases can be done. * with
    bitmap, amount of storage is related to number of children, which can be
    controlled. Could revive storing-mode. * BIER-TE specifies bits for each
    hop to follow. False positive create forwarding to wrong path *
    Toerless: don't we want rough characterization (overhead, resources) before
    writing the drafts? * Pascal: Bit-by-bit fits the BIER architecture. Bloom
    filter needs some adaptations. * Carsten: comparing different metrics: good
    way to compress bit fields. Number hosts (storing mode) of forwarding nodes
    (non-storing mode). * Pascal: 200 hosts, how many bits do I need? *
    Toerless: * Carsten: bit assignment can be managed with RPL, with ND. *
    Carsten: could look at more ways to compress bitmaps. Could get efficiency
    close to that of Bloom filters. * Carsten: I' m interested in non-storing
    mode * Pascal: could use * Carsten: non-storing case is slightly simpler,
    because the actual source is always the root. * Pascal: with Bloom, creates
    a problem. By contrast, bit by bit allows to send multicast from inside the
    network. This is a differentiating point * Pascal: work to be done at BIER:
    allocation of bit to address, * still work to be done to compress RPL
    control plane messages (DIO, DAO, ...) * Toerless: what 's the packet
    format? can we replace IPv6 header with BIER header? * Pascal: compressed
    form, but packet complies with the IPv6 architecture. Can always
    reconstruct the full IPv6 packet using the implicits. * Pascal goes through
    RPL tutorial slide. Bit allocation. Aggregating bits in DAO operation. *
    Giorgios: what do you do if too many nodes? * Pascal: Bier can do groups. *
    Pascal explains how to forward messages based on bitmaps. * can be made
    reliable with ACK, which are OR'ed together as they go back up. * Peter: is
    there interest in the working group for this work? Humm now: humms heard. *
    Peter: anybody opposed? Speak up now. * Carsten: IPR? * Peter: propose to
    start design team. * Carsten: send lawyers * Toerless: isn't it always the
    case? Can create a design team and see later if proposed options are
    covered with IPR. * Peter: suggest Carsten, Pascal, Toerless, Olaf, Greg,
    Ijsbrand (Cisco), Giorgios, Emmanuel. * Peter: Toerless to coordinate. *
    Peter: DT to create doc with alternatives, IPR info.

[11:16] draft-richardson-6tisch-roll-enrollment-priority-00 (Michael)
    * set of requirements coming from 6TiSCH to do in ROLL.
    * not specific to 6TiSCH, though.
    * Problem is network selection. Given a node that can hear many routers
    belonging to several networks, which one to select? * Would like to not
    have to try all routers, but rather know which network they belonging too
    without revealing too much. * We need to do DODAG selection, inside a
    network. * if different PANIDs, probably different keys. * Carsten: if
    secret handshake, none of the two parties disclose anything to a third
    party. * Michael: not quite the same problem. * our objective is node not
    going through all networks * Carsten: done with SSID * MCR: no SSID in
    15.4. Has PANID, but too short and other problems. * in 6TiSCH, IE to
    contain
        * proxy priority: reflects resources allocated for unknown nodes
        wanting to join * R says if it will answer unicast Router Solicitation
        * network ID * DODAG priority: reflects willingness to accept new
        traffic.
    * Carsten: this reveal node is trying to join
    * MCR: secret handshake in zero-touch way, would love it
    * Thomas: emphasizes waste of energy of blind search. This helps a lot.
    Real use case. * Pascal: agrees with Thomas. Mostly interested in DODAG
    priority. In the field, we see instability in structures that we build.
    Oscillations. * Pascal: load at the root is the load of thee network. Work
    to do is to end up with balanced situation * need new metric container.
    Will be transmitted unchanged as DIOs go down the network. * new DIO
    configuration option. To convey the new network ID. * Pascal: your new
    metric does for the whole network what an OF does for a node. * Pascal:
    number of node left, amount of bandwidth left. Not so much percentages,
    because could translate to different absolute values. * MCR: in storing
    mode, as RPL is now, we don't know the load of the nodes * Peter: can you
    say again what this documennt is exactly about? * MCR this is just the
    description of a DIO container. Maybe suggest way of calculating this
    metric. * Peter: parent selection in another document? * MCR: true. *
    Peter: who's read? who's willing to review? who thinks we should adopt? *
    Ines: we'll go to the mailing list.

[11:43] Open mic
    * Aris: finds all problems discussed very interesting. What about
    replicability? how to share information that would allow to reproduce
    situation in simulation * Rahul: agree it's a big issue. Working on a
    framework specifically for this. Whitefiled? framework. * MCR: F-interop is
    also very cool. * MCR: been the case in ROLL WG that issues were reported
    but no detailed info was available to simulate/replicate issue. * MCR:
    Cooja runs Contiki, does not allow to compare RIOT and Contiki
    implementations. * Thomas: there's a lot to verify. F-interop to verify
    interoperability. For performance, 6TiSCH python simulator and interface.
    Allows to enter a scenario and get graphs.
      Only part of the answer to your question, but still something.
    * Ines: introduces tomorrow's meeting.
    * Peter welcome feedback on time of this meeting. Do you prefer longer or
    shorter one?

[11:51] meeting ends

=====
Friday meeting

Friday 23/3 9h30-11h30

Ines+Peter: Introduction (5 min)

Charlie: Asymmetric AODV-P2P-RPL in LLNs (15 mins)
draft-ietf-roll-aodv-rpl-02

Pascal: ND only device connects to RPL DODAG. (20 mins)
draft-thubert-roll-unaware-leaves-01

Rahul: DCO performance report (15 mins)
draft-ietf-roll-efficient-npdao

Pascal: Objective function specification and selection for parent selection,
DAG selection  (30 minutes) draft-thubert-roll-unaware-leaves-01

Pascal: Root initiated routing state in RPL      (15 mins)
draft-ietf-roll-dao-projection-02

Dominique: state of Dis-modifications (5 min)
draft-ietf-roll-dis-modifications-00

xxxxx: RPL-load balancing (15 mins)
draft-qasem-roll-rpl-load-balancing-02

15 MINUTES DISCUSSION: All: Discussion on new subjects
Which topics and priority,
Authors,
Reviewers.

[9:30] Meeting starts

[9:31] Routing for RPL Leaves (Pascal)
    * original idea was low cost nodes roaming through 6LRs.
    * called a leaf, is RPL-unaware. Does not know RPL is being used. Only uses
    6LoWPAN ND * had to change 6LoWPAN-ND because fabric has to know what is
    the latest location, so that it can route to the leaf * comparing
    timestamps does not work because tolerance on timers and mobility speed
    unknown * now, source generates a sequence. Ordering becomes obvious * also
    change source address validation. Address could be spoofed (stolen) and
    traffic diverted. * association mechanism mimicking that of 802.11. Leaf
    pro-actively installs  state in the 6LR (equal to AP in 802.11) so that the
    6LR knows has to forward multicast
      traffic for this leaf
    * this supports RPL but also any other similar routing protocol
    * Pascal shows the address validation mechanism. ROVR is token to prove
    ownership of address. Only proves address on first hop * new spec: leaves
    set the R bit to 1 to instruct 6LR to inject this address into routing *
    Transaction ID is a sequence counter to be injected into the DAO Path
    Sequence Number. * Rahul: Path Sequence is optional * Pascal: believe it is
    mandatory. Otherwise, we have a problem * Rahul: will check. * Registration
    lifetime: in ND, expressed in minutes. In RPL, configuration that tells the
    time-unit. * Rahul: Transit Info not mandatory * Pascal: will check *
    Rahul: none of the open source RPL implementation currently use Path
    Sequence. * Pascal: if the MUST is missing, this is a bug. We'll look at it
    offline. * Pascal: still lacking a reference open-source implementation of
    RPL. Do not judge the quality of RPL by the quality of some implementations
    out there. * shows message exchange diagram. New spec mandates 6CIO option
    from 6LBR down to the 6LRs. * Peter (from the floor): what happens if we
    mix 6LR with and without the new option? * Pascal: the spec discusses this.
    It works. On security side, weaker because smaller keys. Spec recommends a
    leaf attaches to a "new" 6LR. An old 6LR on the way from the attachment 6LR
    and 5LBR is okay. * signaling is in the 6775-update doc, how proxy
    operation is done is in the backbone doc. * Got reviews from IESG, not
    quite closed yet but looking good. * shows diagram on address validation:
    protects the legitimate owner against other nodes trying to steal that
    address. * re-iterates that only first hop is protected, RPL is not. *
    we'll discuss on the mailing list on Rahul draft (DAO-ACK). * Pascal: if
    you're implementing RPL, understand that when a 6LR accepts a DOA from a
    child, it takes responsibility for transmitting ii up. * is the RPL root
    the LBR? technically, could be separate. In Pascal's mind, should be the
    same * big discussion that needs to be had: do we MUST that 6LBR and RPL
    root are one? * proposes to use RPL DAO to accomplish what DAR/DAC does. *
    remember that RPL will not do DAD, since ROVR doesn't go to Root. *
    summary: very simple node roams smoothly across meshed 6LRs, many DODAGs. *
    on terminology: RPL defines "leaf", a node that understands RPL but does
    not route. This draft defines "unaware-leaf", a node that doesn't even
    understand RPL. * pre-requisite: 6775-update, IP-in-IP, RPI header * if
    6LBR was not RPL root: could make it work, no too sure. * do we have a use
    case for it? * Peter: who has read the draft? a few hands? * Peter: is this
    6Tisch-related? useful to 6TiSCH, but not even routing-related. * Pascal:
    simple work, but really important. Most of it done at 6lo. * Pascal: had
    this dream from the start, could not implement it with RPL, now can. * work
    not quite done yet, if you are interested, join in.

[10:15] Asymmetric AODV-P2P-RPL in LLNs (Charlie)
    * allows asymmetrical routes between nodes pairs.
    * went into last call, got lots of comments
    * most extensive comments: some features of P2P-RPL not implemented in
    OADV-RPL. As a result, attempted to include these. * discussion on use of
    DSTN for sequence number. * Pascal: two sequence counters coming down from
    the root. One when new DAODAG is built (version number), rebuilding a new
    DODAG including reparenting. * DTSN is to refresh the state associated to
    current topology. * what exactly is your destination sequence number? *
    Charlie: not sure, will have it as a separate discussion. * will suggest
    using OADV's feature to deal with uni-directional links. * this draft was
    published quickly to meet the submission deadline. Will get a revised
    version soon. * Pascal: original P2P-RPL used DIO for RReq and DAO as
    RReply. Needs a certain degree of bidirectionality. * Pascal: Charlie, your
    work is the only one that uses DIO both ways to discover the route. This is
    good:
      P2P-RPL uses DIO in one way and DAO the other way, does not work as well
      in presence of asymmetrical links.
    * Pascal/Dominique: discussion on the causes for asymmetry.
    * this draft defines new RREQ/RREP option. Imported from 6997
    * new target option.
    * had discussion on pairing of InstanceIDs (one for each direction). <<
    missed part of it>>>> * to be done
        * citing 6997 cannot be normative, because it's experimental.
        * InstanceID conflicts
        * import black-hole link detection of OADV?
    * Rahul: you said asymmetrical link detection is out of scope.
    * Charlie: could make it in scope
    * Rahul: the probing of links for asymmetry should not be in scope
    * Charlie: the metric should be there
    * Pascal: doesn't seem we need to do anything. Building another DAG, using
    DIO. If a link is asymmetrical, flooding will not happen, that's it. *
    Peter: would like this document to be completed. Have this discussion on
    the mailing and get to a conclusion in the next few weeks.

[10:38] Route invalidation, experiment report (Rahul)
    * remember NPDAO sent downstream
    * DCO and NPDAO operating at same time in the network.
    * report link sent on the mailing list a month and half ago
    * two topologies, 50 and 100 nodes. All nodes are started at same time.
    * much less stale entries with DCO than with NPDAO.
    * control overhead better for DCO as well.
    * analysis of what happens on parent switching (identical in Contiki and
    RIOT). Send NPDAO immediately, schedule a new DAO for later. Hence route
    downtime. * Pascal: Contiki and RIOT implementations are not RPL. Don't
    state the quality of RPL based on these implementations. * Rahul: with DCO,
    .... * Pascal: you may be sending two DAOs, one gets slowed down, your DCO
    gets earlier. Don't be too quick in sending the uplink * Pascal: another
    point: traditional in LS to cleanup the bad state left over on mobility.
    From hearsay, proven to be complex. Should research on this. * Pascal: bad
    history of doing this in other routing protocols. * Alvaro: in other
    protocols, do flush. Problem is flushing for somebody else that's no longer
    there. State expires. Connectivity fails. * Alvaro: there has been
    proposals on proxying, nobody very happy with this. * Pascal: keep a note
    that we should experiment with this before standard RFC. I feel this is
    safe, but needs a check * Rahul: still kept the bit .... * Rahul: next steps
        * text changes (Destination Cleanup Object), but no semantic change for
        a long time. * would like to WGLC this
    * Peter: also wants this
    * Peter: perf report in appendix?
    * Peter: if you have publication elsewhere, you can also refer to it.
    * Pascal: Cisco and Huawei both have IPR on this.
    * Rahul has invited Pascal to join the work on this.

[10:56] Root initiated routing state in RPL (Pascal)
     * two implementations under way. One by Huwaei, one
     * invited Huawei (whom?) and Matt Gillmore to this draft.
     * not much progress recently
     * Need to discuss size of MoP, 3 bits. AODV uses a new MOP as well. We'll
     be short on bits pretty soon. * Charlie: discussion also holds for
     AODV-RPL. Should it use new MOP or new message numbers? * Pascal: 8 MOP
     values. 4 consumed in the base spec. 1 is experimental, can be claimed
     back. Leaving 5. * Remaining questions
         * how is the topology known to the root? non-storing, DAOs tell the
         DODAG. storing, not much. * how are node capabilities know to the
         root? extend the DAO to include things such as memory size? * Rahul: *
         Pascal: constrained nodes usually don't do storing mode. If you do
         storing mode, do it well. If node reparents, need to be able to
         reconstruct state. * mixed modes? * loop avoidance
    * Peter: could you reduce document to non-storing mode and avoid all the
    storing-mode related problems? * Pascal: answer is no. Initial motivation
    was to build networks with long lines of nodes, want to compress this line
    with local storing mode. Send in non-storing mode only to the beginning of
    the line. * Rahul: loop avoidance will be updated in this draft

[11:08] Status of draft-ietf-roll-dis-modifications-00
    * interest for this work re-iterated on the mailing list.
    * Dominique and Cenk will allocate resource to work on this by the summer
    * Pascal willing to help
    * discussion whether this draft should just provide the flags and options
    or should also recommend the use of each mode and option for different
    real-world situations * Pascal: we've had these discussions in hallways on
    multiple instances since Maastricht. * not much resource available to that.
    * Pascal: could target the experimental track and publish quickly *
    Dominique: will revive this discussion on the mailing list and move forward.

[11:23] meeting closed