* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Roll Status Pages

Routing Over Low power and Lossy networks (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2008-Feb-15 —  

IETF-101 roll minutes

Session 2018-03-22 0930-1200: Park Suite - Audio stream - roll chatroom
Session 2018-03-23 0930-1130: Viscount - Audio stream - roll chatroom


minutes-101-roll-00 minutes

          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)
          Carsten (and Pascal) use of BIER in RPL uni- and multicast (45 minutes)
          Michael (and xxxx): Parent selection before or after enrollment (30
          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
              * 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
              * 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
             * 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
             * Carsten: your draft has NSA in the title ;-)
             * Peter: how does your proposal co-exist with other parent selection
             * 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
             * Peter: would be nice if this draft reflects how it interacts with
             * 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
                  * RPL spec say aggregated target is possible, but how to handle
                  * 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
              * 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
              * 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
          [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
              * 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
              * 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
              * 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
              * 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)
          Pascal: ND only device connects to RPL DODAG. (20 mins)
          Rahul: DCO performance report (15 mins)
          Pascal: Objective function specification and selection for parent
          selection, DAG selection  (30 minutes)
          Pascal: Root initiated routing state in RPL      (15 mins)
          Dominique: state of Dis-modifications (5 min)
          xxxxx: RPL-load balancing (15 mins)
          15 MINUTES DISCUSSION: All: Discussion on new subjects
          Which topics and priority,
          [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
              * 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
              * 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
              * 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
              * 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
              * 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
              * 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
              * 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
              * 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

Generated from PyHt script /wg/roll/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -