IETF Logo Mail Archive

Re: [6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?

Thomas Watteyne <thomas.watteyne@inria.fr> Wed, 05 July 2017 10:05 UTC

Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27591328D4 for <6tisch@ietfa.amsl.com>; Wed, 5 Jul 2017 03:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.419
X-Spam-Level:
X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GewxDNoFGll8 for <6tisch@ietfa.amsl.com>; Wed, 5 Jul 2017 03:05:31 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EBC1328D3 for <6tisch@ietf.org>; Wed, 5 Jul 2017 03:05:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.40,311,1496095200"; d="scan'208,217";a="230513709"
Received: from mail-yb0-f176.google.com ([209.85.213.176]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 05 Jul 2017 12:05:28 +0200
Received: by mail-yb0-f176.google.com with SMTP id 84so70548658ybe.0 for <6tisch@ietf.org>; Wed, 05 Jul 2017 03:05:28 -0700 (PDT)
X-Gm-Message-State: AKS2vOxBHPbNqkqUJsJW3TAK7xCjaXdeLt+xgS0ttCipoIFcYY0aj8Sr po7yaCoWJN0IPz85GcP0lVtLlDz0YQ==
X-Received: by 10.37.208.15 with SMTP id h15mr35660354ybg.213.1499249127385; Wed, 05 Jul 2017 03:05:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.146.22 with HTTP; Wed, 5 Jul 2017 03:05:06 -0700 (PDT)
In-Reply-To: <CAMxvJtLAK=kz=NufYhyZY4YxasfuxKXfb01Z-4uZR0_7_jP9=g@mail.gmail.com>
References: <2053768015.30211.1497881209061.JavaMail.root@canet.uoc.es> <CAC9+vPiR35YhQXQnMuq0SpuT6m4t=XYeD55dJ8KTdz9ZFB5+4A@mail.gmail.com> <CADJ9OA8ZR5fai--xKE3o=f+h-fSi3-EQMqEVbTSnYRRf6hnrDQ@mail.gmail.com> <CAHCejjVFEyvcwbuu85i-bL4T9iX2O5mKaGnTZ9yzYpHoCVNK4Q@mail.gmail.com> <CAMxvJtLJTf9=eP1T8Mc9d2eTY0ARiRkUVmvfL-3UZZwrnOON6Q@mail.gmail.com> <4882.1498070676@obiwan.sandelman.ca> <CADJ9OA9gecM8VfRD3i1a9qkm1qtD277gTAy2E6JH-cYZNTUG1A@mail.gmail.com> <4335.1498606911@obiwan.sandelman.ca> <CAMxvJtLAK=kz=NufYhyZY4YxasfuxKXfb01Z-4uZR0_7_jP9=g@mail.gmail.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Wed, 05 Jul 2017 12:05:06 +0200
X-Gmail-Original-Message-ID: <CADJ9OA_k8ZfipVQ-HpmjdXKiaZtDD3JMwCW7KwjNdu_OvtgHfQ@mail.gmail.com>
Message-ID: <CADJ9OA_k8ZfipVQ-HpmjdXKiaZtDD3JMwCW7KwjNdu_OvtgHfQ@mail.gmail.com>
To: Simon Duquennoy <simon.duquennoy@inria.fr>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Remy Leone <remy.leone@inria.fr>, 6tisch <6tisch@ietf.org>, Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Content-Type: multipart/alternative; boundary="94eb2c055460aafc1d05538f2345"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/KKagFSi3A-2BkUAxPDGJ624afIY>
Subject: Re: [6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 10:05:33 -0000

Simon,

Didn't look at details, but you look at examples-00. Could you please check
examples-02 and whether the issue is still there?

Thomas

On Wed, Jul 5, 2017 at 12:02 PM, Simon Duquennoy <simon.duquennoy@inria.fr>
wrote:

> In Thomas' example
> https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1
> there is a page dispatch to page 1 (0xf1) followed by IPHC (no routing
> header). In this case, couldn't one choose to elide the page dispatch
> and directly include IPHC? Or is the IPHC different from a page 0
> IPHC?
> Just checking if we're on the same page (no pun intended ;))
>
> Thanks,
> Simon
>
>
> On Wed, Jun 28, 2017 at 1:41 AM, Michael Richardson
> <mcr+ietf@sandelman.ca> wrote:
> >
> > Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
> >     > Simon, all, FYI, we agreed on Friday that using paging dispatch is
> the
> >     > right way forward. I propose we continue discussing on the
> plugtests
> >     > ML if that's going to create problems.
> >
> > Yes, but the point is that a non-6loRH node will not be able to decode
> other
> > than "page 1", and we have no signaling mechanism to tell a 6loRH node to
> > "fall back".
> >
> > That was intentional... We discussed having a flag in the RPL DIO to say
> if
> > there were old nodes present, but decided it wasn't worth it.
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> >
> >
> >
>



-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

v2.23.0 | Report a Bug | By Email