Subject: [6tisch] draft minutes IETF88 WG meeting

From: Thomas Watteyne <[email-masked]>
Date: Tue, 12 Nov 2013 18:02:24 -0800

All,

You will find the first draft of the minutes of the IETF88 6TiSCH WG
meeting at
https://bitbucket.org/6tisch/meetings/wiki/131105_ietf88_vancouver, and
below.

Thanks to Dominique and Xavi to take minutes, and to Michael to serve as
Jabber scribe!

Please go through the minutes and post any comments/suggestions to this
thread.

We will approve the minutes at the call on Friday, after which we will
upload them on the IETF88 proceedings.

Thomas

-----

Minutes IETF 88 WG meeting, 05 November 2013, 6TiSCH group

Note: timestamps in PST.
Venue

   - Tuesday 05 November, 1420-1550 PST
   - Georgia B room, Hyatt Regency, Vancouver, BC, Canada

Taking notes *(using Etherpad)*

   1. Xavi Vilajosana
   2. Dominique Barthel

Jabber

   - Room: xmpp:[email-masked]
   - Logs: http://jabber.ietf.org/logs/6tisch/
   - Jabber scribe: Michael Richardson

Recordings

   - audio recording<http://www.ietf.org/audio/ietf88/ietf88-georgiab-20131105-1300-pm3.mp3>
[mp3,
   155MB]
   - Jabber logs <http://www.ietf.org/jabber/logs/6tisch/2013-11-05.html>

Material

   - Consolidated Slides:
   http://www.ietf.org/proceedings/88/slides/slides-88-6tisch-1.pdf

Agenda

See IETF88 6TiSCH Agenda
page<https://datatracker.ietf.org/meeting/88/agenda/6tisch/>

   - Intro and Status *[10min]*
      - Agenda Bashing
      - <draft-palattella-6tisch-terminology-00<http://tools.ietf.org/html/draft-palattella-6tisch-terminology-00>
      - 6TiSCH charter recap
   - Architecture *[15min]*
      - <draft-watteyne-6tisch-tsch-00<http://tools.ietf.org/html/draft-watteyne-6tisch-tsch-00>
      > *(Thomas Watteyne)*
      - <draft-thubert-6tisch-architecture-01<http://tools.ietf.org/html/draft-thubert-6tisch-architecture-01>
      > *(Pascal Thubert)*
   - Information and Data Models *[25min]*
      - <draft-wang-6tisch-6top-00<http://tools.ietf.org/html/draft-wang-6tisch-6top-00>
      > *(Xavi Vilajosana)*
      - <draft-sudhaakar-6tisch-coap-00<http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00>
      > *(Pouria Zand)*
      - Coverage gap analysis vs. charter *(Dominique Barthel)*
   - Minimal RPL support *[10min]*
      - <draft-vilajosana-6tisch-minimal-00<http://tools.ietf.org/html/draft-vilajosana-6tisch-minimal-00>
      > *(Xavi Vilajosana)*
   - Call for draft adoption *[10min]* *(Chairs)*
   - Unchartered drafts if time permits *[15min]*
      - <draft-ohba-6tisch-security-00<http://tools.ietf.org/html/draft-ohba-6tisch-security-00>
      > *(Yoshihiro Ohba)*
      - Overview discussion on slot allocation principles
      - <draft-piro-6tisch-security-issues-00<http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00>
   - AOB *[5min]*

