Minutes for 6TISCH at IETF-93
minutes-93-6tisch-1

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at IETF-93
State Active
Other versions plain text
Last updated 2015-07-30

Meeting Minutes
minutes-93-6tisch

   ## THIS IS A DRAFT!!! ##

# Minutes, 21 July 2015 main, 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: 13:00 CET, 4:AM Pacific Daylight Time (San Francisco, GMT-07:00)

Resources
---------

* Webex recording: TODO
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/150721_ietf93_prague.md
* Slides:
https://bitbucket.org/6tisch/meetings/src/master/150721_ietf93_prague/slides_150721_ietf93_prague.ppt
* Prez skeleton:
https://bitbucket.org/6tisch/meetings/src/master/150721_ietf93_prague/ietf93_template.ppt

Chairs Summary
----------------

6TiSCH met on Tuesday afternoon for 2 hours with a packed agenda and a pretty
full room, Brian and Ralph attending. Highlight:

   - Ralph’s review of the architecture indicated that the document mixed
   architecture and specification level aspects, while not covering all the
   architecture items in 6TiSCH scope. The discussion led to a proposal that
   the WG takes back the doc till the architecture is complete, which is
   probably the lifetime of the WG. The doc would go still down to what Ralph
   describes as a specification level, but would include security, dynamic
   schedule and DetNet application. This will be confirmed on the ML

   - The first 6TiSCH Plugtest was a huge success that validated the 6TiSCH
   minimal draft. Some changes were proposed and supported at the WG, namely
   suppression of a reference to the architecture in the security section, the
   MUST for non-storing mode RPL and the computation of the step of Rank by
   RPL. Other changes were more discussed like the way issues in 802.15.4e are
   avoided, and the MUST for storing mode RPL. All will be confirmed on the ML.
   Brian confirmed that the dissector outputs that were used for the plugtest
   could be placed in annex in the document if the WG thinks it appropriate.
   The draft will be pushed for IESG review as soon as the issues above are
   resolved.

   - The Interface and CoAP drafts progressed but are blocked by the normative
   reference to COMI and potentially CoOL. With this in mind, the WG cannot
   complete that work and must hold it. In the meantime, implementers were
   asked to provide feedback on the document from their implementation
   experience.

   - Non chartered work was presented on dynamic scheduling, use of CoAP for
   MAC level signaling and DetNet. Discussion started at the mike and are now
   continuing on suggesting to use 802.15.9 as the transport for CoAP, mostly
   due to the limited naming space in IEs.

   - It results that the group is ready to take new work in. The work is mostly
   identified and relates to dynamic scheduling, security and interface with
   DetNet, under the general umbrella of the architecture documents.
   Re-chartering discussions should start soon.

%====================================== START RAW MUNITES
======================================

TODO: publish pcap
suggestion from Carsten: define a Content-type (?) for 6TiSCH

Planned agenda
[13.00]
Intro and Status                                  [5min] (Chairs)
   * Note-Well, Blue Sheets, Scribes, Agenda Bashing
   * Drafts progression vs. plan

[13.05]
6TiSCH Plugtests report                          [15min]
  * Organization report                                  (Miguel Angel Reina
  Ortega) * Tools:
      *             (Dominique Barthel)
      * Golden Device                                    (Tengfei Chang)
  * Summary test cases, anonymized success highlights    (Maria Rita Palattella)
  * Lesson learned                                       (Thomas Watteyne)

[13.20]
Hackathon report                                  [5min] (Maria Rita Palattella)

[13.25]
               [15min]
  * INT-DIR review and resolutions                       (Pascal Thubert)

[13.40]
                   [30min]
  * RPL artifacts and 6LoRH at 6lo                       (Gabriel Montenegro, 
  5min) * Example format and security section                  (Xavi
  Vilajosana,    20min) * Shepherd status and IESG submission                 
  (Pascal Thubert,      5min)

[14.10]
            [10min]
  * Update on changes                                    (Qin Wang, Xavi
  Vilajosana alt.) * Readiness assessment                                 (all)

[14.20]
CoMI News                                        [15min]
  *  and
     in 6TiSCH context   (Peter van der Stok, 10min)
  * Michel's Proposal to avoid hash collisions           (Michel Veillette,   
  5min)

[14.35]
Distributed scheduling                           [10min]
  *                  (Diego Dujovne)
  *                    (Qin Wang)

[14.45]
DetNet and dependencies                          [10min]
  * BoF news                                             (Lou Berger)
  *                (Chonggang Wang)
  *                     (Pascal Thubert)

[14.55]
Re-chartering kickstart and AOB (chairs)          [5min]

