[Roll] Minutes Webex 12 September 2014, 6TiSCH WG

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 12 September 2014 17:30 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D71A802F; Fri, 12 Sep 2014 10:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level:
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clt1Wy1Dn9Pg; Fri, 12 Sep 2014 10:30:05 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A32B1A7D81; Fri, 12 Sep 2014 10:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43370; q=dns/txt; s=iport; t=1410543004; x=1411752604; h=from:to:cc:subject:date:message-id:mime-version; bh=1/gt1SuSMbW4OdINc1prRtOiyueEWD7u2lQPQK0em/o=; b=GpiJNcGw8e4/fbblb+yTU7PcIuGG2lWJdDyet2LZKjKoNv5BhYQXx70h xWoQuKTNdz1/ZAEZ9cVQpeHpjmSVWKYblxlwbAz4bhdMR3EbPl5F83psi b2G1jMiUjD9qXN4m9GEILUHt7t/MrToYLJ8jJkTtI/kNQ7UAmhp1+qXFq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAOwsE1StJV2Z/2dsb2JhbABGGoJHRlNXBMhxh0wBgRAWeIQFAQQtTBIBKgsLAT8mAQQODROIJw02vVcBEwSMHgGBHoE4BwEBHi0EEYMlgR0FkU2EN4I9kG+JF4NhbAEEgQEJFyKBBwEBAQ
X-IronPort-AV: E=Sophos; i="5.04,514,1406592000"; d="scan'208,217"; a="77433043"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 12 Sep 2014 17:30:02 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8CHU1UK006222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 17:30:01 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.160]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 12:30:01 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: Minutes Webex 12 September 2014, 6TiSCH WG
Thread-Index: Ac/OrveXgbqBszvdT5Wmsz1EG7578Q==
Date: Fri, 12 Sep 2014 17:30:00 +0000
Deferred-Delivery: Fri, 12 Sep 2014 17:29:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842DAD973@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.22.3]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD842DAD973xmbrcdx01ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/qUKpxBQaEouuPZLWTMk7RW7ssUA
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: [Roll] Minutes Webex 12 September 2014, 6TiSCH WG
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 17:30:09 -0000

Dear all,

The 6TiSCH bi weekly call was focused on the compression of the RPL option. The various options were considered.

>From the call, it appears that the uncompressed form of the RPL option in the HbH is not acceptable for 6TiSCH due to the size of the frame (127bytes). So we need a compression solution from either ROLL or 6lo and are debating which one we'd prefer see. But we need to well advanced in November when the minimal draft is due to IESG.

It is also appears that transporting 20 bits of random data in the flow label as prescribed in RFC 6437 is not acceptable in the LLN. We need to obtain an exception from 6MAN for the LLN. draft-thubert-6man-flow-label-for-rpl-05 concentrates on that exception and the text to use the flow label for RPL was removed, to be placed in an ROLL draft if the group leans in that direction.

The discussion on whether it is better to opt for a ROLL solution (based on flow label) or a 6lo solution was debated. Please find more below, included the minutes and the recording:

Resources

  *   Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=8b6415fd8dff42a99fccf118ff2faa82
  *   Wiki: https://bitbucket.org/6tisch/meetings/wiki/140912_webex
  *   Slides: https://bitbucket.org/6tisch/meetings/src/master/140912_webex/slides_140912_webex.ppt

