Clone wiki

meetings / 130517_webex

Minutes Webex 17 May 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Thomas Watteyne

Present (alphabetically)

  1. Alfredo Grieco
  2. Guillaume Gaillard
  3. Maria Rita Palattella
  4. Pascal Thubert
  5. Pouria Zand
  6. Raghuram Sudhaakar
  7. Ted Lemon
  8. Thomas Watteyne
  9. Tom Phinney
  10. Xavi Vilajosana




  • BoF in Berlin [40min]
  • Bootstrapping [5min]
  • 6tus split [15min]


  • [08.05] Meeting starts
  • [08.06] Pascal presents agenda
  • [08.05] visibility of 6TSCH
    • Goal: present Ted with all the information
    • visibility of the work is everybody's responsibilities
    • what we alredy did: paper at Industrial Track esIoT. Maria Rita to present it in Taiwan.
    • we are participating in IERC Cluster Book 2013.
  • [08.07] BoF in Berlin
    • Pascal presents slides.
    • BOF: full name and acronym: Deterministic IPv6 over IEEE802.15.4e Timeslotted Ch.Hopping (6TSCH)
    • AREA: INT
    • Two chairs:
    • [TED]:
      • It's a good idea to have the WG chairs not do most of the work.
      • Should the Chairs of the BOF different than the Chairs of the working group? There is no strong requirement but the constraint is the division of work.
    • [Pascal] Thomas and Pascal are candidates for chairing the working group. Thomas and Pascal initial chairs of the BoF but this can be changed.
    • Requested 2.5h. Day? Per Adrian's remark probably Monday or Tuesday since long session requested.
    • [Maria Rita] It would be good to request a particular date. Doodle?
    • [Thomas] Unfortunately, we can not request much. We can make a suggestion (at most), but IETF schedule will depend on lots of constraints.
    • Agenda:
      • first 30 min about discussing model and architecture (TSCH). Identify missing parts and weak items. Explain why this is a IETF work. Why not at IEEE. Routing area work, including ROLL and other PCE, RSVP, NSIS.
      • then 60min for work items. Then done after 1.5h
      • last 1h for discussion, but will be clear whether WG has been create
    • [Ted]: using RPL in L2 or L3?
    • [Pascal]: L3. We are not in competition with L2R for example. We use RPL as is, we might define a OF, but no changes to RPL.
    • [Ted]: asks because need to coordinate with IEEE.
    • [Pascal] will talk to Norman Finn who is at IEEE meeting this week
    • [Pascal] asks for comments about BoF request form
    • [Xavi] is the term "routing" not too restrictive in the sentence?
    • [Pascal, Thomas] good point. Need new work. "Operation? Management?" What about security?
    • [Pascal] we could use "architecture" which covers everything.
    • [Alfredo] we could use an "architecture that supports centralized and distributed routing and resource allocation over a TSCH based mesh"
    • Pascal modifies the slides live.
    • [Thomas] Would be good to have a written backup (charter, requirements, architecture, etc.) we can point people to during questions. The architecture draft and possibly requirements drafts should be our background document.

      The attached slide are the final ones, i.e. the ones with Pascal's live changes.

    • [Pascal] goes through recommendations from Mark
      • we need to control the scope, don't scare people off.
      • if too complex, we need requirements draft. Analyze what needs to be done before doing the work. One case: centralized computation. There's a lot to be done. Very unclear so we discussed whether we can commit to that draft or write requirements.
      • [Thomas] requirements draft, if we have a question of gap analysis we should refer to the requirements draft. So we need to make sure that we have this information in the requirements draft.
      • [Ted] much easier to get approved
      • We need to inspire confidence that we can achieve. We need to say that what we plan on doing is doable. There are already several known issues (ISA, WHART, ZIP). We don't plan to do the work at 6TSCH, we can push to other WGs.
      • Clear understanding of gap analysis. We already have a gap analysis as part of the charter.
    • Description of the BOF:
    • [Tom] let's use the term "sublayer" for G-MPLS
    • [Pascal] Done.
    • [Pascal] Will also add links to the drafts already published.
    • [Pascal] all good?
    • [all] no objection
    • [Pascal] what's the state of COMAN? Probably just ML
    • [Pascal] Marc suggested 50 attendees, might be more, put 60
    • [Pascal] to send slides to Ted
    • [Ted] need to include how many people on the ML.
    • Show activity:
      • Weekly call, Draft and Repos, ML 135 members.
      • [Thomas] I'm convinced that we have the dream team to do this work.
    • [Pascal] Will do. Currently 135.
    • Conflicts to avoid with the following groups or pre-groups
      • ROLL
      • 6MAN
      • COAP
      • COMAN
      • INTAREA
      • RTGAREA
    • external relations:
      • keep external informal relations and participate in other groups.
      • heathrow group
      • ISA100.20
  • Network Bootstrapping
    • Maria Rita presents slide.
    • how do we setup the network?
      • 15.4e network formation are not defined.
      • several optional features
      • several issues at network formation.
    • 6tus tries to cover that
    • security and authentication setup phase. Before defining and distributing the schedule, we need a mechanism to avoid collisions between the nodes. How do we collect all the
      information so the PCE can compute the schedule?
    • [Thomas] In the current 6tus draft there is a network bootstrapping section. How to use that in the presence of a PCE? is that correct?
    • [Maria Rita] 6tus draft needs to define something on how the network interacts with the PCE.
    • [Pascal] Discovery of the PCE. Talked to JP Vasseur. The location of the PCE can be advertised in the routing protocol, using RPL, DIO, placeholder.
    • [Maria Rita] RPL in both directions, DAO msgs to the PCE as well.
    • [Thomas] This does require RPL to run on the backbone.
  • 6tus split
    • Thomas presents slides.
    • Fear is that 6tus is becoming bigger and bigger. It becomes to big. Michael pointing that we need to keep it as one until BoF and identify how to split it.
    • Goal of this discussion is to gather some ideas about how to split the draft, not to split it right away. Split may happen after the BoF, when we have enough material.
    • 4 pieces:
      • 6tus specification
      • 6tus for centralized: 6tus provides commands to the PCE. How the PCE talks to the nodes is another challenge.
      • 6tus for distributed: negotiation protocol
      • 6tus support for label switching: how to manage the labels and switch packets on a track.
    • [Pascal] protocol between the PCE and 6tus should be in a different document.
    • [Xavi] Switching needs some little mechanism that needs to be described out of the architecture draft.
    • [Pascal] In conclusion, architecture we expect a lot from it, we need a good description of all components and that must be ready before Berlin.
    • [Thomas] Time to start working on that too.