Minutes for 6TISCH at interim-2015-6tisch-4

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at interim-2015-6tisch-4
State Active
Other versions plain text
Last updated 2015-02-23

Meeting Minutes

## THIS IS A DRAFT!!! ##
# Minutes, 20 February 2015 interim, 6TiSCH WG #
Note: timestamps in PST.
Connection details
* Webex:
* 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

* Webex recording:
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/150220_webex * Slides:

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

* 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]

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

   * 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

   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.