Re: [6lo] review of 6lo-blemesh

Rahul Jadhav <> Sat, 30 November 2019 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA26A12002F for <>; Fri, 29 Nov 2019 19:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Nq9vR1kJj4O for <>; Fri, 29 Nov 2019 19:27:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7953212009E for <>; Fri, 29 Nov 2019 19:27:30 -0800 (PST)
Received: by with SMTP id r15so20986398lff.2 for <>; Fri, 29 Nov 2019 19:27:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6OBmm45J5aSwmtR8za2PezrM+cRz9EeJxhtOM0T7rE=; b=rL+mHYtS+RDNi5cuyCy+yop/KGHYEtPXVr3pKK5NSnxs1QSaCZqQ7Kuux8jFjKTlI1 t2ChOBcK68h3BPHxk7veBnv+sib2oEpbbDOdt+ZNGwV9X03HcWP8dSohA+J/8eS9FoJG ZPm6NN7EwLI4oLS3bBZte6uTI7ZhuSE22Nkey8/dA+yjNr3kzEow+NlHnPq2bxsEOfN7 IPr/49nga6ntPGNJupeqdW09nB5PgTOsdl7BGkyShJXjDReQ0BNNQ37WT/Cjkn21007V LQ0OyGn0Gu8U4/8uB6KqwmpVLZiAIHh3uayq697WUxNsgpCI8Q9zUmpvYbOgehEBq73O GBJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W6OBmm45J5aSwmtR8za2PezrM+cRz9EeJxhtOM0T7rE=; b=AOggEHFb/aOR3dq+Ovhx9Ejc4IbyeMs0LkgHqfdZaeHP64UfphrIa3EI+64UnTHxvR T7/cis7b3GDoJGWBf+slCEmWB/DmOkLQHfmiDN0zQl/C8MY4rFegX5LIWBAc/OHjSYU+ q6p9hKyEtL1Z+gDduNl4xRMLD0J/Eh+1yVuABOKIRnD35KbV2hjrTF6p6dUa7Co5lKCN j3zpup1QDCXbd4J/VPmjw6807m8s0HmleuIkabfGwzLqpj9TMmtR3OvSOif4W+bdJDj5 LPQhqMtimeYwpGYcvi/ly3tos5qubKqLYOymABXpJJhxlE64szMz/6IsWbMSeuRKg9kY hRpA==
X-Gm-Message-State: APjAAAV6HUZ3OOdiY6z/56CVrGVzp/oTreHx5rQKNPq5F71AJb/vuyKP dxPpSNhr6mbM8dUQdg0DWzLnf3O0IlJlzj2/OZPDfINd
X-Google-Smtp-Source: APXvYqxj1QDvb1duko/+RuiaLsOFy4cYv93uspLZZtZJhg6yyoiSkCFWkGr6ZCp9nNEmlx4Og40VMf+cjP337OZKUVM=
X-Received: by 2002:ac2:59dc:: with SMTP id x28mr7843734lfn.38.1575084448512; Fri, 29 Nov 2019 19:27:28 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rahul Jadhav <>
Date: Sat, 30 Nov 2019 11:27:17 +0800
Message-ID: <>
To: Carles Gomez Montenegro <>
Cc: lo <>
Content-Type: multipart/alternative; boundary="0000000000000b7f36059887ed18"
Archived-At: <>
Subject: Re: [6lo] review of 6lo-blemesh
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Nov 2019 03:27:34 -0000

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.

There are some more comments I had during my subsequent review. Please have
a look. I will provide the shepherd write-up after this.


1) Section 2
"The IPv6 forwarding devices of the mesh have to implement both Node and
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
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
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,
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
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 <> 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:
> 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
> >
> >
> >