[6tisch] Minutes, 20 February 2015 interim, 6TiSCH WG

["Pascal Thubert (pthubert)" <[e-mail]>]

Resources

*	Webex recording:
https://cisco.webex.com/ciscosales/lsr.php?RCID=d6e67b5ca8944585a16db89dc230
de8f
*	Proceedings:
http://www.ietf.org/proceedings/interim/2015/02/20/6tisch/proceedings.html

*	Slides:
http://www.ietf.org/proceedings/interim/2015/02/20/6tisch/slides/slides-inte
rim-2015-6tisch-4-0.ppt 


Taking notes (using Etherpad)


1.	Thomas Watteyne
2.	Xavi Vilajosana
3.	Diego Dujovne
4.	Pascal Thubert


Present (alphabetically)


1.	Thomas Watteyne
2.	Pascal Thubert
3.	Robert Cragie
4.	Chonggang Wang
5.	Elvis Vogli
6.	Giuseppe Piro
7.	Guillaume Gaillard
8.	Maria Rita Palattella
9.	Michael Richardson (10:30)
10.	Pat Kinney
11.	Pouria Zand
12.	Qin Wang
13.	Shwetha Bhandari
14.	Xavi Vilajosana
15.	Zhuo Chen
16.	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 
*	Then security
*	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.

Thomas and Pascal