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


IETF-99 roll minutes

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

Minutes

minutes-99-roll-00 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
          Presenter
          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] Micharl Richardson presenting Use of RPL info draft
          The draft has been completely rewritten. Not as simple as met the eye
          at first writing.
          Thanks Mike Heard for his constructive comments, including radical
          changes.
          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 accomodate 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 Optionss 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 th enew 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 again.
          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 anyways 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 explaine ratioanle 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, 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 explicitely 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 rebot 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,
          untested.
          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.
          Bier:
          Pascal: see BIER-TE (Traffic Enginnering) 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
          inefficieny. 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 Psacl), 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. CouPLld be translated to Bloom filters with usual pros and cons.
          (e.g. distribute the has functions).
          RPL builds preferred tree, install multicast through it.
          BIER has a bitmap, bit set for each node to receive the multicat.
          Several options on the allocation of bits (static, local automatic
          allocation, 6LBR-assigned).
          MCD: 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 aggration going up is OR operation on bitmap.
          Destintion can be one bit (unicast) or ultiple bits (multicast).
          Bloom makes this more elastic.
          Carsten: assuming 256 bis in bit map, this would limit network to
          256 nodes.
          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: runing late
          Ines: please bring this to the mailing list
          
          Pascal: now reliable multicast. ACKs aggragate 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
          draft-ietf-roll-efficient-npdao-00
          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, disover 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 int he 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 an more
          unless significant interest.
          Currently assumes links are symmetric.
          Pascal: would like to keep the asymetric capability.
          Shoudl 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
          draft-hou-roll-rpl-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 coputes 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), progagating 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 Function.
          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.
          Initally would send DAO with a via option to the exit point of the tunnel.
          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 beginnign of the meeting?
          Pascal: yes it can.
          Ines: who is willing ot 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 -