Minutes IETF97: 6tisch
minutes-97-6tisch-01

# Minutes, IETF 97 6TiSCH WG Meeting #

Agenda and Meeting information
==============================

```
Meeting        :   IETF97 Thursday, November 17, 2016 (KST)
Time           :   9:30-11:00, Thursday Morning session I
Location       :   Park Ballroom 1, Conrad Seoul
Chairs         :   Pascal Thubert <pthubert@cisco.com>
                   Thomas Watteyne <thomas.watteyne@inria.fr>
Responsible AD :   Suresh Krishnan
URLs           :   http://tools.ietf.org/wg/6tisch/
                   https://datatracker.ietf.org/wg/6tisch/
                   https://www.ietf.org/mailman/listinfo/6tisch
                   https://bitbucket.org/6tisch

Intro and Status                              [5min] (Chairs)

   Note-Well, Blue Sheets, Scribes, Agenda Bashing

New charter and status docs                   [10min] (Chairs)

   * Status minimal, 6LoRH, 802.15 IE
   * Milestones

Dynamic Scheduling

   * <draft-ietf-6tisch-6top-protocol>                [20min]
     (Xavier Vilajosana)

   * <draft-ietf-6tisch-6top-sf0>                     [15min]
     (Diego Dujovne via meetecho)

Security

   * <draft-vucinic-6tisch-minimal-security>          [15min]
     (Malisa Vucinic)

   * <draft-richardson-6tisch-dtsecurity-secure-join> [20min]
     (Michael Richardson)

Any Other Business                                     [5min]
     (Chairs)
```

Resources
=========