Minutes

   - *[14:20]* Meeting Starts
   - *[14:20]* Intro and Status
      - Introduction *(Thomas Watteyne)*
         - Jabber room available.
         - Etherpad with minutes.
         - Note well read.
         - Meeting is recorded.
         - Objectives of the meeting
            - first meeting of the WG
            - go through the drafts
            - 8 drafts published under 6TiSCH
            - discussion of reshuffling of content between various drafts
            - update general directions
            - election of WG documents
         - Agenda
            - Intro
            - Architecture
            - Informations Models
            - Minimal RPL support
            - Call for draft adoption
            - Unchartered drafts
         - <draft-palattella-6tisch-terminology-00> *(Pascal Thubert)*

      Presented version:
      http://tools.ietf.org/html/draft-palattella-6tisch-terminology-00

      - version is 00 but this draft has 3 revisions, it is 00 due to name
         change
         - added additional terminology
         - Avoid colliding definitions. It does not use 15.4e terminology.
         - Extends ROLL terminology
      - 6TiSCH charter recap *(Pascal Thubert)*
         - Scope of the WG is presented again for clarification.
         - goal after IETF87 BoF: reduce number of work items. Ended up
         with half of initial charter.
         - work item 1: limit the scope to RPL operation over static
         schedule. Not schedule management in that charter yet.
         - work item 2: information model containing the management
         requirements: Information model currently in English. Data
Model in YANG.
         Turn into different representation of the data.
         - work item 3: specification of how we can run RPL on a static
         TSCH network. Need for management (see RPL industrial applicability
         statement), it is the base by which can control the network
(like control
         plane).
      - Architecture
      - <draft-watteyne-6tisch-tsch-00> *(Thomas Watteyne)*

      Presented version:
      http://tools.ietf.org/html/draft-watteyne-6tisch-tsch-00

      - update on the draft: minimal changes and minor rewording and typo
         correction. Gives an overview of TSCH and outlines what 6TiSCH should
         provide.
         - in TSCH management and monitoring is out of scope.
         - draft stable for at least 2month
      - *[14:31]* <draft-thubert-6tisch-architecture-01> *(Pascal Thubert)*

      Presented version:
      http://tools.ietf.org/html/draft-thubert-6tisch-architecture-01

      - follows the discussions on the ML, status of the work being done.
         - this is 4th revision, with 6tsch renamed to 6TiSCH, published as
         -01
         - reorganization,
         - updated interaction models
         - fragment forwarding supported (see 6lo) because of small frames
      - Information and Data Models
      - <draft-wang-6tisch-6top-00> *(Xavi Vilajosana)*

      Presented version:
      http://tools.ietf.org/html/draft-wang-6tisch-6top-00

      - draft defines interface offered on top of TSCH to upper layers
         - was presented in IETF87 Berlin. Changes:
            - updated terminology for consistency with terminology draft
            - made tables and text consistent
            - corrected typos.
         - shows full table of commands for control and monitoring
         - Example usage: centralized approach with a PCE (not in current
         charter scope) and distributed RPL routing (in current
charter scope). Try
         to be as wide as possible not to restrict further work.
         - Example of communication between nodes at MAC layer (Information
         Elements in 15.4e TSCH frames). Need to discuss it further with 15.4e
         experts.
         - Content of this draft is wide, may warrant reshuffling between
         various drafts.
         - Need to distinguish description of interface (communication with
         upper layers) and internal operation of this layer. Also make
explicit how
         15.4e MLME commands are used as a result of 6top commands.
         - Further open questions : Delete cell ACK ? Hard cell removal ?
         - *[Carsten Bormann]* This draft seems to be a collection of
         verbs, describing what it does. Recommend to describe with
