Agenda and Meeting information Meeting : IETF94 Thursday, November 5, 2015 (JST)
Time : 15:20-17:20 JST Thursday Afternoon session II (2h) Location : Room 303, Pacifico Yokohama, Yokohama, Japan Chairs : Pascal Thubert <[email protected]> Thomas Watteyne <[email protected]> Responsible AD : Brian Haberman URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch Intro and Status [5min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing New Charter [25min] (Chairs) * Status Document * New Charter * Milestones * Action Plan Dynamic Scheduling * <draft-wang-6tisch-6top-sublayer-03> [20min] (Xavi Vilajosana) * <draft-dujovne-6tisch-6top-sf0-00> [20min] (Maria Rita Palattella) Tracks in 6TiSCH * <draft-thubert-6tisch-4detnet-01> [20min] (Pascal Thubert) Any Other Business * Announcement second ETSI 6TiSCH Plugtests [10min] (Miguel Angel Reina Ortega) Resources * agenda: https://www.ietf.org/proceedings/94/agenda/agenda-94-6tisch * presented slides: https://www.ietf.org/proceedings/94/slides/slides-94-6tisch-0.pdf * Meetecho recording (audio+video): http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_6TISCH&chapter=chapter_1 * Jabber log: http://www.ietf.org/jabber/logs/6tisch/2015-11-05.html Summary [This summary is transmitted to the INT area ADs] The 2-hour 6TiSCH meeting focused mainly on 3 elements: - rechartering. This has been discussed during 2 interim meetings, and the text presented at the WG meeting summarized the conclusions from those discussions. The proposed new charter builds upon the old charter, and introduces dynamic scheduling of cells. Several constructive remarks were made about the presentation of the different work items; the chairs took as action items to integrate those in proposed charter text, and to transmit it to the IESG. - the main technical part of the meeting was dedicated to the draft-wang-6tisch-6top-sublayer-03 and draft-dujovne-6tisch-6top-sf0-00 drafts (both of which are complementary). No major issues were raised about these draft, but the WG asked a number of clarifying technical questions and make some smal suggestions the authors agreed to integrate. - a presentation of draft-thubert-6tisch-4detnet-01, which links the work done at 6TiSCH with the work done at DetNet. The chairs asked for more feedback on the document on the mailing. A number of other points were raised: - draft-ietf-6tisch-minimal-12 was transmitted to the IESG a couple of weeks before the IETF94 meeting. Three constructive reviews were sent back to the WG. To advance the work on the draft, and in the interest of time, the reviews are discussed on the ML. We had a discussion on the status of the draft (currently Proposed Standard), which we will conclude on the ML. - We announced the second 6TiSCH plugtests event to be held on 2-4 February 2016 in Paris, France, organized by ETSI and hosted by Inria. - We had an announcement about a Study Group created at the IEEE around defining an LLC which could include work from the 6TiSCH and 6lo WGs, as well as a KMP and L2R routing protocol. We agreed to continue the IETF/IEEE liaison around that aspect. The same announcement was made in the 6lo and ROLL WGs, with a longer presentation at the INT Area session. The full minutes, the detailed action items and the presented slides are published in the IETF material manager. The meeting was recorded through Meetecho, and the recording (audio+video) is available. Action items * Chairs to rework the charter text: * use bullet list, not numbered list * put a statement which explains that the architecture follows the progress of the standardization, and will not be delivered first * reorder items? * rework text around what can be done at the IEEE * Chairs to finalize discussion about status of 6tisch-minimal on ML * Authors of draft-wang-6tisch-6top-sublayer to take into account the following remarks: * The child should be able to ask for a number of cell without specifying a cells in the CellList, so that the parent can choose from a chunk it has set aside for that node. * would it make sense to have a transaction identifier in 6P? * Chairs to coordinate with IEEE/IETF liaison group to request an IETF Information Element Payload Group ID to the IEEE. Volunteers * Scribes * Dominique Barthel * Alexander Pelov * Jabber * Robert Cragie Minutes * [15.22] Meeting starts * ~45+25 participants (local/remote) * [15.22] Intro and Status (Thomas Watteyne) * Thomas presents Note Well slide * Shows agenda and queries for comments: none. Agenda is approved. * [15.24] New Charter (Pascal Thubert) * New charter text discussed at last IETF and at a several latest interim calls * First generation of charter limited to static schedule * Now proposing capability to negotiate schedule between nodes * Milestones: 6TiSCH architecture not delivered in time, postponed until other work done to publish only one volume or architecture. Work in progress. New content will come with dynamic scheduling work. CoAP data model and information model publication postponed until CoMI is delivered. * New charter has 3 new work items: * dynamic scheduling on top of 6top * secure bootstrapping: a lot of work done on the mailing list already although not in first charter. * track definition and DetNet requirements. Be able to tell DetNet what 6TiSCH provides. * New charter text shown, in final discussion * Requests to work on track definition and mechanism. Planned for 3rd gen charter. * Current non milestones work items: Test Description for next ETSI 6TiSCH plugtest. * [Brian Haberman] is order in list on screen order of doing work? Architecture first? * [Pascal Thubert] on-going work on architecture. Only published after other work done. * [Brian Haberman] numbered list looks like ordered list. It is important to note that the architecture is a work in progress that will be updated as the time goes by. Some people wait for a document to be published, before they start reading it. Making it explicit may help some people understand and read it before. * [Pascal Thubert] we will remove the numbers, place bullets and rewrite that architecture will be continuously worked on and not delivered. Action item: Chairs to rework the charter text. * [Brian Haberman] Test Description looks like compliance testing. * [Thomas Watteyne] This text just reflects what we have been doing in first 6TiSCH plugtest. * [Pascal Thubert] requirements to be able to play the interop game. Otherwise, implementations could have nothing in common. * [Brian Haberman] intention to publish into RFC? * [Thomas Watteyne] no * [Chonggang Wang] The IoT router in bullet 3 is not defined * [Pascal Thubert] Need to check the exact definition * [Pascal Thubert] for this charter, rely on fact that IP packets have IP addresses. In the future, may be able to tag. You're welcome to do work in advance on something non-chartered. Right now, we're committed to deliver the deliverables in the charter. Architecture give the overall view, but not everything on current charter. * [Subir Das] bullet #2: what is going to be done here and what at IEEE? * [Pascal Thubert] right now, 6top not in IEEE. We'll see in the future. * [Subir Das] would be good to clarify what exactly could be done in the IEEE in the charter. Action item: Chairs to rework text around what can be done at the IEEE. * [Thomas Watteyne] we had a liaison meeting with IEEE to discuss that, will continue the collaboration. * [Samita Chakrabarti] The 6TiSCH architecture will be running on 6LoWPAN. 6lo WG would like to have the reviews done as well. * [Pascal Thubert] Agreed and positive on this. It is on a case-by-case basis. Let's continue working on this together. * [Pascal Thubert] personal opinion that a lot of this will work on a lot of PHYs. * discussion 6tisch-minimal reviews (Thomas Watteyne) * [Thomas Watteyne] (6tisch-minimal): not a proposed standard draft. Brian and Suresh questioned this choice during their review of the doc. * [Brian Haberman] It seems that they are exploring different ways to do a minimal 6tisch deployment. * [Thomas Watteyne] We are not planning to replace it but to enhance it. * [Tero Kivinen] should get rid of ... Says for interop testing. Can't be a standard. * [Brian Haberman] Should be a BCP, gets the same level of review. * [Thomas Watteyne] Agreed. * [Tero Kivinen] Can the minimal setup change? Maybe it is better that when you create the network you set some parameters (profile)? * [Brian Haberman] if Informational document, would simplify review process. * [Tero Kivinen] There is not a single protocol element there. Only describing a set of IEEE parameter values. * [Michael Richardson] is draft-minimal not about getting enough bandwidth for RPL to run? Sounds much more than informational. * [Robert Cragie] If this is really a profile that works fine but it does not belong to IETF. * [Tero Kivinen] More of a profile than a protocol. The reviewers indicated too much text was copied from 15.4 standard. Understood that 15.4 hard to read and copying makes it easier. * [Robert Cragie] Test documents should not become RFCs. * [Thomas Watteyne] It was never the intention of the WG to publish Test Descriptions as RFCs. * [Michael Richardon] After discussion, no objection for -minimal to become BCP or informational. * [15.59] <draft-wang-6tisch-6top-sublayer-03> (Xavi Vilajosana) * Xavi presents the slides. Will focus on comments by Charles Perkins on mailing list. Main focus 6TiSCH Sublayer and 6top * Draft introduces scheduling function but no details, out of scope for this doc. * 6top sits on top of 15.4e, declares the need for Scheduling Function. * One question was about the coexistence of minimal and 6top. Recommend use higher priority for minimal. * Example of protocol exchange: container ID designates slotframe, bundle, chunk, whatever 6top wants to operate on * Suggest to define sub-IE to contain commands an response codes. * Discussion of 1 vs 2 bytes for slotoffset and channeloffset. * Operations: ADD/DELETE/LIST on cell lists. * 6P can do version checking, SFID checking, concurrent transactions, timeouts, etc. * [Pascal Thubert] on slide 31. Cells are owned by RPL parents. What if a child needs a slot, how does it go to the parent to ask for a cell? * [Xavi Vilajosana] Child can request a cell, but the pool belongs to the parent. This slide needs to describe the case where the child does the request. * [Thomas Watteyne] changes the way the messages are used. * Xavi resumes presentation. * Next steps: need agreement with IEEE to get GROUP_ID for IETF. * [Thomas Watteyne] idea is to have a GROUP_ID for IETF so that IETF can manage the sub-IDs with IANA. * [Tero Kivinen] There are only 16 GROUP_IDs; it might be interesting to use IEEE802.15.9's multiplexing where there are 65535 IDs. * [Pascal Thubert] we have an Interest Group for 6TiSCH at IEEE. We ask that interest group to help us identify how we can transport our 6top IEs. * important issues raised during review my Charles Perkins: * non-local statistics * on which cells are the 6top commands transmitted? on -minimal cells first, then as bandwidth is made available on dedicated cells, on those. * role of SF at boot. Initial behavior? * [Charles Perkins] on retry policy. Brought it up because in the past, a draft got rejected because retry left variable. * [Thomas Watteyne] either in the core of protocol and well-known to all nodes, or in the SF and can be flexible. * [Thomas Watteyne] further discussion on the mailing list * [16.23] <draft-dujovne-6tisch-6top-sf0-00> (Maria Rita Palattella) * new draft but work has been going on for a while. On-the-fly scheduling has had 6 revisions already. * 3 steps: monitor traffic per node / estimate need / determine changes to apply * estimate based on node's own traffic and children traffic to be forwarded * Threshold beyond which action is triggered to change allocation * at requesting node side, pick slot offset randomly * source node can request destination to CLEAR all cells allocated. Can ask for cells re-allocation if too low a PDR. * if destination node could not allocate requested cells, will return an error message. Source node could provide a completely different list. * memorizing cells that were refused to not request them again, or just random. * [Pascal Thubert] manage the full transaction with a sequence number? otherwise, may loose track of which request gets accepted or denied. * [Thomas Watteyne] we ruled out concurrent transactions, so should not be a problem. * [Pascal Thubert] but no retry policy * Maria Rita resumes presentation of error handling. * Todos: container field inside 6top request; examples of error handling * [16.39] <draft-thubert-6tisch-4detnet-01> (Pascal Thubert) * new work taking place in DetNet and PCE, that could be useful to 6TiSCH. Our architecture should be clarified and exposed to other groups so that they can use it as input. Describe the 6TiSCH tracks. Most text taken from architecture draft. * in DetNet, packet replication on different paths. Whether 6TiSCH wants to do that is TBD. * 6TiSCH can easily do per-link replication (copy only sent if original did not go through). Replication on different paths would be new. * We should agree in this WG what we do before we can tell other groups. * Maybe create a separate document just on tracks, extracted from architecture. * [Pascal Thubert] who read the document? (5) * [Pascal Thubert] read and speak up if you disagree. * [16.47] Announcement second ETSI 6TiSCH Plugtests (Miguel Angel Reina Ortega) * after first plugtest at Prague on draft-minimal * second plugtest for 6TiSCH will take place on 2-4 February 2016, in Paris, France, organized by ETSI and hosted by Inria. * the scope of the tests is: * start from the tests in Prague, and hence continue on draft-minimal, including multi-hop and link-layer security * add elements of the 6top Protocol * but still early enough in the process that we are open to suggestions. * same group of experts as last time. Will put together test specifications, will do tech support during plugtest and will report to EC after the event. * learned from first plugtest that most issues were discovered before the event. So will strive to issue test documents and golden device early. * website launched in the next few days. * sponsored by EC, event is free of charge. * Third 6TiSCH plugtest envisaged at IETF96 (Berlin). * [16.54] Announcement 802.15.12 work in the IEEE (Charles Perkins) * 15.LLC Interest Group voted to form Study Group that had first meeting recently. * general goal is to make 15.4 easier to use. Right now, a lot left to implementors. * should be as easy to use as 802.11 and 802.3 * interface for Key Management Protocol (KMP) and L2 routing. * 802.15 has growing awareness of 6TiSCH thanks to 6TiSCH interest group at IEEE, that reports at every meeting about 6TiSCH progress * on the todo list: dispatch code (a la Ethertype), 15.9 and 15.10 alignment with LLC, etc. * provides link to presentation on LLC on IEEE side * at January meeting: submit PAR (Project Authorization Request) and CSD (Criteria for Standard Development) * [Pascal Thubert] how is it organized? 802.15.12 will not be merged into 802.15.4 release? * [Bob Heile] (802.15 chair): 802.15.12 and 802.15.4 would have reasonably distinct content so they can be kept separated. LLC work would be delivered separately from 802.15.4 and not wrapped into 802.15.4 revisions. * [Thomas Watteyne] at 6TiSCH, we plan on just continuing our work at the current fast pace. Discussion and coordination with IEEE will happen in parallel. * [Charlie Perkins] agree that both groups want the same thing. Other "customers" also out there. 6TiSCH is a primary custimer that LLC wants to keep satisfied * [17.09] Other Business * No other business. * [17.10] Meeting ends
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
