Re: [6tisch] SeqNum definition in RFC8480 (6P)

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Wed, 24 April 2019 10:48 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
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 2DA1D120324 for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com
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 Fqs6dEZO2-je for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5896E120328 for <6tisch@ietf.org>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id e5so15670383otk.12 for <6tisch@ietf.org>; Wed, 24 Apr 2019 03:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BA+iOMPHIeoQ5hG2Lor9JQlL56q2i/LFWTNG9eJWeb0=; b=rqKX/CTaIWUxPKmkpXoGWJQIU3iWdnKnhexKrwyfDFMmYjq/oetwoglU9voX9TTLk5 oEMWgZdDXVKkH4BlYY5fO3tkOCM45oGGVAsqOkIxf9jKQFZR9Cwv8CRIhAqU5ds7pO4q 4SZU12P9u95v2Vi9EmTC5GIA17zvQAhIYIWbqGV/hiz+N39u6bzemgfEMds39wyfYXX0 OcEeoCM/JKcX3rtA44moe4zTa8yPqU0KwIUAsED0ACPFEZd+9CO2N0+cbisZQ88lhLXu d8BBWfviS6ERkBEOZJ2hSUqNon3tf95jFLC/QHTvEy8szujmi7V56suAREietrD/1Lpp Lwzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BA+iOMPHIeoQ5hG2Lor9JQlL56q2i/LFWTNG9eJWeb0=; b=i+Oa1w/jKWZ22V249yPRBFOjTH/F6DjjcGtdHwghipranIwhsBkbE0MQROJaUayP47 FiXju3nUFV4AmuQhc8lNx3nY/xGOKmujZ+9hHPvxkQ/LZ+qALc9A5k+KaK/VniGi7L6m lOonUhINNRP2kBRP6c37IZXcriT4Hznnlb7CRVpeNNZ5sBmKDDaXzSqJG4rJ5ZwT1rlW bvuZYcBjzfBzu1YksJGEqj4tM2Z5XR7TAo2Fw0s4lAFKUSxi4R1Ms8lBFa8ON0frHMof q+nV+VUbrjlTgE8NsaBnpm95XjcVPCjMlONpRG/eQ6hXjMM2LgwnTavzivOA4Q2rXmH2 hl+A==
X-Gm-Message-State: APjAAAW3VYY0SDFxKY7zN8O5giUu2nvAi9dZOagr2Zndv40ZXMfh9hIP WN5MTVtjNP0jZ8AIndv1c1GDwnt1SdRRYRmkDwKKEw==
X-Google-Smtp-Source: APXvYqwzaUZNvu/B/2oGpF0u1cnaZA9wQH+XBgPX64aSbySENpXRypT3xn/fM/opE/Njot94qfvkmrgBczVgNEFW2Mc=
X-Received: by 2002:a05:6830:1145:: with SMTP id x5mr19985724otq.40.1556102891317; Wed, 24 Apr 2019 03:48:11 -0700 (PDT)
MIME-Version: 1.0
References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> <CAC9+vPgBUVjOiECs5ZL6c6PNkZ12X81=YThCs872VCbtJVb=uQ@mail.gmail.com> <c1e115ed-24c7-ed16-c776-bc2501e8a3b2@inria.fr> <CAC9+vPhs6FpVNvGA9vNe00RzZ5YND5-LvV3TCg=6dSwDsixshg@mail.gmail.com> <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr>
In-Reply-To: <817EBD8A-34E4-41D0-8127-939E61BC0732@inria.fr>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Date: Wed, 24 Apr 2019 06:47:58 -0400
Message-ID: <CAH7SZV-hFaMVW5TRd01odjTiO5LEHPEmWqgVA1yf-+jtOst8tg@mail.gmail.com>
To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Cc: Xavi Vilajosana Guillén <xvilajosana@uoc.edu>, 6tisch@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001241b305874470b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/L83Bpko60tnmY-1eqkP9yaFhDNI>
Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Apr 2019 10:48:16 -0000

Yacht,
          Let me chime in a little bit. Responses below.
Regards,

             Diego


El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
escribió:

> Hi Xavi,
>
> > What is the issue you see with this?
>
> At least, there is an inconsistency in RFC8480. Here is another example:
>
> https://tools.ietf.org/html/rfc8480#section-3.2.2
>
> rfc8480>   6P Request, 6P Response, and 6P Confirmation messages for a
> given
> rfc8480>   transaction MUST share the same Version, SFID, and SeqNum
> values.
>
> Such an inconsistency could bring confusion and/or an interoperability
> issue.
>
> According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a
> special
> meaning which is "I've lost all the states completely (due to
> power-cycle)",
> although this is another case we will receive such a response as shown in
> Figure 32... Honestly, I'm not sure how valuable it is to know the peer has
> performed power-cycle, by the way.
>

As far as I can remember, it is important to know that the peer has
forgotten all the states and has lost his schedule, so all the allocated
cells with that neighbour are currently not valid anymore and should be
wiped from the local schedule.


> So, if setting 0 to SeqNum of a response is a right thing, I would add some
> text to the SeqNum definition in Section 3.2.2, to tell there is an
> exception.
>
> Best,
> Yatch
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>