* 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: Alia Atlas, Alvaro Retana, Deborah Brungard | 2008-Feb-15 —  

IETF-99 roll minutes

Session 2017-07-20 1330-1530: Karlin I/II - Audio stream - roll chatroom


minutes-99-roll-01 minutes

          Agenda of the ROLL  WG
          Date:Thursday, July 20, 2017 (CEST)
          Time: 13:30-15:30 Thursday Afternoon session I : 120 minutes
          Topic to Present
          ROLL Status meeting - (10 min.)
          ----->          Peter/Ines
          RPL-info (20 min.) - draft-ietf-roll-useofrplinfo
                             ----->           Michael
          Multicast-Bier (20 min.) - draft-ietf-roll-ccast
                            ----->           Carsten
          No-Path DAO (15 min.) - draft-ietf-roll-efficient-npdao
                     ----->           Rahul
          AODV-RPL - (15 min.) - draft-ietf-roll-aodv-rpl
                                    ----->           Charlie
          Load Balancing - (15 min.) - draft-hou-roll-rpl-parent-selection
            ------>           Jianqiang
          DAO-projection - (20 min.) - draft-ietf-roll-dao-projection
                 ------>         Pascal
          Q&A (5 min.)
                                ------>           Everyone
          [13:32] meeting starts
          Ines Note well, agenda
          shows list of milestones
          be aware 2 drafts have IPR
          shows list of tickets
          [13:33] Michael Richardson presenting Use of RPL info draft
          The draft has been completely rewritten. Not as simple as met the eye
          at first writing.
          Thanks to Mike Heard for his constructive comments, including radical
          Also text clarification.
          Why update 6553? we changed the bits on the wire because of trouble
          adding / substracting headers for devices that do not speak RPL.
          To accommodate the pure need we'd have to have a transport hop by hop,
          with decap, encap.
          So we decided that the control bits in the option type should clarify
          that if the option ion HbH is not understood (or if the device is not
          configure to care for the option) the option may be ignored. RPI is now
          option 0x23.
          Then came changes to 2460bis. Introduced the behaviour we wanted.
          Now update 6553: processing of HyH Option is now optional.
          Pascal: compress the outer IP header makes it very cheap.
          Michael : adding 6LoRH created a flag day. We are surfing that flag
          day. so the introduction of 0x23 can be synchronized.
          Use a DIO option for telling nodes to uses the new code.
          Pascal: Configuration Option could be used for that.
          MCR: good point. Will do.
          Should we bother?
          Pascal: what if device reboots? will use 0x63 again until sees the option
          MCR: if reboots, need to hear a parent anyway. New nodes will accept
          0x232 and 0x63. Only question is which one to transmit.
          Pascal: option may not be present in all DIOs.
          Rahul: persistent storage expected anyway for other reasons.
          Pascal: all right. Persistent storage is expected.
          MCR: Flag day option useful? very little response, no opposition
          MCR: Should we change from 0x63 to 0x23? 6 hands. No opposed.
          Juliusz: can you please explain the rationale to use 0x63 initially?
          MCR: if nodes in DODAG also connected through other links and packets
          going through the wrong interface, drop packet. But in reality, we can't
          remove packet without IP-in-IP.
          Pascal: MCR forgot to say: nodes on non-RPL network would forward the
          packet and potentially inject them back into the RPL network. That would
          be a problem.
          MCR: inital experimenter ... This draft explicitly created to document
          what to do with these headers, so many cases.
          Pascal: we are clarifying that  ... is not an option. Was a problem with
          the initial Contiki implementation.
          MCR: summary: .. we'll add text clarifying reboot assumption.
          Peter: we'll have a new version and do WGLC on that.
          Inès: please read the new version when it's out.
          [13:57] Carsten Source-Routed Multicast for RPL
          Multicast doesn't work in our networks.
          Still want to make it work. Several solutions: MPL for storing mode,
          In non-storing mode. Nodes need to know they are members down the
          tree. But don't want to store the state.
          Embedding an outgoing interface list does not work.
          Pascal: see BIER-TE (Traffic Engineering) similar to this concept.
          Bloom filters: seemingly natural solution. Has been around for
          long time. Uses hash functions. Nodes check their outgoing interface
          against bloom filter to decide to send. False positives introduces some
          inefficiency. Showed damage is not too large. Uses a Multicast listener
          option similar to a DAO.
          Pascal: Carsten makes two points: selection of next hop and compression
          of route description. Orthogonal to each other.
          Carsten: root has knowledge of network, is in a good position to make
          good decision.
          Use a 6LoRH option to carry this field (see draft by Pascal), not RPL
          option in IP-in-IP packet.
          Implemented in 2013 on Contiki to play with it. Industrial implementation
          coming up soon.
          [14:11] Pascal BIER/RPL
          remember two angles : storing mode and representation with individual
          bits. Could be translated to Bloom filters with usual pros and cons.
          (e.g. distribute the hash functions).
          RPL builds preferred tree, install multicast through it.
          BIER has a bitmap, bit set for each node to receive the multicast.
          Several options on the allocation of bits (static, local automatic
          allocation, 6LBR-assigned).
          MCR: does 6LBR know stuff that makes allocation significantly better?
          Pascal: will show in next slide.
          With BIER, need state for each immediate child, which is the size of
          neighbor cache.
          DAO aggregation going up is OR operation on bitmap.
          Destination can be one bit (unicast) or multiple bits (multicast).
          Bloom makes this more elastic.
          Carsten: assuming 256 bis in bit map, this would limit network to 256
          Pascal: not quite. There's a notion of groups in BIER.
          Carsten: Bloom filters change two things. Describe forwarders, not
          destinations. And ...
          Juliusz: why do you index forwarders in one case, and destinations in
          the other case?
          Pascal: vertices or edges.
          Juliusz: what would be the advantage of index the vertices?
          Pascal: in my spare slides. In storing mode, less vertices than edges
          to leaf nodes
          MCR: taken multicast and used it to simplify unicast. You have optimized
          storing mode.
          Peter: how are we going forward with these documents
          Pascal: need some free bits to not allocate old bits to new node until
          sure old node is gone.
          Peter: running late
          Ines: please bring this to the mailing list
          Pascal: now reliable multicast. ACKs aggregate exactly like the DAO,
          through an OR operation.
          Retransmission map simply built out of previous map, "minus" (==XOR)
          the ACK map.
          Ines: please write this draft just for me :-)
          [14:33] Rahul Jadhav, Efficient No-Path DAO for RPL storing MOP
          Issue presented at Chicago. Recap here. NPDAO needs to go down.
          Contiki implementation done.
          MCR: we have enough type code for you to ask for a new type code. No
          drought of numbers. Cleaner. keep same structure, just other semantics.
          Pascal: would feel more confident with new code, just to make sure not
          mis-interpreted by old nodes.
          Psacal: we should not be repairing routes that are not used. RPI is
          meant for that, discover and fix situations on the spot.
          Pascal: put the right words of caution, how to use your mechanism wisely.
          Rahul: actually situation improved.
          Pascal: if no traffic, not improved.
          Rahul: neighbor churn and other cases described in the draft.
          Zhao : concurs to add explanation to the draft on when to use it.
          Ines: please send comments to Rahul's draft on the mailing list.
          [14:43] Charlie Perkins AODV-RPL implementation
          No significant change to the draft.
          Implementation done.
          Should AODV-RPL specify non-storing mode?
          Messages much smaller in storing mode.
          Should put non-storing mode in same of different draft? But should do
          non-storing mode at all?
          Peter: does the audience think non-storing mode should be done? no hands.
          Peter: opposite question. No hands.
          Charlie: principle of inertia. Will not do it and not suggest it any
          more unless significant interest.
          Currently assumes links are symmetric.
          Pascal: would like to keep the asymmetric capability.
          Should routes have a lifetime? issue was brought up on the mailing list.
          Peter: let's wait.
          Draft ready for last call (since not much left to do)
          Implementation on github.com/lavanyahm
          Ines: who is willing to read and comment on the document? 3 hands
          Ines: please add to the draft more information on AODV security.
          [14:53] Jianqiang Hou Parent selection
          Two problems motivated this work.
          Randomly Unbalanced Networks (has been described in IETF98).
          Goal to balance number of children. Indirect way of balancing traffic,
          in case nodes send same amount of traffic.
          Pascal: (regarding side 4) traffic comes form leaves, not children. If
          you want to balance traffic, use something that is related to traffic,
          not children.
          Proposed solution computes number of children from Neighbor Table,
          combine this metric with other metrics/constraints (like ETX, ...)
          proposes new metric in DMC, called CNC for Child Node Count.
          Comparison with draft-qasem-roll-rpl-load-balancing, which puts node
          address in DIO option.
          Pascal: we have discussed for a long time at 6TiSCH a willingness to join
          the DODAG. Select a Join Proxy. Willingness to be chosen as Join Proxy,
          very abstract. Metric expressing this willingness should come from the top
          (the DAGROOT), propagating down can already reduce willingness. Nothing
          to do with the Rank. You MUST NOT mix the two because the semantic is
          very different. There has to be a Join Function, similar to the Objective
          Jianqiang: good suggestion. But if Root controls everything, will take
          time for the network to converge.
          Diego: other problem with this proposal. If child count limit, a node
          may be left alone.
          Jianqiang: in storing mode, use DAO. In non-storing mode, use NS+ARO.
          Ines: please read draft and send comments to mailing list.
          [15:08] Pascal Thubert DAO Projection
          This draft brings SDN into RPL.
          creates a tunnel into the network.
          Rewrote the draft following Rahul's proposal.
          Initially would send DAO with a via option to the exit point of the
          Now multiple via options.
          Questions to the audience:
          Rahul asked about loop avoidance with all this, in particular loose and
          not end-to-end route.
          Answer is to use the O bit (dataplane validation).
          Pascal shows example of tunnel installation across network. Data packets
          will use SRH.
          Case from leaf node to leaf node could be done as well.
          Peter: could this use bitmap as shown at the beginning of the meeting?
          Pascal: yes it can.
          Ines: who is willing to review this doc? 3 hands (Diego, Rahul, ...)
          [15:19] AOB
          Peter: we'll keep working on these drafts and move them forward.
          Ines: no more question?
          [15:20] meeting ends

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