## THIS IS A DRAFT!!! ## # Minutes, 20 February 2015 interim, 6TiSCH WG # Note: timestamps in PST. Connection details ------------------ * Webex: https://cisco.webex.com/ciscosales/j.php?MTID=m52db5e679e5629fc43265c638d55546c * Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true * Topic: 6TiSCH Bi-Weekly * Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) * Meeting Number: 206 802 913 * Meeting Password: sixtus * CCM: +14085256800x206802913 Resources --------- * Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=d6e67b5ca8944585a16db89dc230de8f * Wiki: https://bitbucket.org/6tisch/meetings/wiki/150220_webex * Slides: https://bitbucket.org/6tisch/meetings/src/master/150220_webex/slides_150220_webex.ppt Taking notes _(using Etherpad)_ ------------------------------- 1. Thomas Watteyne 1. Xavi Vilajosana 1. Pascal Thubert Present _(alphabetically)_ -------------------------- 1. Thomas Watteyne 1. Pascal Thubert 1. Robert Cragie 1. Chonggang Wang 1. Elvis Vogli 1. Giuseppe Piro 1. Guillaume Gaillard 1. Maria Rita Palattella 1. Michael Richardson (10:30) 1. Pat Kinney 1. Pouria Zand 1. Qin Wang 1. Shwetha Bhandari 1. Xavi Vilajosana 1. Zhuo Chen 1. Elvis VogliAction Items ------------ Agenda ------ * Approval * Agenda * Minutes last call * Updates since last call * summary of roll interim call [20min] * consequences on plugtest/ decisions [20min] * architecture draft last call [10min] * AOB 16:04 Meeting starts * Last call minutes are approved. * Agenda bashing - Changes on the agenda are proposed. Robert will be the first to present. - Roll interim meeting happened the 10th of Feb. - Robert accepted to present his proposal for mesh header. * Robert presents the ZigbeeIP compression mechanisms * IP in IP in Zigbee * Ip in Ip is used in many places including rfc6553,6554 to carry RPI header * Robert explains how they addressed IP in IP encapsulation in Zigbee IP * Pascal: Ip in IP specified by a NHC -Section 4.2 of rfc6282 * RH3 and RPI are completely uncompressed. * Proposal from Robert to resolve conflicts in using the 0x01 dispatch * 3 approaches: take approach where they consider the most likely use case for the mesh header and try to avoid conflict with that. * ensure that dispatch code 0b1011 is not used in existing standards. With 6LoRH this dispatch code represents the elective format with length 16 to 31. so this is limiting the length of the option to be smaller that 16B * The only extension (elective format) is used is IP-in-IP 6LoRH but it is unlikely to be larger than 16 Bytes * Thomas: This means a change in 6LoRH spec * Pascal: Yes because this is setting a bit that is right now in the length and setting it will cause the length to be misinterpreted * Robert propose to use an extension header but they reduce the capacity of the 6LoRH length by 2 bits. * Pat Kinney: supports Robert's proposal as similar to start using reserved bits * There are no objections on the call. * Back to agenda. Completing the bashing * Next IETF meeting. Chairs Requested for 2 slots. One slot is for regular 6tisch meeting another is to discuss about non-chartered items such as Detnet and OTF * Will use IETF site instead of bitbucket. o issues raised on this topic. * ROLL Interim * Correct link to http://www.ietf.org/proceedings/interim/2015/02/10/roll/proceedings.html * discussion was about the problem of IP in IP and how compression of RH3 and RPI can be addressed * Robert hinted a variation based on what is done at zigbee IP. Basically they compress the IP in IP. * It is not optimized as proposed in 6lo drafts. * Roberts presentation is following rfc6282. There is not a draft with a summary of that compression technique done by ip in ip compression. Not clear position to take for the Plugtest. * 4944 used 1/3 of the 6lowpan space for 1 mesh header. * It is difficult to get consensus. We do not have an answer immediately. BY the end of the IETF meeting we might have an answer. ROLL needs to explicit which encapsulation happens where. * ETSI plugtest - Pascal: many things to test, security, synchronization, RPL, 6top interface via COMI, data packets conformance - Thomas: it would be too aggressive to do 6top interface. - coap is required - full 6top interface required. - it is a significant amount of work - Pascal: we can make that a stretch goal, but the right IP in IP formats should not be - Michael: We need to be conservative in what we send, be liberal in what we accept - Pascal IF Ip in Ip is not done correctly, It might be better to leave it as is and focus on other specs of 6tisch. Ip in Ip is an overhead that do not proof concepts on the 6tisch wg, and formats with unlawful insertions are still valid format, no coed to throw away. * Between the 1st plugtest and the 2nd plugtest there might be a solution for the Ip in IP encapsulation. * Thomas: My order would be - sync without security - then RPL operation -Do not compress anything (nor using flow label, rh3 and rpi not compressed) - No IP in IP * ETSI Call for experts - write the test cases - deadline today 20th Feb - Unicast mail to thomas watteyne to know more about it * Review of architecture draft * 14 publish * 4 publish with edits * Thomas suggests to copy the issues to the datatracker * 17:12 - AOB - no other B. * 17:12 - meeting ends.