+--------------------------------------------------------------------------------------------------------+ | AGENDA ROLL IETF 103 | +--------------------------------------------------------------------------------------------------------+ | Date: Monday, Nov 5, 2018 (UTC+07) | | | | Time: 9:00 - 11:00 - 120 minutes - Morning session I | | | | Place: Boromphimarn 1/2 - 3rd Floor | +--------------------------------------------------------------------------------------------------------+ http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-roll Agenda 09:00 - 09:05 WG Introduction (Ines/Peter) 09:05 - 09:35 ROLL-BIER Design Team Status (Toerless) 09:35 - 09:45 draft-ietf-roll-efficient-npdao-09 (Rahul) 09:45 - 10:00 † draft-ietf-roll-rpl-observations-00 (Rahul) 10:00 - 10:10 draft-ietf-roll-aodv-rpl-05 † (Charlie) 10:10 - 10:25 †draft-ji-roll-traffic-aware-objective-function-02 (Georgios) 10:25 - 10:40 draft-koutsiamanis-roll-nsa-extension-02 (Georgios) 10:40 - 10:55 draft-ietf-roll-dao-projection-04 (Pascal) draft-thubert-roll-unaware-leaves-05 10:55 - 11:00 Open Floor (everyone) Meeeting notes [9:00] Meeting starts * Blue sheets, notetakers, Jabber scribe, Note Well * Agenda : no comments [9:01] WG Status - Introduction (Ines) * shows milestones, drafts in progress, open tickets (3 new after last meeting, #187, 188, 189) [9:03] ROLL-BIER Design Team Status (Toerless) * goes through introduction slides, goal of BIER in ROLL * example of lighting control application * Carsten: "client-server", you mean small thing and big box, not client-server communication? ACTION: Toerless please fix the slides to use some other terminology. * Toerless: indeed * not done in BIER WG so far, bring individual bits to the app * Simon S: server has state, client has none * Greg Shepherd: if there is a gap for ..., please bring this up in BIER * Carsten: could also use sender and receiver terms. * framework includes nodes that are not routing node ("Lightweight nodes") * Greg: ... * in ROLL, one differentiation from BIER WG is lossy compressed bitmap with bloom filters * in forwarding plane, no distinction between BIER and BIER-TE models * Pascal Thubert: think was clear no need to reset the bits. BIER does reset to avoid loop (because flooded), but RPL uses DODAGs. * Pascal: another draft about managing state in the TE world. Come to PAW bar-BOF (Tuesday 11am), advertised on Detnet list. * Pascal: in RPL, additinoal header says if packet travelling up or down the structure. Packet will never loop. * Toerless: so would explicitely ignore bits that have the packet go up again. * Pascal: set of bits per child instead of per leaf. * Pascal: one bit per adjacency. In storing mode, routing table has state per child in the DODAG. In non-storing mode, ... * Toerless: let's capture this properly * Carsten: this a graph, not a tree. If you never reset bits, nodes lower in graph never sure that .... * Toerless: runnign out of time. Goes through list of related documents. * decision made to use IP multicast (knowing that it is compressed with 6LoRH). * Pascal: * Toerless: if unicast, one bit only. False positive are possible, but will be recognised (discarded) at destination. * Carsten: we need a day to discuss this. * Pascal: BIER allows saving a lot of state, critical for RPL in storing mode. * Pascal: one bitmap bit per child. * Toerless: lets make sure to capture this properly. * MCR: * Pascal: still need to have some info per leaf. But bitmap has one bit per child. Elasticity canbe obtained with bloom filters * Greg: * Pascal: talking non-TE at this time * Carsten: by limiting to 256, we make storing mode much more manageable. * Carsten: sparse groups can be addressed with pretty small filters. Dense groups need larger filters. * Toerless: need to focuss scope of what we need to work on. * muticast, do we need MLDv2 or can we do with SSM only. * Carsten: comment on choosing SSM. Everything goes through RPL root, solves SSM ... problem. The whole thing assumesthat the whole group is within one RPL domain. * Greg: going back to SSM, dont forget that BIER domain is kind of a RP. * Pascal: also remember RPL has instances, could be used for ... * Peter, Toerless: need to plan for a full day to discuss this at a future meeting. In person or at virtual interim meeting. * Greg: in-person is a huge difference.e ACTION: investigate having an interim meeting, virtual interims, IETF104+ day-long interaction [9:45] draft-ietf-roll-efficient-npdao-09 (Rahul) * goes through recent updates to the draft * Peter: this document is finished and we will send it for publication [9:47] draft-ietf-roll-rpl-observations-00 (Rahul) * document may not end up being published, but will be kept around for reference * discussing various ambiguous parts of RPL. * First observation: is DTSN a lollipop counter? how is DTSN used? * Pascal: at the time RPL was specified, could not decide i pull or push model for DAOs. Left it open on purpose. Not enough experience at the time * MCR: could be clearly articulated in 6550 that push model and pull models are possible. Would like to have a specific draft for this. ACTION: Rahul to create new draft on DTSN counter. * Second observation: DAO-ACK behavior * is DAO-ACK to be sent downstream right away or after DAO-ACK received from upstream (the latter interpretation means maintaining long lasting state). * Pascal: Contiki implemented this hack ofr a particular use case. Design on the left ot hte slide is the official behavior in RPL. * Pascal: parent takes responsability and pushes it through, or detach+poison. * Pascal: no extra state, just a bit in routing table that ACK was received from parent. * Pascal: we could specify a mechanism to get an ACK from the root all the way down the DODAG. Could be a new draft. ACTION: new draft on ACK from the root? * Rahul: RPL not good at handling aggregating targets, how to ACK if one fails. * upcoming observations: e.g. use of multiple links [10:07] draft-ietf-roll-aodv-rpl-05 † (Charlie) * will go through comments received during Last Call. * SequenceNumbers: maybe could reuse DODAGVersionNumber and DTSN fields, but this is new Mode of Operation anyway. * Peter: will review it personnally, [10:16] draft-ji-roll-traffic-aware-objective-function-02 (Aris) * goes through changes since -01 * recap: several Objective Functions for RPL (two RFCs and one draft). This one addresses the load balancing requirement. * explains Remaining Throughput computation, shows examples. * Pascal: throughput is dangerous metric. Leads to oscillations. Arpanet experience. Use it together with another metric to slowly rebalance part of your traffic, not switch parent abruptly. * convert Remaining Troughput to Join prirority (PAN priority in EB at layer 2). * asking for next steps: - two volunteers to review (Rahul and Dominique) * address comments by Pascal and call for adoption [10:32] draft-koutsiamanis-roll-nsa-extension-02 (Georgios) * goes over principles of this draft: Packet Replication, Elimination and Overhearing. * find alternate parent(s) that has (have) Common Ancestor. * three different versions implemented. Each one corresponds to a different criterion to select alternative parent. - strict. May lead to no replication. - medium - relaxed. Increased cost (energy, bandwidth) * goes through simulation results * Peter: do these simulations include link failures? * Georgios: yes, 70-100% PDR. * "strict to medium" optimisation. If not replication possible at some stage in strict mode, allow medium mode. * Rahul: how to apply PRE only to a subset of traffic? * so far for the whole traffic * Pascal: this inherits from work done at Detnet, which identifies flows. This can be done here too, see PAW discussion. * Georgios: journal paper uses Cooja simulations. * Rahul: beware of Cooja. Very different results with NS3 * Ines: who is willing to reveiw this draft? Rahul ACTION: Rahul volunteered to review. * Humm for adoption? several hums. Against? one hum. -(Correction on 16-11-2018: no hums against, the person understood wrong the humm adoption, the person clarified to the chairs the situation after the meeting ends) * Pascal: with Route projection, Controller could project the two route with better reliability than discovering alternative parents * Charlie: selection algorithm bsed on grand parents looks nice in the grid drawing. Does it apply to real life networks? * Pascal: using overhearing opportunity. Think of a wave, restricted to a wave guide. * Charlie: please show other network topologies. Also, there are other ways to find alternate routes. * Pascal * Aris: related to Route Porjection. This is distributed, useful when you don't have a central controller. [10:56] draft-ietf-roll-dao-projection-04 (Pascal) * Taking RPL into the SDN world. [10:56] draft-thubert-roll-unaware-leaves-05 (Pascal) * tell what the WG does want and what it does not want into this draft. * router registers an address on behalf on RPL-unaware node. * discussion needed: is LBR the RPL root or not necessarily? if yes, some flows described here can go away. * also Address Protection - ND draft. Crypto mechanism to avoid foreign node to register address already in use. However, protection at the edge. A rogue router could still register such an address. * Ines: put these questions on the mailing list. [11:03] meeting adjourns