nouns. Build
         data model. Much easier to understand.
         - *[Thomas Watteyne]* There is an agenda item which covers data
         model.
      - <draft-sudhaakar-6tisch-coap-00> *(Pouria Zand)*

      Presented version:
      http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-00

      - Subject of the work:
            - Data Model definition for CoAP
            - 6top on top of TSCH
            - Needs an Information Data Model to Interact Data Model
            - 6top offers the commands
            - Uses CoAP methods:
               - GET,POST,PUT,DELETE
               - Mapping CoAP methods to 6top commands through URIs
            - Management Resources, R/W access
            - e.g. URI 6t/Neighbor can be use to manipulate the information
            of the neighbor table
            - Informational resources: Read accessibility
            - Message format:
               - GET: Content encoded using CBOR, URI query uses ABNF.
               - POST: payload encoded using CBOR.
               - DELETE: Uri-Query using ABNF.
            - Open Issues:
               - can ABNF be used?
            - Mapping of CoAP to 6top:
               - e.g. POST to URI /6t/neighbor calls
               Create.neighbor(address,stats)
            - *[Emmanuel Baccelli]* why using CoAP to manage the resources?
            How does this relate to the work being done at 6lo?
            - *[Thomas Watteyne]* We followed the 6lo discussion about
            SMIv2/SNMP and YANG/NETCONF closely. Ideas evolved in
parallel in different
            groups. Will need further coordination.
            - *[Don Sturek]* Thomas, is 6top just an api to manage the MIB,
            or does it require some over-the-air protocol?
            - *[Thomas Watteyne]* API by now. Goals of 6TiSCH is to
            translate API to several over-the-air protocols.
            - *[Carsten Bormann]* 6top looks like an SNMP table.
            - *[Mehmet Ersue]* RESTCONF WG created a REST variant of
            NETCONF called RESTCONF. RESTCONF is a mechanism to manage
MIB described in
            YANG. Please verify whether this draft is applicable.

            From *Pieter De Mil* on Jabber: RESTCONF draft at
            http://tools.ietf.org/html/draft-bierman-netconf-restconf-02

            - *[Don Sturek]* Does 6top define some communication between
            neighbors? This is especially helpful to detect asymmetric
links, by having
            neighbors exchange RSSI information about one another.
            - *[Thomas Watteyne]* The plan is to turn YANG model into a
            neighbor-to-neighbor communication protocol. This will
allow neighbors to
            exchange RSSI information. This is not within charter now,
so we need to
            clearly separate the API portion of 6top from the actual
over-the-air
            protocol.
            - Presentation continuous with examples of operation.
            - Open Discussion: whether to define a generic data model using
            YANG.
            - *[Michael Richardson]* Any two nodes might do something like
            this it does not look like this in the presentations.
            - *[Pouria Zand]* Neighbor-to-neighbor communication is not
            part of this charter. It is for sure next step.
            - *[Mehmet Ersue]* RESTCONF provides features that are
            important for configuration management, such as transactions.
         - Coverage gap analysis vs. charter *(Dominique Barthel)*
         - Slide presents different building blocks on the current working
         documents.
         - The 6top draft is wide because it was created before the scope
         of the charter was narrowed down after IETF87.
         - discussion about how to organize the information ongoing
         - *[Ted Lemon]* Advice on whether to put the extra information.
         Put in a separated document and publish that whenever is the
right time.
      - Minimal RPL support
      - <draft-vilajosana-6tisch-minimal-00> *(Xavi Vilajosana)*

      Presented version:
      http://tools.ietf.org/html/draft-vilajosana-6tisch-minimal-00

      - newly submitted draft, not presented at IETF meetings before.
         - Work item in charter to describe minimal mechanism for operation
         of distributed routing over static schedule.
         - Define a default (fall-back) mechanism.
         - 101 cells in slot frame, 16 channels for channel hopping, 5
         well-known shared cells for communication (with contention), 3 MAC
         retransmission, 15ms cell duration (copes with slow hardware)
         - draft defines timing within slot.
         - draft defines content of Sync IE (Information Element) and Link
         IE.
         - draft defines Time Source neighbor selection: use RPL DAGrank as
         JoinPriority for advertisement, select neighbor with min
JoinPriority as
         time source neighbor.
         - draft defines minimal content of neighbor table.
         - draft defines Objective Function used for RPL as OF0 with
         step_of_rank equals to 2 * ETX.
         - draft defines RPL non-storing as MUST, storing mode as MAY.
         - Open issues:
            - use of ASN vs timestamp
            - OF0 does not know 2*ETX
         - Content of this draft already implemented open source as part of
         UC Berkeley's OpenWSN project. Works.
         - *[Pascal Thubert]* Importance of choosing between ASN and
         timestamp. ASN is linked to one MAC schedule. Timestamp