* agenda: https://datatracker.ietf.org/meeting/97/agenda/6tisch/
* presented slides: (https://datatracker.ietf.org/meeting/97/session/6tisch/
* recording audio+video+chat:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_6TISCH&chapter=chapter_1

Summary
=======

_This summary is also posted in the INT area wiki,
https://trac.ietf.org/trac/int/wiki/IETF97._

```
The Working Group meeting went smoothly and according to agenda, started and
completed in time. A status was given on related work in other WG and at the
IEEE. It is expected that the IETF IE identifier will be granted.

About draft-ietf-6tisch-minimal.
A recommendation to remove well known keys and a todo to ask for an early sec
dir review.

About draft-ietf-6tisch-6top-protocol.
Got new implementers feedback, asking limited changes.
The work depends on the allocation of an IETF IE by the IEEE ANA.
draft-kivinen-802-15-ie, the draft that presents the need and the expected
utilization of an IETF IE, is mostly complete and due to IESG telechat in a few
weeks. Once the request is posted to IEEE, we can expect a rapid turn-around
and that the IETF IE will be granted before YE2016, which matches the expected
date for WGLC for this document.

About draft-ietf-6tisch-6top-sf0.
A few questions are still open, such as the source of the time slots that are
to be granted. Chairs to do a formal request to have feedback from implementers.

About draft-vucinic-6tisch-minimal-security.
New draft describing the end of the join process once the key is obtained.
Depends on work at CORE on OSCOAP.
Will be integrated as the second phase of the 6TiSCH join.
No opposition to WG adoption in the room, chairs to call for adoption on the ML.

About draft-richardson-6tisch-dtsecurity-secure-join.
Work of the security design team, well advanced.
Inherits from ANIMA, and can be seen as the first and optional phase of the
join process. One critical decision remains to be made, whether the FSM is in
the JCE or in the device. No opposition to WG adoption in the room, chairs to
call for adoption on the ML. ```

Action items
============

* Chairs to call for implementation and feedback for draft-ietf-6tisch-6top-sf0.
* Chairs to call for adoption of the security drafts
(draft-vucinic-6tisch-minimal-security,
draft-richardson-6tisch-dtsecurity-secure-join) * WG to Consider progressing
the terminology so unblock minimal. * AD to ask for an early sec dir review of
draft-ietf-6tisch-minimal.

Volunteers
==========

* notetaker 1: Dominique Barthel
* notetaker 2: Geraldine Texier
* notetaker 3: Francesca Palombini (promoted!)
* notetaker 4: Alexander Pelov
* notetaker 5: Tero Kivinen
* notetaker 6: Xavi Vilajosana
* notetaker 7: Pascal Thubert
* Jabber scribe: Ines Robles

Minutes
=======

* [09.30] (expected 09.30) Meeting starts
* [09.30] (expected 09.30) intro (Thomas Watteyne)
    * reminds of Note Well.
    * presents agenda. bashing?
    > No issues raised, agenda approved.
* [09.32] (expected 09.35) WG status (Pascal Thubert)
    * documents
        * draft-minimal
            * **[Suresh]** just did his review. Some comments, like
            redefinition from terminology doc, inconsistency, a few
            questionable SHOULDs. * **[Pascal]** will this be held by
            terminology doc? * **[Suresh]** it can still progress through IESG,
            will then be in waiting state at the exit. * **[Suresh]** also huge
            section to define Rank that was already defined in RPL. Make sure
            this doc only defines the increments, if any. * **[Tero]** this doc
            specifies default keys. This is discouraged. * **[Tero]** minimal
            testing now done, should remove well-known keys and defaut
            passwords that were meant for interop testing. * **[Suresh]** can
            send this doc for early Sec Dir review, to Tero for example! *
            **[Xavi]** the text does say it's only for interop testing
        * -6top-protocol
        * SF0: the architecture is stable, text is missing about tracks
        * SF1 won't be discussed this time but in next IETF
    * non 6TiSCH docs
        * ROLL and 6lo: Paging dispatch and Routing Dispatch passed IESG
        * Backbone router doc is split during the 6lo session
    * Milestones
        * goal is to release 6top by end of year
        * SF0 may slip by a couple of months
    * action plan
        * complex action item on security: work on join process. Trying to make
        this a 2-stage approach * **[Michael]** plan for plugfest before the
        Prague meeting July 2017? * **[Thomas]** We will have a plugfest in
        July at IETF99 in Prague. None a priori before that.
* [09.44] (expected 09.45) draft-ietf-6tisch-6top-protocol (Xavi Vilajosana)
    * much activity on mailig list.
    * New in this -03 version:
        * type field
        * cellOptions
        * cell suggestion in ADD response,
        * best effort number of cells in LIST response
    * draft seams stable - call for implementors comments
    * presentation of the cellOptions bitmap, it enables to specify what kind
    of cell is needed (TX, RX, Shared) * the cellOptions field is added in 6P
    ADD Request and 6P DELETE Request
        * in DELETE, if no cell lists provided, all cells of type described in
        CellType field will be deleted
    * suggestion field in response reduces the number of request attempts
    * do you think anything is missing?
    * **[Thomas]** Offline feedbacks from implementors, some changes are needed:
        * remark 1:
            * when issuing a LIST command, you can ask for 10 cells, but the
            neighbor returns the number of cells that fit in the packet, e.g.
            6. * your last request needs to contain an empty list so you know
            it's the end of the list of cells, since the neighbor is required
            to answer with at least one cell. * This means there is always
            going to be one extra LIST request. * the suggestion is to add an
            "end of list" return code which the neighbor answers when its
            returning the last cells. * comments/ * **[Xavi]** seems very
            reasonable, very small change
        * remark 2:
            * initially, a mote could only request TX cells to its neighbor,
            now can request anything * this means having two generation numbers
            (GAB,GBA) doesn't mean much anymore. * **[Xavi]** agrees, it has
            been discussed on the mailing list, having a single counter is
            probably enough
* **[Pascal]** before we proceed with next draft, could we have an update about
Tero's draft of having an IETF IE identifier?
    * **[Suresh]** the draft will be on the Dec 15 telechat
    * **[Pascal]** Bob, once the telechat is over, how much time until we get
    the IEEE allocation of an IETF IE ID? * [Bob] 24 to 48 hours. Send the
    request to Pat Kinney and myself, we can expedite.
* [09.58] (expected 10.05) draft-ietf-6tisch-6top-sf0 (Diego Dujovne, Meetcho)
    * version -02
    * why this cell estimation algorithm: originally thought applications would
    request bandwidth. Now we estimate outgoing traffic. * the outgoing traffic
    growth only is used to estimate the traffic requirement * we don't assume
    RPL on top. We don't know where incoming traffic is going * alternative 1:
    is what is done now, some of the allocated cells are used and some are
    empty * alternative 2: adds a fix number of over-provisionning *
    alternative 3: not included in version 02, use a number of effective cells
    and an overprovisionning * question to the room, should we use alt 3? *
    **[Thomas]** I  know people have implemented Alternative 3 at scale, but
    did not provide public feedback * **[Pascal]** please do provide feedback.
    Fixed overprovisioning on a large number of bundles is a large number of
    overprovisioned cells. * **[Pascal]** there are situations where another
    approach would be better (shared pool for overprovisioning)=> alternative 4
    * **[Diego]** this alternative 4 can be discussed on the mailing list *
    **[Xavi]** Pascal's proposal makes sense, but may too be complex for a
    minimal SF, would be good for SF2, SF3, etc. * **[Xavi]** percentage of
    overprovisioned cells might be better that fixed absolute number *
    **[Pascal]** let's continue the discussion on the mailing list * we no
    longer estimate number of required cells based on PDR * cell allocation
    policy, back to using original on-the-fly scheduling, threshold value is
    defined by implementer * the value of the number of softcells to schedule
    is left to the choice of the implementor * Timeout calculation: long
    discussion. Proposal to keep MAC and 6P ACK/timeouts independent * Ask for
    feedback o this proposal * since 6P now allows different type of cells on
    the SF, which ones to use? in SF0, only Tx cells. * **[Thomas]** this was
    discussed recently on the mailing list, it has been decided to keep in
    simple and just use TX cells * compliance to 6P requirements is almost
    done. missing timeout (6P ACK will simplify task to achieve this).
    Satistics to compute PDR. * performance evaluation: paper published IEEE
    Sensors Journal. Simulation only. Ask for input from implementers. * Cell
    relocation: SF0 proposes to trigger a cell relocation when it achieves PDR
    20% less than the average of the rest of the allocated cells * Proposes an
    atomic DELETE/ADD command (a "RELOCATE" command) to do relocation
    efficiently (1 request rather than 2) * asks for comments * Diego asks for
    feedbacks from the implementations, on the algorithm and on the
    alternatives * **[Thomas]** thanks for these changes, which are perfectly
    in-line with what was discussed in Berlin * **[Thomas]** the next step for
    this draft is clearly to receive more feedback from the implementors.
    Chairs will issue a formal request for implementation and feedback on the
    ML.
* [10.21] (expected 10.20) draft-vucinic-6tisch-minimal-security (Malisa
Vucinic)
    * **[Thomas]** Some context. There has been a lot of work on security,
    including through the 6TiSCH Security Design Team. 2 drafts will be
    presented that are complementary. They are two steps of the same secutiry
    solution. * draft about join process: how is a node securely admitted in
    the 6TiSCH network * three entities:
        * JN: joining node
        * JA: joining assistant (neighbor of JN, already in network)
        * JCE: join coordination entity (central authority which coordinates
        joining, a computer at the edge of the network)
    * One touch assumption: we start with the JN having a shared PSK or RPK or
    cert with the PCE * end state of the join protocol: a secure session
    between the JN and the JCE through which the JCE configures:
        * the K2 key (see draft-minimal)
        * the short address of the JN
    * **[Thomas]** want to stress that this short-address allocation replaces
    the 15.4 association. This means the JCE is responsible for ensuring unique
    short addresses are being distributed in the network. * to stress the
    limits of the bandwidth when using 6TiSCH -minimal, conducted initial
    simulations on OpenWSN * scenario: 30 nodes deployed in a room (fully
    meshed), DAGroot is started last * question: how long does the join process
    take depending on (1) the minimal schedule used and (2) the number of
    round-trips * in this setup, join process takes in the order of 10min,
    increases fast as more round-trip exchanges are needed * **[Subir]**: Why
    does this take 7 minutes? which part takes more times? * **[Malisa]** This
    is not the worse case but the join time * **[Thomas]** I see 2 key
    takeaways:
        * the 6top protocol is important as it reduces the join time by
        offloading the shared cell * the number of round-trips required is
        extremely important, it's unrealistic to assume 10 or so round trips
    * **[Thomas]** we want a really lean initial handshake otherwise joining
    takes too long * **[Subir]** this is useful, more data it would be even
    more useful * **[Peter]** Do you randomize your exchange? * **[Malisa]**
    Yes, 1 minute * **[Thomas]** These results do not scare me, this is what is
    expected, just great to put them on a slide. This is when 6TiSHC-minimal is
    used, i.e. no 6top protocol. There are many things that can be done to
    significantly speed up the join process, for example sending RAs in IEs. *
    **[Alex]** duration of a slot? * **[Malisa]** 10ms, i.e. there are 100
    slots per second * Goal is to minimize the number of exchanges. In case of
    PSK, single round trip is enough. * Join protocol: the JN waits for the
    enhanced beacon then do the Neighbor Discovery * **[Pascal]** the ND
    exchange is only to acquire a local address * security handshake is
    optional for PSK and mandatory for RPK/Cert. It uses EDHOC protocol (ECC
    over CoAP). * implemented using CoAP:
        * JN is a CoAP client
        * JA is a CoAP Proxy
        * JCE is a CoAP server
    * goes through nonce generation algorithm, key generation algorithm
    * **[Pascal]** What is the size of sequence numbers used?
    * **[Malisa]** It's CBOR so it's variable (starting at 1B and increasing).
    * **[Alex]** CBOR int types up to 64 bits
    * **[Pascal]** was asking about maximum size, so that roll-over is very
    rare. We should recommend use of 4 bytes, for example. * **[Thomas]** this
    means that the JN does not hear the DIOs before and it just talks to the JA
    on local link * **[Malisa]** yes * **[Laurent]** size of messages? see
    numbers on slide 11. 16/26 bytes for req/answ * **[Tero]** about nonce,
    slide 9, always generates the same key if same sender ID are used? *
    **[Thomas]** no, nonce changed for each (re)join * **[Tero]** use of ASN as
    nonce is a problem. If network restarted, same nonce at the same time. *
    **[Malisa]** we are talking about end-to-end JN-JCE protection, not link
    layer. * **[Tero]** ok * **[Francesca]** Looked at CBOR, maximum sequence
    number byte-length is 7B for the MTI algorithm * **[Pascal]** Francesca,
    can you give us an update about the OSCOAP work presented yesterday at
    CORE? * **[Francesca]** the draft was adopted as WG doc at last IETF
    meeting and seems to be ready, a call for implementations has been issued *
    **[Thomas]** we're overtime. Let's discuss this on the mailing list
* [10.46] (expected 10.35) draft-richardson-6tisch-dtsecurity-secure-join
(Michael Richardson)
    * goal is to align ANIMA, netconf and 6TiSCH WG on this. Trying to account
    for constrained devices, e.g. reduce number of round-trips. * describes
    each group's reference architecture. Similar roles, but some opposite flow
    directions. * goes through roles: MASA, JCE, JA * prescribes zero-touch
    process * list of current issues
        * needs TCP, really? maybe use CoAP, COMI
        * EDHOC vs DTLS
        * need to coordinate with 6TiSCH-minimal
        * RA in IE. RA only, not full IP-in-IE. Also some network ID? For nodes
        that have been sleeping long and are looking for beacons to synchronize.
    * **[Pascal]** there is a DNA solution that can be use, but I like the use
    of the DODAG ID more
        * where should this work be done? Anima, Metconf, 6TiSCH? will discuss
        it with relevant ADs.
    * Would like a consensus on the "outgoing" (PCE->Pledge) method. Has an
    influence on the state machine and on who is responsible for the
    certificate lifetime, should it be the light object? the advantage of the
    "outgoing" method is that it is not its responsibility. * **[Pascal]** one
    minute questions * **[Subir]** does this proposal provide additional
    features to the draft presented by Malisa just earlier? * **[Michael]**
    Malisa's draft is the simpler "on-touch" case where security credentials
    are already present. This draft deals with getting the credentials there. *
    **[Michael]** there will be a security DT call on November 29, encourage
    people to join that. * **[Pascal]** the two drafts are complementary, the
    call for adoption will be made on both document. * **[Pascal]** please hum
    now if you this the two drafts should be adopted > hums * **[Pascal]**
    please hum now if you this the two drafts should NOT be adopted > no hums *
    **[Subir]** would suggest to have only one security approach * **[Thomas]**
    this is exactly the case, there are just two phases in this solution, which
    the drafts detail * **[Pascal]** will call for adoption on the mailing list
    and carry on work
* [11.03] (expected 10.55) Any Other Business?
> No further issues raised.
* [11.03] (expected 11.00) Meeting ends