------- Meeting Notes -------

[13.00]
Intro and Status                                  [5min] (Chairs)
   * Note-Well, Blue Sheets, Scribes, Agenda Bashing
     - Pascal goes through agenda
   * Drafts progression vs. plan
     - "minimal" draft passed Plugtest, deemed ready for shipment
     - "architecture" just returned from IESG review, needs rework.
     - "coap ie" and "6top interface" need to move forward
Comments on the agenda ? none.
Agenda is approved.

[13.06]
6TiSCH Plugtests report                          [15min]
  * Organization report                                  (Miguel Angel Reina
  Ortega)
    - organised by ETSI and 6Tisch, support from OpenMote.
    - 4 independent implementations. 23 test sessions plus single hop and
    multi-hop - Plugtest agenda over 2 days.
   - Sunday hackaton
    - Test plan: 6Tisch minimal, over 15.4 radios. 6LoWPAN, RPL, ICMPv6.
 - golden hardware/software provided to participants ahead of time, allowed
 them to do pre-testing at home.
       - used wireshark dissector for debugging
    - Miguel shows list of 18 tests.
    - 93.7% success rate on tests that were executed.
    - not so good on RPL because not implemented the same by all (storing only,
    non-storing only). - Thomas: "minimal" should have a MUST for at least one
    of the modes, otherwise not interoperable! - Thomas: opnions?
     - Xavi: RPL is a MUST
     - Pascal: Is it a problem of code space?
     - Xavi: It is a problem of the table size in the mote. Code size of having
     both modes not a problem. - Michael: what was the interop issue? Thomas:
     were DAG roots that only did storing modes and nodes only non-storing, or
     vice-versa, hence could not interoperate. - Randy Minimal does not specify
     a plugtest procedure for RPL - Tero: 6550 has to support both? Pascal:
     Leaves it open. Tero: then pb with 6550? - Pascal: There are many
     implementations. storing and non-storing are part of the many parameters
     to define - Tero: You must implement both but used according to the
     profile. - Oleg Ham: 6550 says either mode, would "minimal" contradict
     6550 if says MUST to both? - Pascal: RPL is general, but here we need to
     specify a minimal implementation. - Robert Cragie: if sotring mode is a
     MUST, then pb for modes that have little RAM, especially close to  the
     root.
    - Miguel: future plugtest roadmap presented: 2-4 Feb 2016 (Paris) and July
    2016 (IETF Berlin) [tentative] - Michael R: make public the dates at which
    the Plugtest dates will be made public (!) - Miguel: We are going to start
    planning starting next week to confirm the dates.
  * Tools:
      *             (Dominique Barthel)
      - New draft. Wireshark dissector output examples
      - Jonathan Munoz updated the 15.4 Wireshark dissector to dissect 15.4e
      TSCH amendments needed for 6TiSCH. Not the full 15.4e. - ran OpenWSN
      implementation 6tisch-minimal, simple 3 node linear topology and simple
      scenario. Copy-pasted the results from Wireshark when running the code. -
      Simple examples - WIP - Is this useful? Should it be published? *
      Michael: Would like to be able to get the PCAP files, not just the text
      output of Wireshark. * Dominique: will do * Robert Cragie: has the
      dissector been pushed back to the Wireshark site? * Dominique: not yet,
      will do. Already publically available, though, right now, on the 6TiSCH
      bitbucket. * Brian Haberman: RFC or living document? Other examples as
      wikipage. Move it to a wiki, it's minimum overhead. * Pascal: To the
      annex of minimal? * ..?:Requirements, use cases, frame examples: end of
      protocol specification * DR Raza: Other implementations available? *
      Thomas: OpenWSN is open source. Per ETIS rules, we cannot publish the
      name of the entreprises or implementation. * Golden Device               
                          (Tengfei Chang)
  * Summary test cases, anonymized success highlights    (Maria Rita Palattella)
  * Lesson learned                                       (Thomas Watteyne)

[hh:mm]
Hackathon report                                  [5min] (Maria Rita Palattella)

[13:32]
               [15min]
  * INT-DIR review and resolutions                       (Pascal Thubert)
  * Pascal: Provided a document with different levels of understanding. Not
  same depth.