Taking notes (can't live without them :) )

  1.  Xavi Vilajosana
  2.  Thomas Watteyne

Present (thanks guys!)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  Ariton Xhafa (call in user 3)
  4.  Dominique Barthel
  5.  Elvis Vogli
  6.  Kazushi Muraoka
  7.  Martin Turon
  8.  Michael Richardson
  9.  Pat Kinney
  10. Patrick Wetterwald
  11. Paventhen Arumugam
  12. Qin Wang
  13. Rene Struik
  14. Sedat Gormus
  15. Xavi Vilajosana

Action Items

  *   Pascal will post to 6lo and ROLL indicating that these minutes contain a discussion on the RPL option for 6TiSCH
  *   Martin should rebound on that

Agenda

  *   Administrivia [3min]
     *   Approval agenda
     *   Approval minutes last call
  *   Minimal RPL support for RPL option [30min]
  *   Continue Flow Label vs. 6LowPAN discussion [20min]
  *   AOB [2min]

Minutes

*        _[08.05] Administrivia

     *   last call minutes are approved. No concerns are raised.
     *   Agenda is approved. No concerns are raised.

*        [08.10] Minimal RPL support for RPL option [30min]_

*        Can 6TiSCH live with the HBH ?

     *   [Thomas]It works but would be better to have some compression
     *   [Xavi] can we leave the draft not specifying this?
     *   [Michael] we cannot that otherwise no interop
     *   [Pascal] agreed with Michael, implementations need to know what to implement for interoperability. we must be clear on what we use.
     *   [Pat Kinney] Do not like HBH. It is not a think that may live for a long time.
     *   [Thomas] I support that and we need to do something quick.
     *   [Pascal] Zigbee IP uses 15.4g with large frames so 8Bytes are nothing compared to their packets so they can survive with that.

*        Can we reuse the flow label ?

     *   [Xavi] what propose? flow label is not adopted yet, 6lo not working yet on HbH compression
     *   [Pascal] 6man did not reject it. we need to have 6man think about the rule that a flow label cannot be changed.
     *   [Thomas] Currently 6man requires the end to end flow label.
     *   [Michael] random on a per-flow basis
     *   [Pascal] we still carry 20 bit across the LLN to satisfy the core. We need to change those rules anyway.
     *   [Pascal] 6man chairs will people to support and want a good reason.
     *   [Michael] You got consensus on the 6man ML so we can discuss about that. ROLL Mail trying to move that forward. My take is that we have consensus from 6man, that when a packet enters the LLN we can reset the flow label field. It is consistent with zero-flow label existing practice. Using the flow label on a hop by hop basis in the LLN is our matter then.
     *   [Michael] There was silent when asked for consensus about that.
     *   [Martin Turon] Are we talking about the RPL option described in RFC6553?
     *   [Pascal] yes

*        Should we go to ROLL or 6lo?

     *   [Pascal] Roll approach: we do something in ROLL? Other approach: we propose a solution in 6lowpan that works in 6lowpan world only. The RPL version might use the Flow Label but some people do not like. The 6lowpan approach can have some benefit but might be limited to 6lowpan networks. According to 6lo, hbh header needs only to be compressed in 6lowpan networks. Will we be able to have something by November?
     *   [Thomas] There are things that go fast. Do you have a description of both approaches?
     *   [Pascal] The big difference is whether we compress in 6lowpan or in the flow label. The 6lowpan consumes dispatch resources or next header resources.
     *   [Thomas] Also, there is the need to clarify the exception to the rule for the flow label. Break the rule and define an argument.
     *   [Michael] Is there some place where we can put the rank (changing part)? instance id can go in the flow label and the rest somewhere else. can the constant part go in the 6lo context? header compression can use the context.
     *   [Pascal] we need a stable work group document in 2 months. We need to decide what space in the current headers we use, it is only that.
     *   [Ariton] Would like to see slides on the problem.
     *   [Martin] There is something compelling on using 6lowpan compression. But it exposes a problem in 6lowpan header, it is not clear what the ordering should be or it should end.
     *   [Pascal] Well, RFC4944 is clear on the order, and new drafts can be clear as well. e.g. Carsten's draft imposes his new dispatch right before IP_HC.
     *   [Pat] what can happen if both approaches become standards? would everything work the same?
     *   [Pascal] We could say 6lo if present else HbH if present else flow label. Trouble is with source router packets in non-storing going down the DODAG to the device; they may or may not carry a RPL option, and if the do not but yet have a flow label, then we might be confused.
     *   [Martin] take into account that in the future more protocols will be there and we cannot consume many bits in 6LoWPAN compression for a specific protocol such as RPL. Can we accept new routing protocols with the Flow Label solution?
     *   [Pascal] there is one bit left in the flow label. So we can do what we do with dispatch. If first bit is zero then the FL is used by RPL. Other settings with first bit to 1 reserved for other usages, like another routing protocol in the same LLN.

Cheers,


Pascal