1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 140425_webex

View History

Webex CALL, April 25th, 2014

Conference

  • Webex Link
  • Live etherpad for minutes
  • Topic: 6TiSCH Weekly
  • Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
  • Meeting Number: 206 802 913
  • Meeting Password: sixtus
  • CCM: +14085256800x206802913

Recording

Slides

Action items

  1. [Pascal] to Doodle for the date of the plugfest, Sunday morning, afternoon, Thursday evening, Friday afternoon
  2. [Pascal] to ask to the ML if everyone agrees on having a new plugfest.
  3. [Pouria] and [Raghuram] to rename the draft and reset counter to 0

Agenda

  1. [10min] Administrivia
    • Approval agenda
    • Approval minutes last call
    • IETF 90 in Toronto: Registration opened;
    • PlugFest ?
    • draft-sudhaakar-6tisch-coap last call complete
  2. [10min] 6MAN: draft-thubert-6man-flow-label-for-rpl
  3. [10min] Status on 6top discussions
  4. [20min] Terminology discussion
  5. [2min] Next meetings
  6. [1min] AOB

Minutes

Meeting starts at 09.05 PST

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Pascal Thubert
  3. Dominique Barthel

Attendance (alphabetically)

  1. Diego Dujovne
  2. Dominique Barthel
  3. Kazushi Muraoka
  4. Pascal Thubert
  5. Michael Richardson
  6. Pat Kinney
  7. Patrick Wetterwald
  8. Pouria Zand
  9. Randy Turner
  10. Rouhollah Nabati
  11. Xavi Vilajosana

Discussion

  1. [8:05] Meeting starts
  • [recording starts]
  • note well
  1. [8:07] Administrivia
  • Approval agenda
    • Agenda is approved
  • Approval minutes last call
    • Last call minutes are approved
  • IETF 90 in Toronto: Registration opened;
  • Registration for IETF 90 in Toronto is open
  • Recommendation to reserve soon is someone wants to stay in the Event hotel.
  • PlugFest ?
    • Thread started with people in 6lo,rpl,6man and 6tisch.
  • Proposing to make a big event.
    • [Pascal] suggest Xavi chairs the event.
    • [Xavi] needs to check if he can be there; will know next week.
    • [Michael]: is the plan to have it during the IETF week?

  • Discuss about WHEN

    • outside of the main week might be a problem to invite people to get them.
    • network is only setup during the IETF week
    • [Michael] suggest to have it on Saturday or Sunday as are good days.
    • [Pascal]: Sunday afternoon.
    • [Michael], might be conflicting with something. Suggests Sunday morning.
    • [Xavi]: what abou tFriday afternoon? Michael: there will be no (IETF) network.
    • 6TiSCH meeting date? will not be known anytime soon.
    • last time Plugfest was in the morning before 6TiSCH meeting, but still created some conflicts.
    • evenings? not that many available.
    • [Xavi]: thinks better attendance if within IETF week and close to 6TiSCH meeting.
    • [Xavi]: what about 7pm?

  • ACTION: [Pascal] proposes a doodle with different options to see opinion on the ML (all 3 6lo, ROLL, 6TiSCH)

    • [Michael] Requirement to announce it very very soon.
    • [Pascal] Budget for the meeting room is one of the problems. Also for attendees' bedroom.
    • [Pascal] Michael do you get feedback from ROLL people to participate?
    • [Michael] No
    • Tentative: OpenWSN demo, Pascal+Thomas upgraded demo

  • ACTION: ask to the ML if everyone agrees on having a new plugfest.

  • draft-sudhaakar-6tisch-coap last call complete

    • no objection raised. the draft is adopted as a WG document
    • ACTION: Pouria, Raghuram to rename the draft and reset counter to 0
    • The document MUST be the same (except title and version)

  1. [8:22] 6MAN: draft-thubert-6man-flow-label-for-rpl

    • [Pascal] The early versions of RPL uses the Flow Label
    • Changed to HBH
    • If the packets circulates out of the RPL domain requires IPv6 in IPv6 encapsulation
    • RPL HBH Option is 6B
    • TF bits tell us whether the traffic class and flow label are elided.
    • draft-thubert-6man-flow-label-for-rpl proposes to use the flow label to carry what the HBH option contains.
    • This saves bytes.
    • [Randy]: real value? the real value of the proposal is to avoid the Ip in IP encapsulation. 15.4g PHY layer nodes as those in the smart grid does not have a problem with HBH header as they are not running using batteries. Slowing down data rate, increases time to transmission, so if the protocol can safe some bytes that would be good.
    • [Pat] real issue is slow datarate.
    • [Randy] Concerned on violation of the flow label meaning by this usage.
    • [Pascal] Talked to the persons who worked on that topic as well. The goal of the flow label is to enable good load balancing in the core of Internet. What happens at the edges, what is the role of the flow label there? What we need is that 6man understands this gain
    • There is a thread at 6man that summarizes this discussion.
    • [Michael] the concern is that an LBR for example changes the flow label.
    • LBR will need to maintain state for packets coming inbound
    • Outbound are packets leaving LLN. Packets going outbound does not have a problem with the flow label.
    • Because cannot trust the inbound flow label to do the routing, might require an IP in IP header on inbound packets. The use of the flow label is really useful at the core. Inside the LLN, the objective of the flow label is lost, then it can be used by another thing.
    • [Pascal] try and if 6man insists on keeping flow label meaning then negotiate.
    • Waiting for feedback from ISG.
    • [Pascal] what we need is expression of interest on the 6man mailing list, then presentation by [Pascal] at Toronto and adoption by WG and resolve technical issues.
    • Brian Carpenter (6MAN, lead author of Flow Label RFC) appears OK with this draft.

  2. [8:43] Status on 6top discussions

    • [Xavi] good progress on 6top interface work, now looking at how nodes talk to one another to negotiate slots
    • proposal wrapping 802.15.4e IE RPC Yang model to enable multiple implementations eg coap based
    • reminder on communication interface: GET and SET to MIB. Currently changing interface to do softcell negotiation. Requester provide list of candidate cells, receiver replies with list of cells to change to. *wrapper IE would encapsulate COAP to reuse the mechanism from the 6Tisch CoAP draft, and parser code is well known
    • [Randy] how is 6top-6top traffic scheduled?
    • [Xavi] that would be the Same methods as in the PCE case. Proposal is target node address is URI-Host but could be elided from knowledge of MAC
    • describes Uri structure.
    • fragmentation and use of CoAP block option: CoAP proposes fixed size blocks. Which one to chose?
    • Impact when compressed in CBOR?
    • show softcells negotiation dialog. URIs will be shorter than those shown on the slide.
    • 6top will run the coap parser which we wish will be the same as
    • [Pascal] like the idea the Uri host can be elided (because source is known from IE). A la 6LoWPAN.
    • [Xavi]: however, the CoAP parser will be the one that put blocks together. One needs to provide that info to the parser.
    • In summary: clear roadmap, RPC model, wrapper IE and use generic CoAP parser are firm.
    • Still open: CoAP blocks or app level fragmentation; error codes; observe at 6top?
    • Beware of reproducing all CoAP at application level!!

  3. [8:56] Terminology discussion

    • skipped due to lack of time. Maria-Rita is not on the call anyway.

  4. [8:57] Next meetings

    • Monday 4/28 8-9am PDT security
    • 6top to be confirmed
    • otf to be confirmed
    • Friday 5/9 8-9am PDT -6tisch webex

  5. [8:57] AOB

    • No other Business; adjourning.

  6. [8:59] Meeting ends

Updated