accommodates for
         multiple schedules in the same network.
      - Call for draft adoption *[10min]* *(Chairs)*
      - draft-palattella-6tisch-terminology
         - has been stable for a long time. Two new definitions in last
         version.
         - Anybody opposed to adopting as WG document?

         No hands raised.

         - Chairs will confirm on mailing list.
      - draft-watteyne-6tisch-tsch
         - very stable
         - Chairs feel this draft is ready for adoption
         - Anybody opposed to adopting as WG document?

         No hands raised.

         - Chairs will confirm on mailing list.
      - draft-thubert-6tisch-architecture
         - Not stable in content, but closely following discussion on the
         mailing list.
         - Anybody opposed to adopting as WG document?

         No hands raised.

         - Chairs will confirm on mailing list.
      - draft-vilajosana-6tisch-minimal
         - Chairs feel this draft is ready for WG adoption. There is an
         implementation.
         - Anybody opposed to adopting as WG document?

         No hands raised.

         - Chairs will confirm on mailing list.
      - draft-wang-6tisch-6top and draft-sudhaakar-6tisch-coap drafts were
      presented. Not ready yet, will propose reshuffling of content,
then present
      again to WG for adoption.
   - Unchartered drafts if time permits *[15min]*
      - <draft-ohba-6tisch-security-00]> *(Yoshihiro Ohba)*

      Presented version:
      http://tools.ietf.org/html/draft-ohba-6tisch-security-00

      - Security is a key topic for us.
         - Objective is to provide a secure key management framework to
         dynamically update the CCM* keys
         - identify requirements for the Key Management Framework (KMF)
         - *[Michael Richardson]* What is the objective? management or
         framework?
         - *[Yoshihiro Ohba]* The draft is focused on the 6tisch framework.
         Management will go in a separate draft.
         - Framework is for 6tisch and other mesh network that requires key
         management.
         - 3 phases:
            - Bootstrap
            - Link establishment
            - Operational
         - draft focuses on point 1 and 2 requirements
         - 3 key modes:
            - mode 1 broadcast and unicast keys are the same
            - mode 2 broadcast and unicast are the same with bidirectional
            unicast keys
            - mode 3 broadcast and unicast are the same ...
         - Example sequence presented.
         - Requirements for KMP are listed for each phase.
         - Key distribution is started at the root and is distributed hop
         by hop.
      - Overview discussion on slot allocation principles *(Pascal Thubert)*
         - historically PCE is used, with central schedule
         - however, we aim for a capability to provide distributed schedule
         computation based on the use of RPL.
         - Problem:
            - timeSlot distributed allocation is complex:
               - scope of the next recharter.
               - how do we allocate a time slot?
                  - centralized allocation
                  - Fully distributed
                  - parent based allocation taking advantage of the RPL
                  draft
               - Variable Bit Rate (VBR) traffic yields poor use of
            reserved resources
               - VBR requires better ways to deal with scheduling
               - Statistical multiplexing
               - Best effort QoS
            - allocate dynamically (using OTF) to cope with traffic bursts.
            - having a "more bit" indicating that we will need next time
            slot.
         - *[Don Sturek]* Do you take into account the regulations (like
         ETSI restrictions on percentage of channel usage) when scheduling?
         - *[Pascal Thubert]* Thanks for the comment, this is well
         explained in the ISA100.11a we will take it account ETSI
recommendations.
      - <draft-piro-6tisch-security-issues-00>

      Version:
      http://tools.ietf.org/html/draft-piro-6tisch-security-issues-00

      - *[15:48]* AOB

   No other business is raised.

   - *[15:50]* Meeting ends.