Re: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00

Samita Chakrabarti <> Fri, 14 July 2017 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 254CB1316A9; Fri, 14 Jul 2017 13:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 50dNtfkBifLY; Fri, 14 Jul 2017 13:47:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A20212441E; Fri, 14 Jul 2017 13:47:39 -0700 (PDT)
Received: by with SMTP id 35so11444503uax.3; Fri, 14 Jul 2017 13:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=btaGdYelhne61Y9Fq28C5edPJcR7dE+vMKS7J+utquo=; b=p1yl6R6LZGaalf2cgxDYhM3kw3YXq/4jVFnEbpsXfIVtB8lZm97G980m5FHa/mKySK vf0agWmtnhsrM+byTSpkvevSv2DTo5ueofRQrSDGjtZ4pQLWJ4wdv3Jocfn6aSdFhQXC rERRZrBvXKQyO6A+1wpfVLZgdezorH+GnJNmaesfFnHsdpL0f4OGb4qZF/Zgi78SSBTw 3u1+t6FsS5KjadG3TdKOxK0qvNavP92tBQEyiomM6Q+/c9NLlq1HixOQu+a+nnBDvjlH YwT8Um79a2A2A8Xt57velE5iLfFx7spQ7+S/tUPTiSjA/6TbVuLv4cW5sNjgGxD/m1JY qBHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=btaGdYelhne61Y9Fq28C5edPJcR7dE+vMKS7J+utquo=; b=Z0kyrJE2EqRGgNnQPezVTUXrr5gIke+m418naU2teR+Hnp/Io/fiYyVPXd5VvxMenk MjYdP4uVBnjI6Ee5l9L+ol4lPxqvf8fY1xy2pE58R5e6BXh/CLxX6MYU2RclpmmPgoZM cwkwpbPpDG+p/Llmusw9MhkZ9zwV1KLl05sVTxwUrM65UV2V9dVL7B/d6HWIQPfp20zS 3fdqN6YyHh42PGEfNWbZUOiZyIRTB+D9WqwPRr6UGB+HF74PUjifH/t3jXtFFkqHgwqu ATwT0xiN0Ix1MSERYuDvCSbYdThmoCY1rErU+U5kKLtwxIqk1GsK2HarK+M2cfIlfwXS Hryw==
X-Gm-Message-State: AIVw110nBf3GEZqfZKdXWc8IIgVeEmr+TSoaVBDf+44zCsqGBW8D+EQx 4fyYaTn/tqFs9UrwfLgALDutZZpJLg==
X-Received: by with SMTP id u2mr4623467uag.36.1500065258182; Fri, 14 Jul 2017 13:47:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Jul 2017 13:47:37 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Samita Chakrabarti <>
Date: Fri, 14 Jul 2017 13:47:37 -0700
Message-ID: <>
To: Zhen Cao <>
Cc:,, Routing Over Low power and Lossy networks <>, lo <>
Content-Type: multipart/alternative; boundary="f403043eb49cda9bfc05544d28e3"
Archived-At: <>
Subject: Re: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00
X-Mailman-Version: 2.1.22
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: Fri, 14 Jul 2017 20:47:41 -0000

Hi Zhen and Rahul:

Thanks for looping 6lo in the lwig-nbr-mgmt-policy draft discussions.

6lo WG, please review draft-jadhav-lwig-nbr-mgmt-policy  document for any
impact in 6lowpan-nd. Also it is a good place to discuss if anyone else is
aware of any alternative neighbor management methods.
Also please provide feedback for improving neighbor management from 6lo


On Thu, Jul 13, 2017 at 5:48 PM, Zhen Cao <> wrote:

> Dear Rahul and co-authors,
> Many thanks for the hard work in contributing this draft to the lwig
> wg. (I am copying roll and 6lo since some discussion will be quite
> relevant)
> As I go through the document, I found essentially there are three
> types of different policies discussed:
> a. Trivial neighbor management (FCFS/LRU)
> b. advanced neighbor management (proactive and reactive)
> c. proposed ‘reservation based’ approach
> Logically I understand the shortcomings of the trivial approach,
> however in practice, how much this many impact the network stability
> is not convincing enough yet. (what’s the possible size of node
> density/mobility may be impacted? ).
> The discussion of reactive and proactive ways of managing the neighbor
> cache entries is helpful. The discussion about the proactive approach
> in Sec.2.5.2 quoted below has some pending relationship with RPL (if
> this is an acknowledged problem by ROLL WG).  Anyway this is something
> we need to discuss with the ROLL wg to see if this a need feature.
>     Currently there is no standard way of signaling such neighbor cache
>    space availability information.  RPL's DIO messages carry metric
>    information and can be augmented with neighbor cache space as an
>    additional metric.
> For the proposed reservation based approach,  I think this is quite a
> practical recommendation (if my concern about a. will be relaxed).
> I also found the Contiki RPL implementation has recently used a
> similar way in its rpl-nbr-policy. Shall we link the draft to the open
> source community to see if the document has provided additional help
> to the implementation? (or that’s already done given coauthors Simon
> and Joakim are both active contributors of Contiki)?
> Many thanks for discussion.
> Cheers,
> Zhen
> _______________________________________________
> 6lo mailing list