Re: [6tisch] review of draft-ietf-6tisch-enrollment-enhanced-beacon

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Mon, 25 March 2019 09:17 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 AD3AA1203DA for <6tisch@ietfa.amsl.com>; Mon, 25 Mar 2019 02:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_TEMPERROR=0.01] 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 sT7JHVW-Gcnh for <6tisch@ietfa.amsl.com>; Mon, 25 Mar 2019 02:17:15 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 0F4ED1203A9 for <6tisch@ietf.org>; Mon, 25 Mar 2019 02:17:15 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id e80so7354943ote.5 for <6tisch@ietf.org>; Mon, 25 Mar 2019 02:17:15 -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=2nZxQ7g0v1/2HN9h/1lA2HPf8aJYnfHHevJHjCJnaFA=; b=L7Z1/n3Y2jVTD60ZRB3NA7f8hL1KbqrxU3zIOuElxp/EqDUgpQl5wdQ+R1JwX9PBg5 NYMLgrci4LI/BjbOlJYA5SDzIPXlRk8ytJEQPAhcH6DI0jZhupEKsGkCTkLAH7Vazma5 zMf3o5iY7XBFtIn4fuOdqRw4bbpFtZxLrIInF4iVxv5+CATkUXcjSZoB88rUWBsfBjnX cSAJNwSPqZ51cJsnAKeaUxPy4pLLQ1tWe/ECEf9DCA7SC0G+VRqfnb5XgcX+LvEDhjXG 0dLpgaPMbOFCtboisK6xKPlki0bZ8YNZb7qIy7LsU0xD/iUeroEQjxI/+w3ip0jeBGJa shoA==
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=2nZxQ7g0v1/2HN9h/1lA2HPf8aJYnfHHevJHjCJnaFA=; b=V8ZAYcpBCsM5sRutu5rW18Lh/F2oS8rDz38p7483sbfsutiEqQvKqiXGt/0auYPAAX JfOWfT5EY5dNhXjYXeE3kAoIppFJh4LoYb34MAgwYPc1fyIjtIKMZLoFME+29Gmq8JQJ yNATYf7wvVwSMZExLb4Lmmg6gtJDvcBtlk2uBiBytF/zX+w7cnPtTq8QOtRxQc2QlKJ5 ILfUOEPduUMQsvGJil6QfYBI94RU0T/1ST2D/c/MFpDyLlg4bXqUOYMRDv8dFT+SLqOA XAnwamMPZltaltYaveDn9zt7QVLD7t/S+Cn07awR6b+roEuU+SXPMBGx5yH+OJKgEwlo vWog==
X-Gm-Message-State: APjAAAWtO4oVY1bzoDORPFPxhdS+P92vMTDGVTYt+Pem8HB9pAi2oi8F NcJcpdooj1cEynaGgZcCtwquwKM6LpIf9vR0vWcKgg==
X-Google-Smtp-Source: APXvYqwNDy1db0E6D6/wwIgsDSglGOzTuFkXBwJh00hA3dsghXsPnYCBV5+nh98PbQvVYWYmjpbth66v2QiIFzHe1TY=
X-Received: by 2002:a9d:6a88:: with SMTP id l8mr16261797otq.260.1553505434213; Mon, 25 Mar 2019 02:17:14 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB35657322D6A302F34A9B84D3D84A0@MN2PR11MB3565.namprd11.prod.outlook.com> <15671.1553503636@dooku.sandelman.ca>
In-Reply-To: <15671.1553503636@dooku.sandelman.ca>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Date: Mon, 25 Mar 2019 06:17:03 -0300
Message-ID: <CAH7SZV9UpyiftJjk9UktSeM8a84xb5z1ihuskfzPARCmuV9rEA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org" <draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000090350c0584e7abc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/u0dRWxZzOClt8Vd7UM8jWGDcl2c>
Subject: Re: [6tisch] review of draft-ietf-6tisch-enrollment-enhanced-beacon
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: Mon, 25 Mar 2019 09:17:24 -0000

Pascal, Michael:
             Thanks for the comments. Answers below.
Regards,

                               Diego

Le lun. 25 mars 2019 à 05:47, Michael Richardson <mcr+ietf@sandelman.ca> a
écrit :

