[6tisch] minutes 6TiSCH WG meeting IETF 94 Yokohama

[Thomas Watteyne <[e-mail]>]

All,

Below are the minutes of yesterday's WG meeting.

Reply to this e-mail if you have any remarks. I will upload these minutes
onto the IETF94 material manager as soon as I land.

Thomas

----


# Minutes, IETF 94 6TiSCH WG Meeting #

Note: this document is formatted using Markdown (
https://daringfireball.net/projects/markdown/)

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

```
Meeting        :   IETF94 Thursday, November 5, 2015 (JST)
Time           :   15:20-17:20 JST Thursday Afternoon session II (2h)
Location       :   Room 303, Pacifico Yokohama, Yokohama, Japan
Chairs         :   Pascal Thubert <[e-mail]>
                   Thomas Watteyne <[e-mail]>
Responsible AD :   Brian Haberman
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                                      [25min] (Chairs)
   * Status Document
   * New Charter
   * Milestones
   * Action Plan

Dynamic Scheduling
   * <draft-wang-6tisch-6top-sublayer-03>        [20min] (Xavi Vilajosana)
   * <draft-dujovne-6tisch-6top-sf0-00>          [20min] (Maria Rita
Palattella)

Tracks in 6TiSCH
   * <draft-thubert-6tisch-4detnet-01>           [20min] (Pascal Thubert)

Any Other Business
   * Announcement second ETSI 6TiSCH Plugtests   [10min] (Miguel Angel
Reina Ortega)
```

Resources
=========

* agenda: https://www.ietf.org/proceedings/94/agenda/agenda-94-6tisch
* presented slides:
https://www.ietf.org/proceedings/94/slides/slides-94-6tisch-0.pdf
* Meetecho recording (audio+video):
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_6TISCH&chapter=chapter_1
* Jabber log: http://www.ietf.org/jabber/logs/6tisch/2015-11-05.html

Summary
=======

[This summary is transmitted to the INT area ADs]

```
The 2-hour 6TiSCH meeting focused mainly on 3 elements:
- rechartering. This has been discussed during 2 interim meetings, and the
text presented at the WG meeting summarized the conclusions from those
discussions. The proposed new charter builds upon the old charter, and
introduces dynamic scheduling of cells. Several constructive remarks were
made about the presentation of the different work items; the chairs took as
action items to integrate those in proposed charter text, and to transmit
it to the IESG.
- the main technical part of the meeting was dedicated to the
draft-wang-6tisch-6top-sublayer-03 and draft-dujovne-6tisch-6top-sf0-00
drafts (both of which are complementary). No major issues were raised about
these draft, but the WG asked a number of clarifying technical questions
and make some smal suggestions the authors agreed to integrate.
- a presentation of draft-thubert-6tisch-4detnet-01, which links the work
done at 6TiSCH with the work done at DetNet. The chairs asked for more
feedback on the document on the mailing.

A number of other points were raised:
- draft-ietf-6tisch-minimal-12 was transmitted to the IESG a couple of
weeks before the IETF94 meeting. Three constructive reviews were sent back
to the WG. To advance the work on the draft, and in the interest of time,
the reviews are discussed on the ML. We had a discussion on the status of
the draft (currently Proposed Standard), which we will conclude on the ML.
- We announced the second 6TiSCH plugtests event to be held on 2-4 February
2016 in Paris, France, organized by ETSI and hosted by Inria.
- We had an announcement about a Study Group created at the IEEE around
defining an LLC which could include work from the 6TiSCH and 6lo WGs, as
well as a KMP and L2R routing protocol. We agreed to continue the IETF/IEEE
liaison around that aspect. The same announcement was made in the 6lo and
ROLL WGs, with a longer presentation at the INT Area session.

The full minutes, the detailed action items and the presented slides are
published in the IETF material manager. The meeting was recorded through
Meetecho, and the recording (audio+video) is available.
```

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

* **Chairs** to rework the charter text:
    * use bullet list, not numbered list
    * put a statement which explains that the architecture follows the
progress of the standardization, and will not be delivered first
    * reorder items?
    * rework text around what can be done at the IEEE
* **Chairs** to finalize discussion about status of 6tisch-minimal on ML
* **Authors** of draft-wang-6tisch-6top-sublayer to take into account the
following remarks:
    * The child should be able to ask for a number of cell _without_
specifying a cells in the CellList, so that the parent can choose from a
chunk it has set aside for that node.
    * would it make sense to have a transaction identifier in 6P?
* **Chairs** to coordinate with IEEE/IETF liaison group to request an IETF
Information Element Payload Group ID to the IEEE.


Volunteers
==========

* Jabber
    * Robert Cragie
* Scribes
    * Dominique Barthel
    * Alexander Pelov

Minutes
=======

* [15.22] Meeting starts
    * ~45+25 participants (local/remote)
* [15.22] Intro and Status (**Thomas Watteyne**)
    * Thomas presents Note Well slide
    * Shows agenda and queries for comments: none. Agenda is approved.
* [15.24] New Charter (**Pascal Thubert**)
    * New charter text discussed at last IETF and at a several latest
interim calls
    * First generation of charter limited to static schedule
    * Now proposing capability to negotiate schedule between nodes
    * Milestones: 6TiSCH architecture not delivered in time, postponed
until other work done to publish only one volume or architecture. Work in
progress. New content will come with dynamic scheduling work. CoAP data
model and information model publication postponed until CoMI is delivered.
    * New charter has 3 new work items:
        * dynamic scheduling on top of 6top
        * secure bootstrapping: a lot of work done on the mailing list
already although not in first charter.
        * track definition and DetNet requirements. Be able to tell DetNet
what 6TiSCH provides.
    * New charter text shown, in final discussion
    * Requests to work on track definition and mechanism. Planned for 3rd
gen charter.
    * Current non milestones work items: Test Description for next ETSI
6TiSCH plugtest.
    * [**Brian Haberman**] is order in list on screen order of doing work?
Architecture first?
    * [**Pascal Thubert**] on-going work on architecture. Only published
after other work done.
    * [**Brian Haberman**] numbered list looks like ordered list. It is
important to note that the architecture is a work in progress that will be
updated as the time goes by. Some people wait for a document to be
published, before they start reading it. Making it explicit may help some
people understand and read it before.
    * [**Pascal Thubert**] we will remove the numbers, place bullets and
rewrite that architecture will be continuously worked on and not delivered.
    > Action item: **Chairs** to rework the charter text.
    * [**Brian Haberman**] Test Description looks like compliance testing.
    * [**Thomas Watteyne**] This text just reflects what we have been doing
in first 6TiSCH plugtest.
    * [**Pascal Thubert**] requirements to be able to play the interop
game. Otherwise, implementations could have nothing in common.
    * [**Brian Haberman**] intention to publish into RFC?
    * [**Thomas Watteyne**] no
    * [**Chonggang Wang**] The IoT router in bullet 3 is not defined
    * [**Pascal Thubert**] Need to check the exact definition
    * [**Pascal Thubert**] for this charter, rely on fact that IP packets
have IP addresses. In the future, may be able to tag. You're welcome to do
work in advance on something non-chartered. Right now, we're committed to
deliver the deliverables in the charter. Architecture give the overall
view, but not everything on current charter.
    * [**Subir Das**] bullet #2: what is going to be done here and what at
IEEE?
    * [**Pascal Thubert**] right now, 6top not in IEEE. We'll see in the
future.
    * [**Subir Das**] would be good to clarify what exactly could be done
in the IEEE in the charter.
    > Action item: **Chairs** to rework text around what can be done at the
IEEE.
    * [**Thomas Watteyne**] we had a liaison meeting with IEEE to discuss
that, will continue the collaboration.
    * [**Samita Chakrabarti**] The 6TiSCH architecture will be running on
6LoWPAN. 6lo WG would like to have the reviews done as well.
    * [**Pascal Thubert**] Agreed and positive on this. It is on a
case-by-case basis. Let's continue working on this together.
    * [**Pascal Thubert**] personal opinion that a lot of this will work on
a lot of PHYs.
* discussion 6tisch-minimal reviews (**Thomas Watteyne**)
    * [**Thomas Watteyne**] (6tisch-mininal): not a proposed standard
draft. Brian and Suresh questioned this choice during their review of the
doc.
    * [**Brian Haberman**] It seems that they are exploring different ways
to do a minimal 6tisch deployment.
    * [**Thomas Watteyne**] We are not planning to replace it but to
enhance it.
    * [**Tero Kivinen**] should get rid of ... Says for interop testing.
Can't be a standard.
    * [**Brian Haberman**] Should be a BCP, gets the same level of review.
    * [**Thomas Watteyne**] Agreed.
    * [**Tero Kivinen**] Can the minimal setup change? Maybe it is better
that when you create the network you set some parameters (profile)?
    * [**Brian Haberman**] if Informational document, would simplify review
process.
    * [**Tero Kivinen**] There is not a single protocol element there. Only
describing a set of IEEE parameter values.
    * [**Michael Richardson**] is draft-minimal not about getting enough
bandwidth for RPL to run? Sounds much more than informational.
    * [**Robert Cragie**] If this is really a profile that works fine but
it does not belong to IETF.
    * [**Tero Kivinen**] More of a profile than a protocol. The reviewers
indicated too much text was copied from 15.4 standard. Understood that 15.4
hard to read and copying makes it easier.
    * [**Robert Cragie**] Test documents should not become RFCs.
    * [**Thomas Watteyne**] It was never the intention of the WG to publish
Test Descriptions as RFCs.
    * [**Michael Richardon**] After discussion, no objection for -minimal
to become BCP or informational.
* [15.59] <draft-wang-6tisch-6top-sublayer-03> (**Xavi Vilajosana**)
    * Xavi presents the slides. Will focus on comments by Charles Perkins
on mailing list. Main focus 6TiSCH Sublayer and 6top
    * Draft introduces scheduling function but no details, out of scope for
this doc.
    * 6top sits on top of 15.4e, declares the need for Scheduling Function.
    * One question was about the coexistence of minimal and 6top. Recommend
use higher priority for minimal.
    * Example of protocol exchange: container ID designates slotframe,
bundle, chunk, whatever 6top wants to operate on
    * Suggest to define sub-IE to contain commands an response codes.
    * Discussion of 1 vs 2 bytes for slotoffset and channeloffset.
    * Operations: ADD/DELETE/LIST on cell lists.
    * 6P can do version checking, SFID checking, concurrent transactions,
timeouts, etc.
    * [**Pascal Thubert**] on slide 31. Cells are owned by RPL parents.
What if a child needs a slot, how does it go to the parent to ask for a
cell?
    * [**Xavi Vilajosana**] Child can request a cell, but the pool belongs
to the parent. This slide needs to describe the case where the child does
the request.
    * [**Thomas Watteyne**] changes the way the messages are used.
    * Xavi resumes presentation.
    * Next steps: need agreement with IEEE to get GROUP_ID for IETF.
    * [**Thomas Watteyne**] idea is to have a GROUP_ID for IETF so that
IETF can manage the sub-IDs with IANA.
    * [**Tero Kivinen**] There are only 16 GROUP_IDs; it might be
interesting to use IEEE802.15.9's multiplexing where there are 65535 IDs.
    * [**Pascal Thubert**] we have an Interest Group for 6TiSCH at IEEE. We
ask that interest group to help us identify how we can transport our 6top
IEs.
    * important issues raised during review my Charles Perkins:
        * non-local statistics
        * on which cells are the 6top commands transmitted? on -minimal
cells first, then as bandwidth is made available on dedicated cells, on
those.
        * role of SF at boot. Initial behavior?
    * [**Charles Perkins**] on retry policy. Brought it up because in the
past, a draft got rejected because retry left variable.
    * [**Thomas Watteyne**] either in the core of protocol and well-known
to all nodes, or in the SF and can be flexible.
    * [**Thomas Watteyne**] further discussion on the mailing list
* [16.23] <draft-dujovne-6tisch-6top-sf0-00> (**Maria Rita Palattella**)
    * new draft but work has been going on for a while. On-the-fly
scheduling has had 6 revisions already.
    * 3 steps: monitor traffic per node / estimate need / determine
 changes to apply
    * estimate based on node's own traffic and children traffic to be
forwarded
    * Threshold beyond which action is triggered to change allocation
    * at requesting node side, pick slot offset randomly
    * source node can request destination to CLEAR all cells allocated. Can
ask for cells re-allocation if too low a PDR.
    * if destination node could not allocate requested cells, will return
an error message. Source node could provide a completely different list.
    * memorizing cells that were refused to not request them again, or just
random.
    * [**Pascal Thubert**] manage the full transaction with a sequence
number? otherwise, may loose track of which request gets accepted or denied.
    * [**Thomas Watteyne**] we ruled out concurrent transactions, so should
not be a problem.
    * [**Pascal Thubert**] but no retry policy
    * Maria Rita resumes presentation of error handling.
    * Todos: container field inside 6top request; examples of error handling
* [16.39] <draft-thubert-6tisch-4detnet-01> (**Pascal Thubert**)
    * new work taking place in DetNet and PCE, that could be useful to
6TiSCH. Our architecture should be clarified and exposed to other groups so
that they can use it as input. Describe the 6TiSCH tracks. Most text taken
from architecture draft.
    * in DetNet, packet replication on different paths. Whether 6TiSCH
wants to do that is TBD.
    * 6TiSCH can easily do per-link replication (copy only sent if original
did not go through). Replication on different paths would be new.
    * We should agree in this WG what we do before we can tell other groups.
    * Maybe create a separate document just on tracks, extracted from
architecture.
    * [**Pascal Thubert**] who read the document? (5)
    * [**Pascal Thubert**] read and speak up if you disagree.
* [16.47] Announcement second ETSI 6TiSCH Plugtests (**Miguel Angel Reina
Ortega**)
    * after first plugtest at Prague on draft-minimal
    * second plugtest for 6TiSCH will take place on 2-4 February 2016, in
Paris, France, organized by ETSI and hosted by Inria.
    * the scope of the tests is:
        * start from the tests in Prague, and hence continue on
draft-minimal, including multi-hop and link-layer security
        * add elements of the 6top Protocol
        * but still early enough in the process that we are open to
suggestions.
    * same group of experts as last time. Will put together test
specifications, will do tech support during plugtest and will report to EC
after the event.
    * learned from first plugtest that most issues were discovered before
the event. So will strive to issue test documents and golden device early.
    * website launched in the next few days.
    * sponsored by EC, event is free of charge.
    * Third 6TiSCH plugtest envisaged at IETF96 (Berlin).
* [16.54] Announcement 802.15.12 work in the IEEE (**Charles Perkins**)
    * 15.LLC Interest Group voted to form Study Group that had first
meeting recently.
    * general goal is to make 15.4 easier to use. Right now, a lot left to
implementors.
    * should be as easy to use as 802.11 and 802.3
    * interface for Key Management Protocol (KMP) and L2 routing.
    * 802.15 has growing awareness of 6TiSCH thanks to 6TiSCH interest
group at IEEE, that reports at every meeting about 6TiSCH progress
    * on the todo list: dispatch code (a la Ethertype), 15.9 and 15.10
alignement with LLC, etc.
    * provides link to presentation on LLC on IEEE side
    * at January meeting: submit PAR (Project Authorization Request) and
CSD (Criteria for Standard Development)
    * [**Pascal Thubert**] how is it organized? 802.15.12 will not be
merged into 802.15.4 release?
    * [**Bob Heile**] (802.15 chair):
    * [**Thomas Watteyne**] wat 6TiSCH, we plan on just continuing our work
at the current fast pace. Discussion and coordination with IEEE will happen
in parallel.
    * [**Charlie Perkins**] agree that both groups want the same thing.
Other "customers" also out there.
* [17.09] Other Business
    * No other business.
* [17.10] Meeting ends