Minutes IETF104: roll
minutes-104-roll-00
| Meeting Minutes | Routing Over Low power and Lossy networks (roll) WG | |
|---|---|---|
| Date and time | 2019-03-25 15:10 | |
| Title | Minutes IETF104: roll | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-03-26 |
minutes-104-roll-00
https://etherpad.tools.ietf.org/p/notes-ietf-104-roll +-------------------------------------------------------------------------------------------------------------------------------------------------+ | IETF 104 - ROLL Meeting | | 16:10-18:10 Monday Afternoon session II - 25th March | | Material: https://datatracker.ietf.org/meeting/104/materials/ | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 16:10 - 16:20 | 10 min | Introduction | Ines/Peter | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 16:20 - 16:30 | 10 min | draft-ietf-roll-aodv-rpl-06 | Charlie | | | | Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 16:30 - 16:50 | 20 min | draft-rahul-roll-mop-ext-00 | Rahul | | | | RPL Mode of Operation extension | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 16:50 - 17:00 | 10 min | draft-ietf-roll-dao-projection-05 | Pascal | | | | Root initiated routing state in RPL | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 17:00 - 17:10 | 10 min | draft-thubert-roll-unaware-leaves-06 | Pascal | | | | Routing for RPL Leaves | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 17:10 - 17:20 | 10 min | draft-ietf-roll-nsa-extension-01 | Aris | | | | RPL DAG Metric Container Node State and Attribute object type extension | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 17:20 - 17:30 | 10 min | draft-koutsiamanis-roll-traffic-aware-of-00 | Aris | | | | Traffic-aware Objective Function | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 17:30 - 17:50 | 20 min | draft-audeoudh-rpl-asymmetric-links-00 | Henry | | | | Experimental observation of RPL: routing protocol overhead and asymmetric links | | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 17:50 - 18:05 | 15 min | RPL-BIER Status - How we proceed? | Toerless/Ines/Peter | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ | 18:05 - 18:10 | 05 min | Open Floor | Everyone | +--------------------+----------+-------------------------------------------------------------------------------------------+---------------------+ Meeting notes ------------------- [16:11] meeting starts [16:11] Intoduction (chairs) * Note Well, Blue sheets, etc. * no comments on proposed agenda * Milestones: we are late on many of them. Peter would rather keep them unchanged, any objection? none. * status of draft * rpl-observation was updated today. * useofrplinfo-25, believe has addressed all comments, now in WGLC [16:14] draft-rahul-roll-mop-ext-00 (Rahul Jadhav) * MOP field is 3 bits, already exhausted with current proposals. * MOP specify mandatory-to-implement functionalities (at least for the 6LR) * proposes a numbering extension for MOP values, using an extension field. * this draft also proposes to define Capabilities, which are features that may be optional. Need to advertise what features a node can do. * modeled along 802.11 * Rahul enphasizes that MOP extensions and Capabilities are independant. We can chose to have one or the other or both. * The impact on the memory requirement is critical. If capabilities are to be stored in the routing entry, big pb. * Pascal: orginally though MOPs to be mtuually exclusive (either storing or non-storing). Then DAO projection was additional, on top of. * Pascal: how to express that, in the future, we may have a main mode of operation and sub-modes not available to all nodes. * Inès (co-chair): who has read the draft? 4-5 people. * Inès (co-chair): Who is willing to review? Georgios, Inès. * Rahul: does this mean we can't advance DAO projection until this is finisehdd. * Pascal This one is normative reference in DAO projection. * Peter: what kind of dependency? * Pascal: signal the support of DAO projection. * Rahul: if we want to expedite, we can leave Capabilities out and only issue this draft with MOP extension. * Ines: would MOP extension be enough to clear the dependency? * Pascal: Capabilities could come later. * Ines: put this in RPL observation draft. Will be easier to discuss. Agreed? no obbjection. [16:28] draft-ietf-roll-aodv-rpl-06 (Charlie Perkins) * modifications to AODV-RPL draft based on comments received during WGLC.. * security considerations; bidirect asymm route discovery in addition to peer-to-peer route discovery * Security considerations - requested to be more explicit. This draft now presents the 6550 framework in details - not different than before, but more explicit. * Route discovery * Pascal: want to emphasize "shorter path". There could be different metrics. With this work, finds pathes with better metrics than through Objective Function. * other editorial improvments. * thinks this resolves the comments. * Inès: we believe this document is ready. Will issue a 1 week LC. Read again, especilly the security section. [16:35] draft-ietf-roll-dao-projection-05 (Pascal Thubert) * highlights changes since last version. Editorial. * Not expected to have many modes simultaneously on one network. One main mode and one DAO-projected mode should be enough. Restricts the risk of loops. * For projected route, use a different ICMP error type so that root does not confuse it with non-storing mode ICMP error. * Food for discussion: - how do we express the topology to the Root? - Capability container (similar to Dag Metric Container) - compress the control path. "via" option is going to be large, need for compression. DIO and DAO already sometimes hit the MTU limit. * most urgent feature needed is expression of capabilities. * Comments? * Rahul: compression has to be handled. Feel it is required. Tried to do it with 15.4. * Carsten: also question of whether to design a protocol in uncompressed form and rely on somebody else to compress it for you; or design it compressed in the first place. * Carsten: not sure what I would prefer in the case here. * Pascal: GHC? * Carsten: if it solves your problem, go ahead and use it. But bespoke compressor will always be better. * Pascal: 8138 was done here. Could do this as well. * Carsten: could use the same data structure as in 6loRH. * Inès: would be nice if you put this in RPL observation draft, so that we can discuss it more easily. * Inès: Pascal, send an email to the ML to ask for comments about this. [16:46] draft-thubert-roll-unaware-leaves-06 (Pascal Thubert) * summarises the 4 drafts bundle for wireless IPv6 ND (WIND): RFC8505 + 6lo-backbone-router + 6lo-ap-nd + 6lo-unicast-lookup. * the counterpart to RPL is this draft. Defines routing services (ND proxy, ...). * draft is stable. * Carsten: need to fix the name. This is about "hosts" in IETF terminology. * Pascal: this is about a RPL router does when a host uses 8505. * Pascal: * Carsten: making no requirement on hosts? * Pascal: one requirement on opaque field to be passed to the routing protocol (in 8505), only field loosely routing-related. * Carsten: host/router model is extended by something here. * Pascal: 8505 instructs any 6LN to have a TID. * Carsten: this is an extension to 8505, and how to handle this on the other side. * Pascal: yes, one line somewhere extends 8505. * Carsten: avoid "Leaf", change to "host". * Pascal: if you want. But people in this group are used to "leaf". * Rahul: * Pascal: * Inès: add to the terminology section what "host" means. * Pascal: hopefully, if we use the term "host", there will not be any ambiguity compared with "leaves". Will be addressed. * Carsten: the term "leaf" is in 6550, and not in the terminology section. * Pascal: I mean a RPL *unaware* leaf * Peter: who has read the draft? 6 hands * Carsten: once you add something to the host/router interfaces, the question comes: who else need this? Can it be generalized? * Pascal: 3 drafts use 8505 as expression of need from host to router. * Carsten: was asking about RPL instance ID. Who else could make good use of it? opportunity to generalise? * Pascal: RIFT, BBR, RPL use this. * Carsten: RPL Instance ID? * Pascal: 6775 introduced 6LBR, which is a router (the name) and a Registrar (its function). But Registrar could be anywhere in the netwrok. * Pascal: should we enforce that 6LBR is always the RPL root? DAO is used as a DAR. * Pascal: if separated, we need the keep-alive shown in the slide between the root and the 6LBR * Inès: we want to equate Root and LBR. Will check on the mailing list. [17:06] draft-ietf-roll-nsa-extension-01 (Aris Koutsiamanis) * Rahul's Comments are now addressed in the novel version * 6LowRH has been implemented in Contiki * The goal is to do Packet Replication and transmission over multiple paths, but control replication to avoid full flooding. * the draft creates an alternative path. The parent selection (primary / alternative) relies on the parent set of the possible parents. * new metric container format in DIO. Now mandate that prefixes are elided. This creates an additionnal overhead. We use the normal address compression scheme (6LoRH) * 3 modes of alternative parent selection. The choice depends on the primary parent, estimating the relevance of each alternative parent. * We have still to address the scope of the draft: should we keep it simple? Or should we make it the most complete as possible? * Rahul: my comment was that we have priority info from Michael's draft. Selection logic should be implementation specific. Great guidance in this draft, but should not be mandated. * Aris: another idea by Rahul was to add preference level to each parent (i.e. a priority byte) * Rahul: 6loRH defined in this draft? * Aris: no, reused from 8138. 5 bits used in 8138. So 3 bits are available, could be used for parent preference. * needs for more reviews: Dominique Barthel * Ines: next step is to address issues. * Georgios: do we need another draft to define how to select an alternative parent? * Rahul: a section already exists, detailing an example * Pascal: 6TiSCH has nothing to add to this. Maybe SPAWN will. [17:16] draft-koutsiamanis-roll-traffic-aware-of-00 (Aris Koutsiamanis) * novel Objective Function which tries to balance the load globally in the network (using a remaining througput metric). It monitors the throughput during a given interval window. * we inserted some novel TLV to configure the measurement process, from the root. * Pascal has pointed out the problem of oscillations. The current draft doesn't yet address this issue, it just acknowledges it. * example where an unbalanced situation is created with a standard OF. * novel metric determining the remaining throughput (with a sliding window). This OF is similar to MRHOF, but uses the RT metric. * also addresses the issues of enrollemnt: pick the best PAN and DODAG. RT in EB. * the implementation is almost ready * Pascal goes through a problematic example. Throughput exposed per parent, but doesn't account for path convergence uphill. * Aris: you expose the throughput you use, but also what you are fowarding. * Ines: next step it to address the oscillation issue. Can ask help from the mailing list. Then we can think of adotio. [17:30] draft-audeoudh-rpl-asymmetric-links-00 (Henry-Joseph Audeoud) * researching routing protocols, compared to RPL, brough about observations on RPL behaviour. * 3 scenarios: background control traffic / muted node / deaf node. * asymmetric links do exists. * goes through experimental scenarios. FiT IoT-lab, Contiki. * a large number of unicast DIO practically (for probing). MRHOF doesn't define how to compute the link quality toward each potential parent * Question raised: what should be a node's reaction on receiving a unicast DIO? * Contiki uses unicast DIO for link estimation. Counted as redundancy. * Pascal: bad idea, should not be counted. They are not redundant. * Rahul: should not be counted. 6550 specifies that Trickle timer should not * Thomas: talk to Simon Duquennoy. * Thomas: AFAIR, unicast DIOs in COntiki used to do a weird way of local repair. Don't quite really remember. Answer is not in 6550. * Thomas: the high number of DIOs you're seeing is not due to 6550, but to tricks in Contiki. * Rahul: * Thomas: texting Simon to see if he's available. * Next experiment. Broadcast DIS, therefore broadcast DIO. * We expect that LL is able to detect and blacklist asymetrical links. But DIS and IO are broadcast without ack * Rahul: blacklisting is difficult to do, due to memory required. * Pascal: replaces an attack on bandwidth with an attack on memory. * Pascal: Trickle throttles. Restting the Trickle timer is known to be an issue. DIS-modification should be resumed. A draft on AODV already supports asymmetrical links. RPL assumes that an external mechanism exists to detect and to mute asymmetrical links (e.g. ND). * Pascal: if link is not bidirect, RPL should not let the ode have an IP address and take part in the network. * Third scenario: after some time, a node is nearly-fully muted. * Conclusions: sort out Contiki tricks and RPL inherent properties * Is the lik quality estimation part of RPL or not? * Thomas: Simon is available to talk. But not enough time anymore. * Pascal: need to resume work on DIS-modification. How to really handle all the cases? * Peter: measurment, experiments then specification. * Pascal: also use cases that you know in advance: power outage, or installation of single new meter. We haven't described these use cases [17:52] RPL-BIER Status - How we proceed? (Toerless Eckert) * work done until IETF103, but not written down properly. * thubert-roll-bier already captues part of it. * Carsten's roll-ccast has another part * first identify what is informational, what is normative. Maybe pull infomrational into another doc. * Carsten: serverl angles to look at his from. One is: who can implement this. Bloom filters have a lot of patent claims. Original draft tried to sail around these. Whether we were successful or not, I don't know. * Carsten: merging increases the risk again. * Toerless: in Pascal's draft, not much details on Bloom filters. Leaving it to Carsten's draft. * Carsten: any IPR claims at this time on this? * Toerless: I don't know. * Peter: I don't think so. * Carsten: this doc is 6 years old. At the time, it looked good wrt to IPR. * Pascal: agree with Carsten that we need to look at IPR, especially for the normative part. * pascal: when we start describing what we do when we use Bloom, or explicit bits, will check on IPR. I have some, by the way. * Toerless: my opinion was we could focus on the specification part. In the end, we still have to it. Could split in several quadrants. Focussed discussion on ROLL-BIER continues in the Paris room, immediately. [18:05] Meeting adjourns