>
> Thank you for this review!
>
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>     > Page2 Introduction: there?s an EDNOTE: field. It could be useful but
>     > not necessary to make the proposed addition. Is the author willing
> to?
>     > Or should a coauthor help?
>
> } EDNOTE: Explain why broadcasts are rare, and why we need them. What the
> } Enhanced Beacon is, and what Information Elements are, and how the IETF
> has a
> } subtype for that area.  Explain what kind of things could be placed in
> } Information Elements, how big they could be, and how they could be
> } compressed.
>
> If the WG feels that this section needs to be filled in then I will work
> with
> Diego to fill it in.    Clearly less text is easier to review, but I think
> that non-6tisch reviewers will need some understanding of why we do what
> might be considered layer violations to pack all this L3 and routing
> information into a L2 object.
>
> I would prefer to write text like:
>        "[XYZ] explains how the availability of the broadcast is limited.
>        [ABC] details how the Enhanced Beacon is already used to do
> schedule synchronization"
>
> - One good reference for the low availability of broadcast nodes is Malisa
Vucinic et al. paper
"Broadcasting strategies in 6TiSCH networks" which mentions:
"State‐of‐the‐art approaches(2–4) address the problem by assigning
additional bandwidth; this comes with extra maintenance and energy cost.5
Using the Trickle timer6 to schedule EBs is not feasible in 6TiSCH as new
motes have no means of soliciting its reset without being synchronized with
the network."
- I think the details on the Enhanced beacon can be obtained both from
RFC8180
and from the IEEE802.15.4 standard.

Comments welcome.


> I would dearly like help from the WG on this text. Now that the
> architecture
> is more stable, perhaps they are just normative architecture document
> references?
>
>
>     > Suggestion to also refer to https://tools.ietf.org/html/
>     > draft-ietf-6tisch-architecture for terminology
>
> Done.
>
>     > ?
>
>     >    At layer 3, [RFC2461] defines a mechanism by
>
>     > ?
>
>     > Please use RFC 4861
>
> done.
>
>
>
>     > Section 1.3
>     > There?s a XXX leftover. What is the intention?
>
> No idea, removed.
>
>
>     >    proxy priority the proxy prority value contains a number from 0 to
>     >       0x7f.  Lower numbers are considered to be a higher
> preference.  A
>     >       priority of 0x7f indicates that the announcer should never be
>     >       considered as a viable enrollment proxy.  Lower value indicates
>     >       willing to act as a Join Proxy as described in
>     >       [I-D.ietf-6tisch-minimal-security].  Only unenrolled pledges
> look
>     >       at this value.
>
>
>     > ?
>
>     > Maybe indicate first that the field indicates the willingness to act
> as
>     > join proxy? Also, a typo (prority).
>
> Fixed.
>
>     > P and R bits definition; though it is quite obvious, the description
>     > does not say that ?R? is the RA bit and that ?P? is the Proxy Address
>     > bit. Maybe use the term flag, like in? the ?P? flag?.
>
> Okay.
>
>     >    join-proxy lower-64 if the P bit is set, then 64 bits (8 bytes) of
>     >       address are present.  The Link Layer address of the Join Proxy
> is
>     >       fe80 (as for any Link Layer address), and the bits given in
> this
>     >       field.
>
>     > ?
>
>     > I think you mean Link-Local not link layer? What about:
>
> Thank you, good catch.
>
>
>     >    join-proxy Interface ID if the P bit is set, then 64 bits (8
> bytes)
>     > of
>     >    address are present. This field provides the suffix of the
>     > Link_Local
>     >    address of the Join Proxy. The associated prefix is well-known as
>     >    fe80::/64.
>     > ?
>
>
>     >    In a 6tisch network, where RPL is u
>
>     > ?
>     > Missing reference to RFC 6550
>
> added.
>
>
>     > ?
>     > 2.1.  Protocol Example
>     >    Here will be three examples of processing.
>     > ?
>     > Do you intend to fill that section?
>
> At this point, I have no example packets, so I will remove that section.
> I have posted -02 with these changes.
> What lacks now is only a decision on how much text to put in the intro to
> explain broadcasts.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125