ROLL IETF 107 Interim Meeting Jabber room: roll@jabber.ietf.org -- information for setting https://www.ietf.org/how/meetings/jabber/ Play recording (2 hrs 4 mins): https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/e1e20904ec454fd383f0b40ae280c455Recording password: (This recording does not require a password.) Webex Details: Wednesday, Apr 29, 2020 6:45 am | 3 hours | (UTC-04:00) Eastern Time (US & Canada) Meeting number: 610 440 357 Password: Pp6DfDQce26 https://ietf.webex.com/ietf/j.php?MTID=m976a599b4a6b6be830ec4e500329fd33 Join by video system Dial 610440357@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) 1-877-668-4493 Call-in toll free number (US/Canada) Access code: 610 440 357 Minutes are at the bottom For the minutes: Most common IOT Routing Protocol RPL- Orhan Ergun and Pascal Thubert inventor of the protocol https://www.youtube.com/watch?v=Q_-dvNZLHzs&list=WL&index=39&t=29s +-----------------------------------------------------------------------------------------------------------------+ | PARTICIPANTS - BLUESHEET - | +-----------------------------------------------------------------------------------------------------------------+ Webex: 6 people Jabber: 13 people NAME --- AFFILIATION Ines Robles Aalto University Remous-Aris Koutsiamanis --- IMT Atlantique, France Pascal Thubert - Cisco Systems France Rahul Jadhav - Huawei Rabi Narayan Sahoo - Juniper Dominique Barthel - Orange Dimitrios Sourailidis --- IMT Atlantique, France Michael Richardson, Sandelman Software Works Georgios PAPADOPOULOS - IMT Atlantique, Framce Tim Costello - BT Amelia Andersdotter (CENTR) Alvaro Retana - Futurewei Meeting notes below. Agenda Interim Meeting ROLL IETF 107 : +------------------------+----------------------------------------------------------------------+-------------------+ | Time | Topic | Presenter | +------------------------+----------------------------------------------------------------------+-------------------+ | 11:00 - 11:10 (10 min) | WG Status | Ines/Dominique | +------------------------+----------------------------------------------------------------------+-------------------+ | 11:10 - 11:30 (20 min) | draft-ietf-roll-unaware-leaves | Pascal | +------------------------+----------------------------------------------------------------------+-------------------+ | 11:30- 11:35 (5 min) | NPDAO and unaware-leaves | Rahul | +------------------------+----------------------------------------------------------------------+-------------------+ | 11:35 - 11:40 (5 min) | Updates on AP-ND and 6BBR, state of cluster C310 | Pascal | +------------------ -----+----------------------------------------------------------------------+-------------------+ | 11:40 - 11:55 (15 min) | draft-ietf-roll-capabilities / draft-ietf-roll-mopex | Rahul | +------------------------+----------------------------------------------------------------------+-------------------+ | 11:55 - 12:05 (10 min) | draft-ietf-roll-nsa-extension | Aris | +------------------------+----------------------------------------------------------------------+-------------------+ | 12:05 - 12:15 (10 min) | draft-ietf-roll-rpl-observations | Rahul | +------------------------+----------------------------------------------------------------------+-------------------+ | 12:15 - 12:25 (10 min) | draft-papadopoulos-roll-dis-mods-use-cases | Georgios | +------------------------+----------------------------------------------------------------------+-------------------+ | 12:25 - 12:35 (10 min) | draft-ietf-roll-enrollment-priority | Michael | -------------------------+----------------------------------------------------------------------+-------------------+ | 12:35 - 12:45 (10 min) | draft-thubert-roll-eliding-dio-information | Pascal | +------------------------+----------------------------------------------------------------------+-------------------+ 12:45 - 13:00 (15 min) | Open Floor | Everyone | +-----------------------+----------------------------------------------------------------------+-------------------+ Meeting minutes Times in UTC [11:02] WG status (Ines) [11:07] draft-ietf-roll-unaware-leaves (Pascal) was holding Cluster 310. need from the field. This draft has normative dependency to UseOfRPLInfo. 9 slides illustrate the various situations. They are good help to read the draft. Last 4 drawings are new recommendations. Rahul: requests to put these slides into github, into the ROLL/RAL repository. MCR: There is also: https://github.com/iot-dir/slides where slides about IoT stuff, and the icons and components to make new slides are welcome. [MCR: I also used Pascal's template RPL DODAG for my slides] Pascal: will do [11:25] NPDAO and unaware-leaves (Rahul) justifies the value 195. Aligns with 8505 and unaware-leaves. Only change in the draft. [11:28] Updates on AP-ND and 6BBR, state of cluster C310 (Pascal) Pascal informs of notion of clusters at RFC Editor, and the dependencies between drafts in the queue. Rahul: how is core-stateless dependant on unaware-leaves? Pascal: minimal-security and architecture depend on it. [11:34] draft-ietf-roll-capabilities / draft-ietf-roll-mopex (Rahul) explains the rationale behind capabilities, and allocation of instances. mopex: no design change, just forked into separate document. discusses backward compatibility issues, and proposed interpretation of msb of option value. Pascal: yes. Very important. This is a cornerstone for what it is to be RPLv2. Pascal: ignore the option or ignore the DIO altogether? Rahul: get that topic into ML. Back to capabilities draft. - Section added to explain difference between capabilities, Config option and Routing Metrics/Constraints. - G flag to mean Global, capability must be copied down unchanged through 6LRs. - binary capabilities grouped into a bitfield, called Capability Indicators. Dominique: anticipated to use it with Length!=3? MCR: align the bits to the right, or better to the left? Rahul: either, would need to think about it. MCR: bunch them into bytes, and extend bytes to the right? we could ask IANA to help crafting this. Rahul: new capability - routing resource capability (useful for P-DAO?), should we use the same approach for neighbor chache? if we do it, should we put it into the same capability or a separate one? bring question to ML. 11:55] draft-ietf-roll-nsa-extension Aris-Remous changed DMC to be metric instead of constraint. highlights that this metric is not taken into account when computing rank. Dominique: do we need a hook to allow future compression? Aris: we did implement compression in early work. example provided by 6loRH, we used for parent set address. But after discussion with Pascal it would be good to have compression for all the control packets, more general approach instead of special solution. Typically same compression level for all addressed in the set. Can tell by size if 6loRH compression is used. Dominique: We could use capabilities to understand which nodes are able to understand the compress form. Then, the question which messages use the compressed form, which do not. Aris: The compressor decide. If you would like to do piece-meal compression, some parts compressed and some not, maybe a field should be added. not sure. Rahul: general compression is really needed, for example TIO. This message is DIO, multicast. Compression is a must. MCR: used GHC to compress DIO messages. Would compress any IPv6 address in any option, avoid ad-hoc solutions. Suggest creating a RPL-level compressor, to be negociated as a capability. Aris: agreed. Would also compress Target Address option, especially beneficial when same address is present in both. Pascal: does it mean GHC MUST be present in every RPLv2 node? Pascal: in dao projection, not use of full IPv6 addresses. DAO projection would do same. Pascal: default model should be 8138, until we have GHC. Pascal: options can be elided. This is also a form of compression. Pascal: some options may have to be made mandatory, so that they are never elided. Dominique: conclusion is that we don't need specific signalling to allow future compression. Aris: so next steps? WGLC? Dominique: OK, didn't hear any objections. Dominique: Will post a WGLC on the mailing list. [12:09] RPL observations (Rahul) explains issue of DAO-ACK. Proposal is to use TIO to have the BR send a DAO-ACK directly to the originating node, even in storingmode. Pascal: maybe this message does not need to be called DAO-ACK. DAO's can be aggregated on the way up. Pascal: first DAO indicates new reachable node. For periodic refresh, no latency issue, as long as within lifetime. Rahul: agree, very important. The first DAO should be responded with this message. Rahul: agree we should not be calling it DAO-ACK. This asynchronous message could be used for other purposes, too. This is the first time, in storing mode, that we have a direct message from the root to a node down the graph. Only change is setting of the K flag, saying that acknowledgement is sought. Rabi: when a node switches parent, needs the reachability information? Rahul: if parent switches parent, will send aggregated DAO without K flag. Pascal: I am concerned about piggybacking this information in the DAO. Maybe the First DAO is copied as received all the way up. But normally, DAO can be completely regenerated by the intermediate nodes. it doesnt have to be stored and forwarded, meaning, should we store this K flag and should we put it in every copy that we sent up until we get a DAO from below? Rahul: K flag similar to E flag in terms of behavior. Intermediate node has to remember that E flag is set, on behalf of other node. Pascal: E does not change over time, is a physical property of a node. Should intermediate node store K? Pascal: root response could be different on first node appearance. MCR: kind of a RPL ping. Seems that's what we want. Pascal: need to take care that the RPL ping does not pass the DAO, otherwise root does not know what to do. Hence the piggybacking. MCR: this initial exchange is opportunity to do capabilities exchange. Then, refresh knowledge of parents. Ines: running out of time. Good discussion. To be brought to the mailing list. Rahul: this draft not to be published, how to handle the proposals? errata? Ines: will discuss on the ML and at the interim meeting in May [MCR: really good idea. Is there a date?] Doodle to go out within the next hours/days. [12:28] draft-papadopoulos-roll-dis-mods-use-cases (Georgios) Describes 3 uses cases that prompt for modifications in DIS message. - new node joining established network - identifying defunct DODAG - probing adjacencies Shows preliminary simulation results for use case #1. Shows benefits of proposed solutions of dis-modifications Pascal: another use-case is power down, then power-up and electrical smart meters can back up again,. On a power-up, you would want multicast DIOs to save on individual transmission. Dominique: will take this use case into account. [12:43] draft-ietf-roll-enrollment-priority Michael goes through "animated" slides. Node 32 can accept more pledges, sends 0x7f as a priority. Node 24 does not know option, deletes it. Node 35, not seing the option, assumes half-way value of 0x40. Ines: we need reviews. Please volunteer! [12:49] draft-thubert-roll-eliding-dio-information (Pascal) witness that more and more configuration information appearing in RPL. Good because allows autonomous behavior. But inflates DIOs. Per 6550, DIO options are "optional to send", allows to save on DIO size. But what if node misses important option? How to make sure ithas the latest update? How can it probe for last update? (DIS modification) Not worked on this draft since IETF106 meeting. Left on the backburner. Work to be resumed. Probably should be part of cluster of "RPLv2" RFCs. Proposal: DIO sequence number. - DIO message can be split in multiple messages, still with same sequence number to tell they real form a single one. - can check freshness of last received value. Introduces an new option, the option of Abbreviated Option (AOO). Sequence number can also be used to detect that root has rebooted, e.g., through lollipop. Georgios: merge with dis-modifications. MCR: let this "coast" for a bit, so that we can push the other documents and get experience. MCR: getting close to writing 6550. [13:04] AOB Ines: need for a work meeting in May? Dominique: yes. --------------------------Jabber relevant chat information ------------------------------------ (2:19:05 PM) mcr: really awesome slides. These will be very useful for future people. (2:19:14 PM) ines: yep (2:20:40 PM) aretana: I wonder how these could look in SVG so we can include them in the draft.. ;-) A slightly simpler version, of course. (2:22:04 PM) mcr: well, we'd get no colour. (2:22:09 PM) mcr: (and no u in colour) (2:22:56 PM) mcr: and not even grayscale, so we can't put one thing on another, transparently. (2:23:19 PM) mcr: but, there could be a version that probably worked. (2:23:27 PM) aretana: No, but it would be a lot more useful than figuring it all out as you read the descriptions…and hoping you got it right. (2:23:33 PM) mcr: I agree. (2:44:12 PM) mcr: I guess we need to number these bits from left to right? (3:04:43 PM) ines: rfc 7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (3:05:04 PM) mcr: brb. 2min. (3:06:32 PM) ines: ok (3:21:56 PM) mcr: (8am crontab loads funny pages) (3:27:10 PM) mcr: proposal: virtual interim for observations draft only. (3:27:35 PM) mcr: we clearly need to get some of the other items out of observations into errata or updates. (15:13:44) mcr: okay, we really need to think about rechartering soon for RFC6550bis. We need to start thinking about this soon, even if it might take some time to figure out what is in and what is out. (15:14:17) mcr: Internet Standard step or cycle at Proposed Standard... (15:14:55) mcr: yeah, let's not call it the DAOACK. RootACK. (15:15:07) ines: charter contains that in oct sept we should take that in consideration ----------------------------------------------------------------------------------------------