This document does not cover completely 6tisch. We will use volumes, e.g.
dynamic scheuling, detnet in the context of 6tisch for the IESG review.
  * Because currently does not fill the expectation of the reader which is a
  global architecture, so shall we restructure it? * Show minimal implemented.
  Show this could be done. Pick different items from different groups and see
  if they fit and if there is anything else missing. * Brian Haberman:
  Architectures: you never know if it is going to change. This document can be
  used to implement 6tisch now. It was written in small pieces. * Ralph Droms:
  Refer to Brian, agree with him on supporting implementation. This document
  should be a wikipage but not for publication. * Integrating with detnet and
  references to components/blocks in detnet. The expectation on the components
  to know which go here and which go to detnet * Thomas (co-chair): One way
  could be to make a simple document with high level architecture only *
  Pascal: The architecture should represent what is being developed. Wanted to
  describe way to use RPL and 6LoWPAN together. * Ralph: putting together
  protocols is a spec document, not an arch document. Needs to be consistent
  through the document as to what is is. * Ralph: arch describes boxes and
  interfaces, not necessarily sepcifying what's inside or parameters. The later
  belongs to spec document. * Brian: one way of doing this is wait until all
  building blocks documented, document is architecture document. But right now,
  there are TBDs and future work. * Pascal: to summarize, reopen the document,
  keep it active until all pieces are done. * Ralph: arch part should be
  understandable by somebody that does not know RPL, but knows waht a routing
  protocol is. * Thomas: Shall we hum? * Pascal: Humm. People who think we
  should reopen the doc, keep it active in the WG and ship after WG work is
  complete. * Pascal: humm for keeping pushing it through the IESG? none head *
  Pascal: humm for dropping the doc altogether? none heard * Pascal: so we take
  the doc back * Qin Wang in Jabber room: some elements not on the charter. *
  Pascal: We cannot finish this document unless we charter the documents not
  chartered yet. * Brian: you guys confirm consensus on mailing list. If yes, I
  will send the doc back to you. * Pascal: Come to 6lo to help solve RPL issues.

[13:52]
                   [30min]
  Actually version -11
  * Example format and security section                  (Xavi Vilajosana,   
  20min) different interpretations of 15.4e fields, had to agree before
  Plugtest. define key for interoperability tests * Subir Das: last line in
  Security section refers to 6TiSCH arch doc, needs editing * Subir: what doc
  to refer to regarding security * Brian: So... you can t live with crossed
  references. Put security in this document or build another security document
  * Subir: We can live with the phrase saying it is out of scope * DR Raza:
  Agree to drop the sentence. It can be understood without the reference. *
  Brian: agree to drop the sentence. * Pascal: humm if opposed to dropping this
  snetence?none heard. Will confirm on mailing list. * Malisa: add that
  implementation MUST have security implemented. * Xavi resume presentation.
  RPL OF0. Rank computation. * Pascal: typo in the slides. Proposal is actually
  3*ETX-2. * Pascal explains: a good link is ETX=1; With 2*ETX, can't have step
  rank of 1. Humm if disagree? none heard. * Tero: (one slide back to specific
  802.15.4 headers) Table 2 is wrong, features don' t work in 15.4. You cannot
  have two PANIDs with the new version. * Propose that PANID should be 1. *
  Pascal: with -2011, we know it's broken. * Tero: no, in -2011 was OK  two
  PANIDs worked. * Tero: 15.4e-2012 got it wrong. * Thomas: what do you
  recommend? * Tero: ???? * Pascal: technology works. But this doc refers
  broken specs. * Tero: why compressed PANID O? What's the use? * Thomas: We
  are talking about 1 bit in a header, what is the meaning of that bit. * Tero:
  Wireshark will parse frame, won't be able to parse this because this bit
  wrong. * Subir Das: Why don' t just accept the mechanism. This draft should
  recommend this. let the text go through and add the reference when the IEEE
  standard is finished (november) * Raza: for the "last sentence", cite
  802.15.9 that does key management for .... * Pascal: please Subir propose
  your idea on the mailing list, and will confirm. Then ship. * RPL artifacts
  and 6LoRH at 6lo                       (Gabriel Montenegro,  5min) * Shepherd
  status and IESG submission                  (Pascal Thubert,      5min)

[hh:mm]
            [10min]
  * presented by Xavi on behalf of Qin

  * Update on changes                                    (Qin Wang, Xavi
  Vilajosana alt.)
   in Yang model, modified the SecurityAttributes. Comments received from M
   Richardson. minor changes, grouping of attributes.
  * remove commands section
  * Check if YANG model to cover attributes (read/write)
  * Use the format to negotiate for distributed scheduling
  * Randy: Did you say one PIB or any PIB?

  * Readiness assessment                                 (all)
  will come back to this after COMI's presentation

