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