Minutes IETF98: 6tisch
minutes-98-6tisch-01

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes IETF98: 6tisch
State Active
Other versions plain text
Last updated 2017-03-30

Meeting Minutes
minutes-98-6tisch

   # Minutes, IETF 98 6TiSCH WG Meeting #

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

```
Meeting        :   IETF 98; Tuesday, March 28, 2017 (CST)
Time           :   9:00-11:30, Tuesday Morning session I
Location       :   Room Zurich C, Chicago Swisshotel Concourse Level
Chairs         :   Pascal Thubert
                   Thomas Watteyne  (remote)
                   Michael Richardson  (acting)
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 (10mn) (Chairs)
    * Note-Well, Blue Sheets, Scribes, Agenda Bashing               [ 5min]
    * draft-ietf-6tisch-minimal-21,
      draft-ietf-6tisch-terminology-08,
      progress vs. charter                                          [ 5min]
* Security (75min, lead by Michael)
    * Presenting the drafts and the flow between them (Michael)     [20min]
    * draft-ietf-6tisch-dtsecurity-secure-join-01 (Michael)         [15min]
    * draft-ietf-6tisch-minimal-security-02 (Mališa)                [15min]
    * draft-richardson-6tisch-join-enhanced-beacon-01               [10min]
    * draft-richardson-6tisch-minimal-rekey-01                      [10min]
* 6top protocol  draft-ietf-6tisch-6top-protocol-03  (Xavi)         [15min]
* Service Function 0 draft-ietf-6tisch-6top-sf0-03  (Diego)         [15min]
* Architecture draft-ietf-6tisch-architecture-11 (Pascal)           [10min]
* News from IEEE 802.15.4 (Pat)                                     [15min]
* Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun)  [10min]
* Any Other Business (Chairs)                                       [ 5min]

```

Resources
=========

* agenda: https://datatracker.ietf.org/meeting/98/agenda/6tisch/
* presented slides:
https://www.ietf.org/proceedings/98/slides/slides-98-6tisch-aggregated-slides-06.pdf

Summary
=======

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

```
The Working Group meeting went smoothly and according to agenda, started and
completed in time. All the expected slots took place except for the last one on
detnet-backhaul-architecture which was informative to the group. The group is
ready to call for adoption for the 6P and SF0 documents, with restrictions. The
first restriction is the lack of feedback information from SF on whether the
panel of capabilities from 6P is sufficient to achieve all the needs to an
abstract SF. This will be alleviated by experience from the interop test in
Prague so we expect to be ready then. Also remarks on the lack of definition of
the service interface between SF and 6P, e.g. pointing on the responsibility of
the timeouts and the values incurred. The largest piece of the meeting dealt
with security. The framework was presented in which the minimal security based
on PSK can be seen as an optional portion of the larger flow that starts with
private keys / certificates and fits within the ANIMA framework. A status was
given on related work in other WG and at the IEEE.

```

Volunteers
==========

* notetaker 1: Dominique Barthel
* notetaker 2: Geraldine Texier
* notetaker 3: Francesca Palombini
* notetaker 4: Alexander Pelov
* notetaker 5: Tero Kivinen
* notetaker 6: Xavi Vilajosana
* notetaker 7: Pascal Thubert
* Jabber scribe 1: Diego Dujovne
* Jabber scribe 2: Ines Robles
* Jabber scribe 3: Michael Richardson

Minutes
=======

* [09.01] (expected: 09.00) meeting starts
    * Thomas calling in from Paris
* [09.03] (expected: 09.00) Intro and Status (10mn) (Chairs)
    * [09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda Bashing
                  [ 5min]
        * Pascal goes through agenda:
          * 70 min dedicated to security, will be able to do some work instead
          just present slides. * -minimal: Xavi now integrated all
          comments/reviews. -21 should go to IESG
    * [??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21,
      draft-ietf-6tisch-terminology-08,
      progress vs. charter                                                     
            [ 5min]
    * mcr: plans for future plugtest ?
    * Thomas: yes, at Prague, probably 14 and 15 July, or after meeting.
    Physical meeting but tools for online testing.
     At the next interim meeting we'll discuss the scope of the interop. Likely
     -minimal, 6top, minimal sec.
    * we'll have an expert team to write the test description
    * Kerry: 6lo plugtest as well? Pascal: will see.
    * Suresh: -minimal underwent major review, many reviewers provided
    comments. Going to RFC editors. was approved a week ago.
* [09.12] (expected: 09.10)  Security (75min, lead by Michael)
    * presented at Detnet and ANIMA yesterday. Will repeat intro anyway.
    * [09.13] (expected: 09.10) Presenting the drafts and the flow between them
    (Michael)     [20min]
        * goal: explain how the drafts fit together.
        * every 2 weeks phone meetings
        * new Doodle poll. If you couldnt make it to the past times, cast your
        vote for better times. * security considerations in ROLL actually
        applies to all LLNs * zero-touch: designed for networks that need to
        scale to huge number of nodes * the two security drafts were adopted
        after last IETF meeting * -enhanced-beacon: could not wait for
        -minimal, wrote ED usage description in separate draft * new
        terminology used: pledge - join registrar/coordinator - join proxy *
        took some terms form ANIMA. E.g. MASA  Manufacturer Auhtorised Signing
        Autority
          - sets PSK if manufacturers knows which customer the device is
          shipped to. - Michael goes through decision tree for Pledge node to
          join. Hearing first EB can be
            very long, consumes energy.
          Subir: reason for going back in decision tree? mcr: if heared EB from
          wrong network - table of constraints: Michael interestsed in knowing
          other contraints that migh have been missed
        *
        * high level explanation of PSK and RPK cases. For FPK, needs to do
        EDHOC first (see ACE presentation) * Thomas: re. time to join. you can
        optimize many things, we are talking about seconds not minutes though.
          one of the constraints is that you get all the nodes to join roughly
          at the same time ("flood of join"). One use-case: when installing a
          network in a plant, booting the router last, every nodes will join at
          the same time
        * Benjamin Damm:   ? mcr: bring question to the list, it's a difficult
        one. One example is two "identical" parts were swapped during shipment
        to two customers. "Just" need to redo pre-provisioning, not swap the
        part. How? *
    * [09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join-01
    (Michael)         [15min]
        * status of the document: reduced this to the scope of the zero-touch,
        pushed some content to -minimal or other * Thomas: will we have an
        opportunity to talk about IP-IP vs. CoAP? mcr: good question, let's
        take that at the end. * will use CBOR Web Token as a voucher, will
        reuse a lot of code (COSE, CBOR already in place) * ANIMA so far not
        using CBOR, negociation going-in to unify. * presentation of anima
        document. Revocation not needed. * Max: you can find this in the notes
        from Anima meeting * Suresh: regardin one and zero-touch: what is going
        to be the update of one vs the other? mcr: goal to make the on-the-wire
        mechanism as close as possible. Expect to see devices that are
        both-capable. You can see that the differences are not big right now
        (Ack for bandwith control). * one difference is rate of requests: if
        Pledge drives the timing and many pledges, not much control. Il JCR
        drives its own rate, can control. * Suresh: at some point you still
        have to choose between those two. mcr: if you have a manifacturer that
        can put a PSK in it for you, you can do that. If you have a large
        number of devices or many manifacturers, you may want to go to one
        touch instead. * Thomas: or you can have a configuration step * Suresh:
        question still remains. What if you have one mechanism? Is it possible
        to reduce these two processes into one? * mcr: trying to build a
        protocol that allows you to deal with different cases: if we have the
        PSK, we can do the simplest thing, otherwise we can do this other
        thing. For example, might have a PSK for network A, and if deployed in
        network B, still ok since has a DevID. * Suresh: . * mcr: proposal by
        Goran, but doesn't have a home yet. * mcr goes through questions listed
        at ANIMA. * Please help articulate the benefit of using of CWT instead
        of adding PKCS7. * Open Issues * pictures ideal outcome, with
        convergence between 6Tisch, ANIMA ,
    * [09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (Mališa) 
                  [15min]
        * status: -02 includes major editorial restructuring, stabilizes the
        Join Process * this is one touch scenario draft * presentation of the
        join process * security handshake: this is the current version, and is
        not set in stone * Mohit: security hanshake, said could use EDHOC. Why
        rely on EDHOC if using P SK? * Malisa: in case of PSK it's optional to
        run EDHOC, if you require perfect forward secrecy you can run EDHOC
        with PSK, in case of RPK it's mandatory. * mcr: 3a (refer to message in
        the slides) (AAA) is optional when you don't use PSK. * Join Proxy
        operated as CoAP proxy in previous version of draft. Now new CoAP
        option to carry state between Proxy and Server, * could do IP-in-IP but
        proble is 3 IP headers, how about compression. * Pascal: provide
        example on the list for discussion. If all prefixes same as LBR, might
        be able to compress. * Carsten: could you present the status of this
        doc (incl. Join Proxy) at CoRE meeting end of the week?  mcr: Friday
        morning. Malisa can make it. * Thomas: re. IP-in-IP vs. CoAP: CoAP can
        use well-known resources, saves a lot of exchanges that we have to do
        with IP-in-IP. * mcr: I dont think we have to do all that:
        specifically, the address of JRC could be LL-anycast, and I don't think
        that there any other addresses that the pledge needs to know. *
        describes how nonce and key are generated in OSCOAP at the pledge and
        at the JRC * Mohit: which values provide enthropy? Malisa: we are using
        the OSCOAP mechanism, we only use it in our case. Mohit: ok, will check
        with authors and carry forward on the mailing list. * Pascal:
        Interested in the discussion about the nonce transport because LoRaWAN
        seems to use similar mechanism so if real pb would like to know!
    * [10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-beacon-01
                  [10min]
        * Diego presents.
        * Draft meant to add join information into EB to make joining more
        efficient. * beware that EB is not encrypted, should not put here stuff
        that should not be seen by attacker, e.g. PIO. * Erik: it is not clear
        what this Network ID is. mcr: hash of DODAG id. Issue is that it's
        constant across time. As long as connected to same root. * Malisa: why
        is PAN ID not enough? mcr: we might decide that we always use a
        constant PAN ID, maybe it is enough. Diego: a combination of both *
        Thomas: Ask same question about PAN ID. PAN ID might be the simplest
        way. * Subir: slide 3. How do you identify JCE? mcr: This is from the
        Join Proxy. L2 address and ... * Benjamin: Frequency bands/channels to
        use. How does it get to know about it? mcr: not an IETF problem. *
        Diego: asking for comments about adoption. * Pascal: interest in the
        document. Should this document be adopted *at some point* by this WG? 
        (about two in favour), (nobody against), (two have read document) *
        Samita: ? Diego: * mcr: next presentation will respond to Samita's
        question.
    * [10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01       
                  [10min]
        * Michael presents new draft. Presentation about the concept behind it.
        Uses CoMI. * when node receives draft with a given key in table, will
        start sending traffic with this same key. * Mohit: do keys have key id?
        mcr: yes, on the wire * allows to eliminate malicious node off the
        network, but may take a long time because need to rekey all the other
        nodes,
          that may be sleepy and will keepy accepting previous keys for some
          time.
        * Kerry Lynn: are there requirements that nodes wake up every n days?
        mcr: if you dont wake up every time and then you would lose
        desyncronisation AND you would loose the keys as well, so it's not a
        big addition to the requirements. * Interested in adopting this, using
        CoMI (possibly CoMI co-author)
* [10.34] (expected: 10.25) 6top protocol  draft-ietf-6tisch-6top-protocol-03 
(Thomas replacing Xavi)         [15min]
    * stable document. About distributed 6TiSCH cell allocation.
    * few cahnges from previous version. Most notable is relocate command to
    improve on delete+create cell. * authors believe the draft is ready, but
    few unknows: relation with SF, missing functionalities? * will know from
    6TiSCH plugtest event in July. * Pascal: ask for in depth reviews, in
    particular from an allocation expert. Diego, Charlie will review this
    document. * Pascal: after review, will ask for last call. * Thomas (as
    chair): would feel more confortable moving it to last call if all the
    pieces fit together, in particular feedback from implementors about 6P+SF0
* [10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6top-sf0-03
 (Diego)         [15min]
    * this draft is about a simple scheduling function.
    * following discussion at IETF97, adopted one mechanism for bandwith
    estimation. * Packet Delivery Ratio estimation computed on last 10 packet
    transmission. Is 10 a good value? * Timeout: Yasuyuki proposed algorithm.
    See discussion on mailing list (Dec 2016 onward). * Thomas: *algorithm*
    already implemented in 6P. The 6top draft says timeout *value* is left to
    the SF, because it's the only entity in the node that has the full view.
     diego: we are thinking about the whole transaction, instead of a timeout
     for each of the exchanges. Now you have to calculate the worst timeout
     between all the exchanges, which is very long. Pascal: let's take that to
     the mailing list.
    * discussion on cell relocation: oprions are
        * when PDR gets significantly worse that average for all cells
        * constant relocation to number of random cells ()
        * leave it to implementation
    * Tengfei: For the PDR_THRESHOLD, each cell is provisioned by different
    SFs, so as long as the cell is related by the corresponding SF, which is
    running on one side, there is no issue for interoperability. (Copied over
    from jabber) Thomas Requested to start a Thread on the ML on that Malisa on
    mic: there is a 6tsich simulator available on the bitbucket page that is
    convenient for simulating this sorts of algorithms. please take a look. *
    Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides duty
    cycling. * PAscal: this draft should ship together wth 6top. But pobably as
    informational, and make second version as standards track when we have more
    experience * Malisa (from jabber):  there is a 6tsich simulator available
    on the bitbucket page that is convenient for simulating this sorts of
    algorithms. please take a look.
* [11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture-11
(Pascal)           [10min]
    * considerationa about "tracks". Also provided in Detnet draft. A 6TiSCH is
    not just a serial sequence of cells along a path. Can include
    replication/elimination. * published draft at BIER to describe how this
    path replication (using Arc routing) works. * Tests have been performed to
    combine BierTE mechanism with tracks. A bitmap tells the path to take. *
    The bitmap indicate the paths that failed or not, enabeling an OAM
    mechanism and a control loop * Kerry Lynn: how does this compare to FEC?
    Pascal: we are mostly aiming at protecting against node failure; TSCH is
    pretty good at reducing link failure probability. * Pascal: take advantage
    of inherent broadcasting of radio to do "bi-casting", by having two
    receivers and one transmitter per cell. This increases reliability. * Also
    expose node multiple parents to RPL root (in non-storing mode), shows the
    full structure. Root can find shorter pathes. Effectively reduces latency.
    * Recap: *tracks* are much more than sequence of cell. * Tengfei: we are
    conducting large-scale experiments of 6P SF0 on the IoT-lab, with 100-nodes
    runnign openWSN. will contribute results to the group verifying the current
    of 6p and SF0 work. * Malisa: working on 6TiSCH simulator, on BitBucket.
    Will contribute the results to the group. Explore the code and contribute.
    * Pascal: please write that in the mailing list
* [11.15] (expected: 11.00) News from IEEE 802.15.4 (Pat)                      
              [15min]
    * 15.4q: new low power PHY, has Amplitude Shift Keying. Not backward
    comptabible. * 15.4t: 2Mbps, backward compatible with current radios. *
    next 15.4 revision will integrate 6 amendments and include corrigenda. *
    15.9: Information Elements for Key Management Protocols. * 15.10: layer 2
    routing. Meant to support "large scale" networks (node count in the
    thousands).

        Randy Turner asked what is large scale, Charlie answered thousand

    * 15.12: upper layer over 15.4. Defines concept of profiles (e.g. for WiSun
    or Thread). * Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC
    similar to 15.4. But nobody at 15.6 asked 15.12 to consider their techno *
    Carsten: Is this all done? Pat: no it's underway right now. We do need
    help. * Bob: 15.6 has a limited stack architecture, star topology, very
    isolated approach to many things, very closed, trying to put 15.6 in
    discussion is challenging at best, talking about 15.7 would be much better.
    * Need participation from this group.
* [xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) 
[10min]
    * skipped for lack of time
* [11.29] (expected: 11.25) Any Other Business (Chairs)                        
              [ 5min]
    * Samita: please come to 6lo
* [11.30] (expected: 11.30) meeting ends