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] 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 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 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 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 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, 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 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 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: 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 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, 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 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 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 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. Initially 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 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