Re: [6lo] review of 6lo-blemesh
Rahul Jadhav <rahul.ietf@gmail.com> Mon, 16 December 2019 01:06 UTC
Return-Path: <rahul.ietf@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A64512004A for <6lo@ietfa.amsl.com>; Sun, 15 Dec 2019 17:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wtkJM06ExdYA for <6lo@ietfa.amsl.com>; Sun, 15 Dec 2019 17:06:52 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 2666D12008F for <6lo@ietf.org>; Sun, 15 Dec 2019 17:06:52 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id c19so4848643lji.11 for <6lo@ietf.org>; Sun, 15 Dec 2019 17:06:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sAi5BQP5w22wag/ZWTfEuiLYJHh/jKuOxWrkYVuXeNQ=; b=sbrnS2Jg3wT76hX262TdaGtViku1VJXFnC1shSafiScd0LBtoOKviraB9OnbdU4QPh xrm7+U/G+HAb21e7Z+YI+Z3JLI1hsnxrb/E33I32CGLj3y/22gBJ3WjLmid25+ya2B9m Z3FQGxV6P10DBDkmoeG/kYyTWrszrw6lWh+Jsivg3cS+zD589b8FDXbS0hN4fIwdxyny 94YK0lKQcNKPj2U0CWzK57FKPGltGbDOmGE3qkUSzJsjlfSwm41zZ3js2L+O1yXUudun 84Pn24LL3+bVsPOyXgUO5YmhI5Q8olSLSm2cTFoNEPi+frR5xGkUtJB0Yubv32BaZQY9 2sNA==
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=sAi5BQP5w22wag/ZWTfEuiLYJHh/jKuOxWrkYVuXeNQ=; b=tOaq7gFE6aO0AEdqnXEIZ/uICcLI+e0MNytyDfFJ4QXa4rfc3poSzZ+B5trRR3nqsB c9u9NuN+HfK8jM/u3JlF0BfHnPvSXlKJBD9vZQCP2j0WuKInB3G6B9hfauu5EpH+TR8e kuAv23BTfWf17WOE47cmpW8o4oEvDDqWzTpySQWiOllrH8cAYkukCezzponb5BPv9O26 FS5xi5oZHCa7DheyRbmxkRTr3ySjaXuRR0P9cXxULXz3j7UGyxR/lW6YXaYcW3bf/CBj B6bXheZ0CTYwW6Zm0v7GdYm6+Nxpg1cV+pgQyH73HRu02C887IpWd7Gg69mjUOOB+3cq TZHw==
X-Gm-Message-State: APjAAAUh1kupW7HEgJC1cBLnAlOUc0Xdapx+v3MszmkyPxDfGf+rSLLg 2UrjpIpjoXWv8EGeZ8KjmI7kZlqaD1bBhHu9Wmk=
X-Google-Smtp-Source: APXvYqzXNvC/Wa7EJE9kHFE6VjXh4dYJQTzK3W3aLk5myvmV3yIZgl959bt6OKsGZ20O2z09g8b+atXc4q3cpOtGtzA=
X-Received: by 2002:a05:651c:cd:: with SMTP id 13mr1114036ljr.63.1576458410430; Sun, 15 Dec 2019 17:06:50 -0800 (PST)
MIME-Version: 1.0
References: <CAO0Djp2Of3ERSvZoHvPosDvp1D6jGhKa4UU64uaQ5AX0a12dpA@mail.gmail.com> <1e105105832b45342a54be08c3c9df90.squirrel@webmail.entel.upc.edu> <CAO0Djp2oCi7SGuRaxLnesJ3X1_HPGvPTz+=LbFcZgTNNW=p-xg@mail.gmail.com> <66b0bcd40aba76ffd90dcf219e4ac1b1.squirrel@webmail.entel.upc.edu>
In-Reply-To: <66b0bcd40aba76ffd90dcf219e4ac1b1.squirrel@webmail.entel.upc.edu>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Mon, 16 Dec 2019 09:06:39 +0800
Message-ID: <CAO0Djp0L9osjHL8NnH7W8+93RPO66gw7yAB_U8GK1uj+188rHg@mail.gmail.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: lo <6lo@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/ITQh5-wNH0-whyrFKwEpG2EiLbw>
Subject: Re: [6lo] review of 6lo-blemesh
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 01:06:55 -0000
Thank you Carles and authors. I read the diff and my comments are handled with what I had in mind. Best, Rahul On Sun, 15 Dec 2019 at 03:18, Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote: > > Hi Rahul, > > Many thanks for your last review! > > We just submitted -07, which is intended to incorporate your last round of > comments. > > Should you have further comments, please do not hesitate to let us know. > > Cheers, > > Carles > > > > > > Carles, Thanks for incorporating the comments and feedback. I did a round > > of review and the comments are handled according to what I had in mind. > > Thanks. > > > > There are some more comments I had during my subsequent review. Please > > have > > a look. I will provide the shepherd write-up after this. > > > > Best, > > Rahul > > > > --------Comments------- > > 1) Section 2 > > "The IPv6 forwarding devices of the mesh have to implement both Node and > > Router > > roles, while simpler leaf-only nodes can implement only the Node role." > > The roles here refer to roles as described in Bluetooth IPSP Spec. I was > > confused with the Host and Route mode as described in RFC 4861. I would > > suggest > > adding explicit ref here. > > [Later I found that a para above has a context for IPSP and the > > Node/Router > > roles. Thus I would leave it up to you to add an explicit ref.] > > > > 2) Section 3.3.1: > > "Multihop DAD functionality as defined ... MUST be supported." > > RFC7668 didn't mandate DAD. I am not sure if we should mandate it here. If > > an > > implementation decides to use SLAAC with a static link address then DAD > > won't be > > necessary. The cost of multihop DAD is high. > > > > 3) Section 3.3.2: > > "A Bluetooth LE host MUST register its non-link-local addresses ... " > > > > This stmt contradicts with another stmt in section 3.3.3 which says, > > "A 6LN SHOULD register its non-link-local address with EARO in the > > next-hop router. Note that in some cases (e.g. very short-lived > > connections) it may not be worthwhile for a 6LN to send an NS with > > EARO for registering its address." > > > > My suggestion would be to use SHOULD even in Section 3.3.2. > > > > 4) Section 3.3.3: > > "... non-link-local packet transmissions originated and performed by a > > 6LN, > > and > > non-link-local packets intended for a 6LN that are originated or forwarded > > by a > > neighbor of that 6LN." > > What does "performed by a 6LN" imply here? Suggest just keeping originated > > by > > a 6LN, unless I am missing sth here. > > > > 5) [nit] Section 3.3.3: > > "..., context- based compression MAY be used." > > remove space between "context- based" > > --------End of Comments------- > > > > On Sun, 29 Sep 2019 at 01:04, Carles Gomez Montenegro < > > carlesgo@entel.upc.edu> wrote: > > > >> Dear Rahul, > >> > >> First of all, apologies for the late response. > >> > >> Thank you very much for your review. > >> > >> We have just submitted -06, which is intended to address your comments: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-06 > >> > >> Should you have any further concerns, please do not hesitate to let us > >> know. > >> > >> Cheers, > >> > >> Carles (as a WG participant) > >> > >> > >> > Dear authors, > >> > > >> > Following are some review comments based on the latest updates to the > >> > document: > >> > 1. In the last revision, the draft mandated the use of NS(EARO) in > >> > place NS(ARO). This change is not consistently applied in the > >> > document. E.g., in section 3.3.3, the draft continues to use NS(ARO). > >> > 2. Section 3.3.3 also mandates the use of the 6CO option. 6CO option > >> > may not be necessary in case a single prefix is used in the network. > >> > The CID defaults to zero which results in the use of default prefix. > >> > 3. Section 3.3.3 the following statement is not clear, "In particular, > >> > the latter comprise link-local interactions, non-link- local packet > >> > transmissions originated and performed by a 6LN, and non-link-local > >> > packets transmitted (but not necessarily originated) by the neighbor > >> > of a 6LN to that 6LN." > >> > 4. I think the draft will benefit from a call flow diagram depicting > >> > the node joining procedure. > >> > 6LN ----(RS)-------> 6LR > >> > 6LN <---(RA-PIO)---- 6LR > >> > 6LN ----(NS-EARO)--> 6LR > >> > [Multihop DAD procedure] > >> > 6LN <---(NA)-------- 6LR > >> > 6LN can now start acting as 6LR and advertise its own RA > >> > 6LN ----(RA)-- > >> > > >> > Regards, > >> > Rahul > >> > > >> > _______________________________________________ > >> > 6lo mailing list > >> > 6lo@ietf.org > >> > https://www.ietf.org/mailman/listinfo/6lo > >> > > >> > >> > >> > > > >
- [6lo] review of 6lo-blemesh Rahul Jadhav
- Re: [6lo] review of 6lo-blemesh Carles Gomez Montenegro
- Re: [6lo] review of 6lo-blemesh Rahul Jadhav
- Re: [6lo] review of 6lo-blemesh Carles Gomez Montenegro
- Re: [6lo] review of 6lo-blemesh Rahul Jadhav