DRAFT -- MINUTE-- ROLL IETF 93 Minutes takers: - Dominique Barthel - Diego Dujovne - Thomas Watteyne == Agenda == 1- State of: (10 minutes) Work item ROLL I-D Related I-D Open Issues 2- draft-robles-roll-useofrplinfo-00 (20 min) 3- draft-thubert-roll-dao-projection-00 (20 min) 4- Open floor (10 minute) == Minutes == [17.43] Meeting starts [17.44] 1- State of: (10 minutes) Ralph Droms : received liaison statemnts from ITU-T 15, requesting response by Friday. Applies to 6lo momre than to ROLL. Regards Dispatch ESC code. G9905 and G9905 used ESC byte with additional byte. ITU-T ask confirmation that we are not going to change specification that would prevent ... We want to create registry ..., ITU-T recognizes that registry should be created, just not done yet. xxx (liaison officer): reiterates request from ITU-T to provide response back. Requests went both to 6lo and ROLL. We want one joint response. Ralph Droms: Highlight the liason matters. see https://datatracker.ietf.org/liaison/1415 Thomas: 1415 Yes, it is identical. They are using the IETF protocols information 6lo, 6lowpan and compression. They are watching and following IETF processes, and they are concerned on the use of the headers. They created a liason to highlight their use of the header. Rationale fois.r request is that Japan and France are deploying meters, want to avoid deprecation that would conflict with their use of dispatch. Last thing we want is ITU-T creating a seaprate registry and maintain it. Proposed response is : "we wont change it, and we will collaborate". Requests feedback from the WG on this. Pascal: I agree with the text. But not the registry. Option: This exists, we would ask other groups to maitain a common registry. We would need to talk to other groups to keep the registry and distribute the identifiers by IANA. Ralph shows proposed text: From 6lo chair (and proposes also ROLL chair if this WG concurs). CC: relevant ADs. To liaison secretariate. 6lo WG reviewed the content yesterday and asked the people present to review the text and express their opinion after. We plan to send the text to the ML to obtain comments. Ralph reads the proposed text. Thomas: Agree with the text Dominique: What about "Command ID values as *already* defined in G.9903 and G.9905"? So that you don't commit to endorse any and all of ITU-T's future desire. Alex Petrescu: Two paragraphs. second one: this new registry populated. this new registry? Ralph: changes the text to "This new registry, maintainede by IANA" Alex: ITU does not maintain registry. Why IANA maitains a registry for below Layer 3? Ralph: already does for other link layers. Alex: Why there is no registry for the IPv6 header The IPv6 HC is all the information necessary to rebuild the header. Alex: Transported uncompressed is possible Jonathan Hui: already a code for transporting uncompressed header. Ralph asks for a humm Humm if support sending this liaison statement as written no to ITU-T 15: humms heard. Humm if not support : none heard. Ralph: "Clear consensus in the room to send this text to ITU-T on Friday. Will confirm on the mailing list." The chairs will post this to the ML to additional discussion Work item * ROLL I-D * Related I-D * Open Issues * [XX.XX] 2- draft-robles-roll-useofrplinfo-00 (20 min) Scenarios to analize storing and non storing mode. For RFC6553, RFC6554 on IP encapsulation. Leaf to leaf, root to leaf, leaf to root. Inès asks if any more scenario to consider. Also, for these scenarios, do we always need all of 6553, 6554 and IPIP? Thomas: Context on this: Thought it might be useful to have a draft about this. Thanks to Inès for having written it. Was put out on the mailing list. I have not received any review yet. * [18.07] 3- draft-thubert-roll-dao-projection-00 (20 min) Pascal: RPL is a protocol storing and non-storing mode. Propose a missing link between storing and non-storing mode. Specific portions would benefit from storing. Propose signalling to define routes. It is difficult to say storing or non-storing for a specific device (do I have enough memory to enable storing mode?) This draft proposes to patch some parts of the network based on the knowledge of capabilities of the nodes. The root has information for the whole DODAG. Another device can have more information such as PCE. If deterministic network (such as 6TiSCH), CPE could know ... Moving to the SDN world. From the topology on the draft, there is a step by step animation of the process. Set up a route to a segment for a particular destination target. The idea is to install a segment of a route. non-storing topology, and 46 wants to establish a segment to 56. There is a DAO, and DAGroot installs a route and sends a DAO ACK. Overall, this short-cuts the path up the DAG to the root and down to a leaf that is the normal case in non-storing mode. By adding some routing state locally in those nodes that can support it. The DAGroot improved the route by observing the traffic between two nodes (55 to 56) This a way to compress information for long lines of sensors. Segments can be added at later time, piece by piece. Michael commented on the ML about the alternate programming by the DAGRoot. (slide 40) Hybrid case of 1 ho of routing header to "jump" from one segment to another (unconnected) one. You can play with what you put on the packet and what you put on the network. Terminology discussion on the mail list. "Segment". Segment is used for loose number of hops is correct? Decided to use "projected DAO" instead. The draft defined a new mode of operation (MOP) (MOP is defined in RPL spec). Decided to just use "non-storing" MOP. The root must know what is really going on and decide the routes and optimize accordingly. Approch: Bottom to the top. This allows better route following? on the DODAG. now we have DAOs going down. Shall we use DAO-ACKs to go up the DODAG? Ines: Shall we consider this as a new mode? Ines: We have a registry already on 6550. Pascal: careful, only 3-bit registry for MOP in 6550. M Richardson (through Jabber): technically not chartered to do this work yet. Ines: Wait for comments for this draft on the ML and after decide. Thomas: I agree with Pascal, no relationship between this draft and the previous one. [18.25] 4- Open floor (10 minute) Any question? none. [18.25] Meeting ends