[14:17]
CoMI News (work done at Core, presented for information here)   [15min]
  *  and
  * Peter: Issues being discussed on the ML.
  * Small services and small clients. All the items taken into account,
  including hashes. * Discussion points: name hashing and patch content format.
  * Hash clash probability very low, but incrementing with the number of names
  * Reduce impact of rehash handling; client will only know of a hash clash
  when it uses that hash. * assumption that no clash within module. * server
  will provide info on modules involved in the clash; suggest some servers are
  managed, have fixed names, others unmanaged, only have hashes.
     in 6TiSCH context   (Peter van der Stok, 10min)
  * Add a PATCH command to CoAP.
  * patch format 1: use CBOR or JSON format, but need additional rules to do it.
  * Carsten: Microoptimization. you need measurements. is it possible to get a
  prediction? * Thomas: yes. Some elements can be accessed with less cost
  depending on the access frequency. * Implementers provide feedback. * Peter:
  if more rules, put in Comi document or -patch? * Thomas: This must be
  discusseed in CoRE * Peter: CoRE tells how to send a patch, there are
  existing media types or creating your own. * Michel's Proposal to avoid hash
  collisions           (Michel Veillette,    5min)
COnstrained Objects Language (COOL)

  * could be used beyond management.
  * avoid hash clashes by using managed numbers.
  * A hash clash might results in acting upon an unwanted resource.
  * The client must know the notification source
  * Dynamic loading of a new module may create hash clash.
  * Comi clients need to store large tables.
  * Pascal: Constrained devices. what if don't have space for this. The tables
  use memory. * Michel: Unmanaged vs. Managed. There is no solution for the
  memory problem. * Proposal is 20 bits registered module IP, and 10 bits
  assigned YANG ID. * Modules registered in IANA, leave 3/4 of space reserved
  for future use. * Goes through a GET example. * Support Patch, stream based
  on RFC5277, resource discovery, etc..

  * TW: is cool and optimization of COMI? Will you update COMI with the ideas
  in CooL? * Peter VDS: we did not see a.. * Thomas: we need a flexible
  solution. * PT: Make clear what is a must and what is not. In terms of using
  clash vs IDs * Peter: might be useful to have packet sizes, payload sizes
  etc... How to choose and asses on the choice.

[14:40]
Distributed scheduling                           [10min]
  *                  (Diego Dujovne)
OTF  Update.
  * new version 06
  * distributed scheduling
  * event triggered and parametrized allocating policy. Accessing to it through
  CoAP * When to trigger the allocation and the number of requests that it will
  do to allocate the cells. This is fundamental in terms of performance and
  energy consumption * 2 associated bundles: only on the outgoing bundle.
  Reservations are only performed in the outgoing bundle. * 6top will negotiate
  the cells with the corresponding neighbors. * Default algorithm defined. * if
  incoming cells > outgoing cells then the mechanism triggers a reservation
  of some cells. In the opposite case it removes cells. There is a threshold to
  avoid churn. * Next steps: * How to deal with l2 tracks? Not only the best
  effort track * uses shared soft cellls between nodes.

  * Thomas: any implementation of this (next plugtest in mind)? Diego: soon in
  OpenSWN. Hopefully for Berlin.

  *                    (Qin Wang)
  * Thomas presents on Qin's behalf.
  * fixed CoAP IE to be paylod IE.T
  * Tero: only 16 payload IEs, already 4 allocated. <<>>
  * Tero: will send pointer
  * Thomas: Do we publish the interface now or shall we wait for CoMi to
  provide feedback? * We have a dependency here. * Pascal: We need a normative
  reference. * Peter VDS: use of RPC. Recommend to wait till Yokohama.

[14.51]
DetNet and dependencies on 6TiSCH                         [10min]
  * BoF news                                             (Lou Berger)
  * Lou Berger: prep work done here, BOF well attended, polling resulted in
  lots thinking good stsuff, half willing to do work. * expect good
  collaboration between the groups.

  * Randy: Asks for the BOF  slides. said wired nework? Pascal: Detnet, not
  here, won't comment. * Pascal: Nothing is casted in stone

  *                (Chonggang Wang)
  * updates: track and Detnet. Work on track is 6Tisch could be beneficial to
  Detnet.
           path redundancy.
           metrics for industry networks: RFC 5673 from ROLL.
  * Thomas: please WG read and comment on mailing list.
  *                     (Pascal Thubert)
  * Pascal: 6tisch view of what we need from detnet. Core question is "what is
  a track".

[14.58]
  * Re-chartering kickstart and AOB (chairs)          [5min]
  * Out of time.
  * Conclusions
1) <<>>
2)interface delayed until COMI is finished.
3) rechartering. AD comment? Brian: makes sense.