Minutes for 6TISCH at interim-2015-6tisch-16

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at interim-2015-6tisch-16
State Active
Other versions plain text
Last updated 2015-11-27

Meeting Minutes

   ## THIS IS A DRAFT!!! ##

# Minutes, 27 November 2015 interim, 6TiSCH WG #

Note: timestamps in PST.

Connection details

* Date: 7-8AM Pacific
* Webex link:
* Webex Recording:
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/150925_webex * Slides:

Taking notes _(using Etherpad)_

* Diego Duvojne
* Thomas Watteyne
* Michael Richardson
* Pascal Thubert
* Tengfei Chang

Present _(alphabetically)_

1. Thomas Watteyne
1. Pascal Thubert
1. C-Y Lee
    1. Call-in User_4 (did)
1. Diego Dujovne
1. Jonathan Munoz
1. lavanya (didn't identify him/herself)
1. Malisa Vucinic
1. Michael Richardson
1. Michel Veillette
1. Nicola Accettura
1. Pat Kinney
1. Sedat Gormus
1. Tengfei Chang
1. Xavi Vilajosana
1. Zhuo Chen

Action Items
* Pascal to publish Architecture draft update
* Xavi to publish Minimal draft update
* Chairs to propose new charter to responsible A-D (Brian)
* Thomas to push adoption e-mails to the 6TiSCH ML
* Zhuo to kick a ML discussion on whether P2P routing and HbH scheduling apply
to IP forwarding, G-MPLS, or both


* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
* Charter Update _[15min]_
* Minimal Support: status _[15min]_
* Architecture: status and directions _[15min]_
* 6lo drafts (BBR and 6LoRH) _[10min]_
* AOB _[1min]_


* _[07.??]_ Meeting starts
    Agenda change: Propose Xavi to start first. No opposition, approved.
    Minimal is first.

* [07.06]  Minimal Support: status _[15min]_
    * large list of issues created in bitbucket
    * last issue (#3) needs to be discussed
    * Xavi goes through summary of all changes. Made changes following the
    recommendation from the reviewers
        * editorial changes
        * changes to RPL
        * what happens if the network is not multi-hop
    * intended status: no
    * [Michael] no intended surveys, but BCPs ("profile") say that, "when using
    protocol X in context Y, you SHOULD use parameters Z". This is for
    operators rather than implementors. Minimal says you to use RPL, which you
    would not implement if you were just using IEEE802.15.4e. AD asked whether
    this will be used beyond a plugtest. * [Pascal] node requirements for IPv6
    is informational, it does not mandate behaviors. Just information about the
    mote; but doesn't use "MUST". Minimal draft does say you need to compute
    the RPL rank according. That draft is what this is specified, so it's not
    just setting parameters. Think we are beyond informational. * [Malisa]
    agreed with Pascal & Michael, would make sense to publish as standards
    track. The DTLS profile that is a similar scope, is intended to be
    published as standards track. * [Michael] RFC6434 list RFCs that you are
    expected you should look at. RFC6434 should not have been informational.
    Strictly speaking, informational are not standards. * [Michael] we have a
    BCP number, but no informational numbers. * [Thomas] Consensus on Standards
    track. How do we proceed? We are building on top of it Default setup on top
    of it. * [Michael] A good answer. We have not articulated that. * [Thomas]
    It is important to publish this. Standard track. RPL rank no anywhere else.
    This is the spec. * [Pascal] Nobody wants informational, better standard
    track. Recommendation for developers than for deployers. * [Thomas] Discuss
    on the ML. * [Pascal] To get an RFC number, highly respected. Already
    implemented, tested. * [Thomas] Anything else? X: Publish it. * [Thomas]
    Send it to the ML and send a note. * [Pascal] Copy the link to the diff to
    see the changes. Thanks. Great work.
* [07.25] Charter Update _[15min]_
    * [Pascal] Starts discussion on Charter. We are closing Architecture and
    Minimal. Plan: Architecture and Minimal published, start a new charter. *
    [Pascal] Charter: Is a contract with the IESG, 5 elements. 6top sublayer, 
    6top protocol. Lots of work on IEEE, there is a 6tisch interest group. The
    plan is go to standards track and then go to IEEE for next gen. Second
    item: Scheduling Function. We intend to keep SF at the IETF. SF0 standards
    track too. Tracks on discussion on Detnet. Secure Bootstrap on the ML, keep
    it up. Architecture next step. Take the work back to the WG, wait until
    completed the WG and publish it.
* [07.30] Architecture: status and directions _[15min]_
    Terminology tickets: 38 and 39. Update the link on Architecture. Next step
    to publish -09 and then discuss on the ML and work on the tracks. The
    architecture is built on too many pieces. Capture more detailed
    information, can be on the specification level. Hop-by-hop scheduling: we
    did not really work on it, we have seen interest on it, Chonggang provided
    help. Make tracks work. Fragments forwarding listed on Archie forever,
    either work on it or live without it. Clarified dependencies. More explicit
    on dependencies. * comments from Kris is that we have different ways of
    doing forwarding, routing and scheduling. This turns into many
    combinations, which is complicated. * proposal is to select a small number
    of combinations * Pascal talks about the different forwarding models (slide
        * we now have IPv6 forwarding+RPL+static
        * we are now working on now have IPv6
        forwarding+RPL+neighbor-to-neighbor (SF0) * we have work in front of us
        with reactive P2P (RPL P2P or AODV v2)/ Charlie Perkins has indicated
        he might be interested in working on reactive P2P. That's a great fit
        with hop-by-hop scheduling. * question is whether we want to classical
        IPv6 forwarding.
    * Pascal indicates this table locks the number combinatorial combinations.
    This table is the proposal. That table is in the draft. * [Zhuo] saw that
    in the routing there is PCE. * [Pascal] PCEP is the protocol to install
    routes. PCE is the component which calculates the routes. Route computation
    happens inside the PCE. Forwarding happens in the devices. In centralized,
    the control plane centralized in the controller. In RPL, the routing is
    distributed. PCE is not a protocol. What would you like in that box? At
    this stage we don't have an idea what the protocol is. * [Zhuo] In my mind,
    thinking about track with hard cells. Track with soft cells. Something in
    future is track configured by the node. * [Pascal] that's what we have put
    in the lowest row the HbH scheduling will allocate soft cells. * [Zhuo] can
    that be a track? * [Pascal] had that discussion with Thomas, it's our
    decision. * [Pascal] alternatives:
        * we install the HbH in the routing table, or we use track forwarding
        in this table. Decision was not made yet. Proposal is to keep IPv6
        forward. We are nowhere on the GMPLS way. If we want to go quickly to
        market. Let's take that to the ML.
    * action item: Zhuo to start a discussion on the ML
    * [Zhuo] OK
    * [Thomas] +1 on the table. Great overview of the roadmap. When will be
    published. * [Pascal] submit -09 now, but pushed to IESG very late in the
    process * [Pascal] RFC4861 is clearly designed not work in NBMA case. This
    is the case of the 6TiSCH mesh. Ralph asked us to work on this. * [Thomas]
    second idea to publish it ASAP.
* [16.57] WG adoption calls on both drafts, we need to answer that call to
weight on the adoption. This is very important for the work we do at 6TiSCH.
    * BBR is what we have in our architecture
    * 6lo routing dispatch is what we need to compress RPL. 6TiSCH has been
    complaining about that. 6lo is ready to adopt this compression mechanisms.
    * [Thomas] please send the initial call e-mails to * Action item: Thomas to
    push adoption e-mails to the 6TiSCH ML *
* _[08.??]_ Meeting ends