[6tisch] Minutes, 11 March 2016 interim, 6TiSCH WG

["Pascal Thubert (pthubert)" <[e-mail]>]

Note: timestamps in PST.

Connection details

  *   Date: 7-8AM Pacific: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2016-03-11&sln=15-16
  *   Webex recording:https://cisco.webex.com/ciscosales/ldr.php?RCID=8dabef427d86849b5a91b0a138fafbd1
  *   Meeting Slides: https://bitbucket.org/6tisch/meetings/raw/be4f76125c8db0d80556b5f651a30e567eff7039/160311_webex/slides_160311_webex.ppt

Taking notes (using Etherpad)

  1.  Michael Richardson
  2.  Pascal Thubert
  3.  Thomas Watteyne
  4.  Xavi Vilajosana

Present (alphabetically)

  1.  C-Y Lee
  2.  Diego Dujovne
  3.  Dominique Barthel
  4.  Jonathan Munoz
  5.  Lijo Thomas
  6.  Maria Rita Palattella
  7.  Michael Richardson
  8.  Michel Weillette
  9.  Nicola Accettura
  10. Pascal Thubert
  11. Pat Kinney Kinney
  12. Qin Wang
  13. Rene Struik
  14. S.V.R. Anand
  15. Shalu R
  16. Tengfei Chang
  17. Thomas Watteyne
  18. Xavi Vilajosana
  19. Zhuo Chen

Action Items

  1.  Pascal to progress on the 6p encoding with Pat and 6T IG
  2.  Diego to publish refresh prior to cut off

Agenda

  *   Administrivia [2min]
     *   Approval agenda
     *   Approval minutes last call
  *   Misc and Charter news [5mn]
  *   Preparing IETF 95 [10mn]
     *   agenda, who's coming?,
     *   other WG of interest & interaction)
  *   ANA and IANA needs and status [10mn]
  *   6p and Sf0 issues [QSP]
  *   AOB [1min]

Minutes

  *   [07.04] Meeting starts *
     *

*        [07.0x] Administrivia [2min]

     *   Approval agenda
     *   agenda is approved. No issues raised
     *   Approval minutes last call
     *   last call minutes are approved. No issues raised.

*        [07.xx] Misc and Charter news [5mn]

     *   There is a new charter, congrats.
     *   aim to produde SF0
     *   provide requirements for detnet
     *   keep working on the architecture
     *   YANG data models left to later phases.
     *   secure 6tisch neThomas Wattteyneork bootstrap.

*        [07.xx] Preparing IETF 95 [10mn]

     *   agenda, who's coming?,
     *   Monday 4th 14 to 15.30 (6pm to 7:30pm in CET)
     *   preliminary agenda
     *   draft cut off date in 10 days.

o   objectives: - update sf0 draft (diego) - update and rename 6top sublayer to 6top protocol.
- terminalogy draft to be clean up and publish
- call for adoption for 6p and sf0
- report the PT and talk about the Berlin Plugtest

o   Pascal: would like to see a status on where we are with the security work, which has been interrupted for a long time.

o   Michael Richardson: can produce 2 slides to position the work and see where we are. Willing to speak but remotely since not attending Buenos Aires.

o   other WG of interest & interaction)

*        [07.15]_ANA and IANA needs and status [10mn]_

     *   Pat Kinney outlined different choices for the IETF IE
     *   Pat Kinney: 6TiSCH should ask for a OUI

o   Pat Kinney: there are 3 options. they are exclusive.

        *   Vendor specific ID is in the standard and can be used. the Vendor Specific ID requires us to use an OUI but we cannot do that.
        *   a second choice is to get an ID in IANA. There is a procedure. We need a formal request from an IETF representative.
        *   Final option is ESDU IE meant to use for an upper layer, the MAC layer passes it to the upper layer without checking it.

o   Pascal: This will still require a dispatch type but handled by IEEE. Could the 6T IG discuss that in Macau next week?

     *   Pat Kinney: will be presenting this to the interest group that will look into this as an standardization group whereas we see it more as a user group.
     *   Thomas Watteyne: option 2, IETF will produce an RFC that will tell IANA explaining how this ID is managed.
     *   Thomas Watteyne: how do we proceed? do we have this discussion in the ML? do we have a volunteer to read and see what are the pros and cons of it.
     *   Pascal volunteers to evaluate the options.
     *   Pat> on the ESDU case the 6top can come with the format.
     *   Pat Kinney to send a msg to the reflector indicating what is the discussion and the resolutions.
     *   Michael: does the wg prefer the option 2?
     *   IEEE allocates one of these payload IE group IDs to the IETF. The IANA is the registry for the IETF value.
     *   Choice 2 is 2 byte shorter.
     *   Pascal: No: we will need some dispatch with the OUI as well as there are few of these.
     *   Pat Kinney: why not a header IE. Do we need a header IE?
     *   Thomas Watteyne: 6top packets will be transported in the payload IEs. So no header IEs are needed as far as we can tell now.

*        [07.31]_6p and Sf0 issues [QSP]_

     *   proposal to indicate what the 6p protocol adds a requirement to the SF so it indicates the metrics and statistical operations used to operate.
     *   Xavi proposed a text.
     *   Diego agrees with the text
     *   The requirement from 6p is a SHOULD.

o   Pat Kinney are there any statistics mandatory? would we assume defualts?

o   Thomas Watteyne: Algorithm made from many types of statistics. No need to list the collected ones. MUST can be empty, since we may not use always statistics. Default metrics?

     *   Thomas Watteyne: Default metrics, we do not know if we can default something at that moment
     *   Pat Kinney: should indicates me that I do not have to provide it.
     *   Thomas Watteyne: proposes MUST provide ..., if use by the algorithm. ACTiON: Diego to propose the reworded text.
     *   add 8bit token field to the 6P header.
     *   match a request to a response.
        *   do we really need a token? -- consensus is yes. It is needed, not only because it enables to support concurrent transactions but also because it enables to differentiate one request to the previous one.
        *   Diego: what about the timeout. Could we use the timeout.
        *   Qin: Do we need 8 bits for the token? as this is for a pair of nodes.
        *   PT: reduce it to less bits and use a sequence number.
        *   can we use the ack? -- clarification: referring to l2 ack. The ack does not tell that the packet has been processed but only received. It is useless in terms of semantics of the protocol. --
        *   can a child ask more cells before receiving an ack? -- in the 3 phase negotiation the 3rd message is like a 6top ack message who confirms and closes the transaction. the 6top layer ack in that case is similar to the MAC layer ACK. --
        *   starting 6p transaction from receiver.
        *   if B is the parent and B has granted the cells to A. Is there a mechanism to reclaim that cells.
        *   Pat Kinney: use lease ?
        *   Xavi: use Delete request

o   Zhuo: do we have a timeout scheme for expiration in case that a node is disconnected from the network?

?  Pascal: In case of a disconnect and reconnect we need to resync the state

?  Proposal on the ML was ti use a bitmap instead of specific cells. Let a node when joins get a bundle and then use a bitmap to decide what cells of that bundle are active.

        *   to be further discussed.

*        [08.10]_AOB [1min]_

     *   Authors need to have a working session to work SF0 and 6P before cutoff
     *   we need to have a call the 25th March?
     *   PT: If not we coudl have a security discussion? can propose to the ML to recap on security...

*        [08.xx] Meeting ends