ROLL WG Meeting IETF 98 - Chicago Thursday, 30 March, 2017, 17:40 - 18:40 Chairs: Ines Robles and Peter van der Stok Agenda State of the WG 17:40 - 17:50 (10 min.) Ines & Peter DAO projection 17:50 - 18:00 (10 min.) Pascal * https://tools.ietf.org/html/draft-ietf-roll-dao-projection-01 Npdao optimization 18:00 - 18:14 (14 min.) Rahul * https://tools.ietf.org/html/draft-jadhav-roll-efficient-npdao-00#section-4 Load-balancing 18:14 - 18:24 (10 min.) Mamoun * https://datatracker.ietf.org/doc/html/draft-qasem-roll-rpl-load-balancing AODV-RPL 18:24 - 18:33 (9 min.) Charlie * https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl RPL-info 18:33 - 18:38 (5 min.) Michael Q&A 18:38 - 18:40 (2 min.) Open Mic Meeting minutes [17:41] State of the WG 17:40 - 17:50 (10 min.) Ines & Peter * Chartered deliverables: some delays. * Lists WG drafts, related drafts, open tickets [17:44] DAO projection 17:50 - 18:00 (10 min.) Pascal * https://tools.ietf.org/html/draft-ietf-roll-dao-projection-01 * now a WG document * recent addition of Source Routed projected state. Many new examples. * main text focusses on the mechanism, example are pushed to Apendices. * question to the audience: is there value to be able to project any type DAO into the DODAG? * if multiple addresses in one VIO, means projected path. * if multiple VIAs, means * question is how to compress all of this. * Peter: like the projected DAO, but how does the root know how much space is available in the node? * Pascal: so far considered out of scope, external means such as Management. However, if situation is dynamic or if multiple roots can inject state, we need a protocol to learn about remaining space. If people interested in thi scapability let it be known on the mailing list. * IP-IP encapsulation * e.g. a 16-hop route, want to install for route segments of 4 hops. One address replaces 4. This is different from encapsulation * discussion had on the mailing list: how is topology known to the root? node capabilities known to the root? do we want mixed mode? * comment on the mailing list about these topics. * Pascal goes through example. Compares path stretch (node 51 to 53) in non-storing mode, storing mode, and with new functionality in storing mode. In non-storing mode, 41 will encapsulate and source-route to 43 via 42. See the final slides online. * Rahul: complexity of mixed mode when DAG has inconsistencies. E.g., a loop. * Pascal: the new DAO would inject route of higher administrative preference. * Rahul: no way to solve inconsistency. * Pascal: to be discussed on the mailing list [18:02] NP-DAO optimization 18:00 - 18:14 (14 min.) Rahul * https://tools.ietf.org/html/draft-jadhav-roll-efficient-npdao-00#section-4 * draft first presented in Buenos Aires. Applies to storing mode. * simple solution to handle the problem * a lot of care has been given in RPL to create routes, not so much on removing them. This works addresses this. * currently, NoPath-DAO is sent along the bad/failing/disapperaring path. This is going to fail by design. Also ,NP-DAO and new DAO follow different paths, different delay, so there may be a period of time during which there is no route at all. * proposed change: the common parent is responsible for sending a NP-DAO *down* the old path to prune the stale state. * Pascal: clarifying question. This is pruning the broken branch from the trunk. Rahul cofirms * This also allows invalidating routes for dependant nodes, not just reporting node * Mcr: does this mean .. ? Rahul: D sends to A which send NP-DAO down * MCR goes through example. What i traffic from J to C? ... * Rahul: this improves the situation vs. previous situation. * This limits the route downtime, but there * Pascal: moving between DODAGs, DODAGthe roots exchange ND with new EARO option so the old root is aware that the node has now attached to the new root. The expectation was that a flow exactmy like this would clean up the stale routes in the old , same design was done. So this is what we need. * Rahul: we'll also look at the Backbone router. * changes: I flag to mean "invalidate on my behalf". R flag to tell Reverse direction (i.e. going down). [18:15] Load-balancing 18:14 - 18:24 (10 min.) Mamoun * https://datatracker.ietf.org/doc/html/draft-qasem-roll-rpl-load-balancing * idea presented at a IEEE conference in oct 2016, paper on line * RPL missing a mechanism to balance number of children. * example presented, all children select a same parent, leads to dissymmetry * Pascal: in storing mode, node 3 can run out of memory. There is (could be) an overload bit in DIO to tell "attach to another node". Regrading the saturatino of throughput, use the throughput metric. * Dominique: to solve the problem of ndoes running out of energy, use the remainning energy metric. * Rahul: allow for nodes to count the number of children without creating new messages or having extra traffic. * propose to have DIO include an option with IP address of parent. Parent will process DIO even though rank is greater and recognize its address. * IOW this leverages a DIO that would be ignored otherwise. * Pascal: you're showing trees. RPL is about DODAGs. Nodes in the middle would attach to both anyways. [18:31] AODV-RPL 18:24 - 18:33 (9 min.) Charlie * https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl * changes: some editorial. appendix to describe simulation. Code will be released. * technical change: instance ID, explanation of S bit. * details about example topologies added/changed * pick the odd/even bit in the instance ID to indicate rreq vs. rrep * if RREP turns out to have id of RREQ + 1, saves putting the TargetAddress in the DIO. If conflict, assign another id and put the TargetAddress. * Pascal: Seems there should be no conflict. Name space is from the Requester. * Charlie: need to think about it. Pascal: if we save this bit and complexity, would be great. * Pascal crafts a solution: One bit Global/Local. One bit already for the direction. You don't need the odd/even trick at all. [18:39] RPL-info 18:33 - 18:38 (5 min.) Michael * * rewrote the security for IP in IP. Need good BCP 38 filtering at the root. * Maybe problem for with efficient ND in the backbone * IP in IP causes longer path that can be alleviated by DAO projection * humm for document approval: humms heard. Against? none heard. [18:41] Meeting ends