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

Zhen Cao <zhencao.ietf@gmail.com> Fri, 14 July 2017 00:48 UTC

Return-Path: <zhencao.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 AAE901242F5; Thu, 13 Jul 2017 17:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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 sO3a6oJPUvKf; Thu, 13 Jul 2017 17:48:35 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 67136128BC8; Thu, 13 Jul 2017 17:48:32 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id j53so43742891uaa.2; Thu, 13 Jul 2017 17:48:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=fBXmvcw4Nxl8SCjXJeRABWlDR4tPOO5oaj1LyTSI8mM=; b=mdmfMGoBnrQSpFTdlp8xbtZ5zV5SsvCPYRRJEETwIMdIjboagr79bJUcS+UDOTPNxJ bKaiCFUrrl02yddZ4/mvVcgpezpNHUTTXd+JNCucSLKV68FsEgW7yEWnabCHVPTSIB6D ul30bR6fMmq4GwG5K5YWxbuwv3oAbFwu6HIy+IRRM5h6A9GBVWvIQg/yB2a/uPVmP6Zr BP9YaZT05uwJcr6NxBCwXkNz5Za06s85ZnfMiO9xv6+KBRrYbW3Szwu7Yi9Z3vm0Wz8W SQhjxbylOplfViYEbQja9ssjyqQsn0HS9FwMSdD51PrM6Cbu2dcJOT0bitxP5oZE5J26 rdIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=fBXmvcw4Nxl8SCjXJeRABWlDR4tPOO5oaj1LyTSI8mM=; b=RMODzvpxkgh4ouEC9OXjMFHaj1K+kaSoGvN6fHqOY4U5vPp/BXJQmJRnWx4+qjvMj+ 10IYcintBZaWp5cxLORBUny/csggrzfAao/R/VxHrb97hbLDNImMkGgfNjctFgHidIpB SY93z84mUjbIeL7zUVfeVd1yUnAyubvfOdrnDl9Mw/eVYdiC0czSAEsqEaL+ajGS0HRA xsbZoDUbSPWs/SXdxMFBWu8Tx5aTgPVvG5Hj7s3k6go2xOEgYbBGpm/BTQrFm86Xb9N9 4yyFAnt3ytDBDPMjMKqn1hkpu+W4s+oD4IArNZY7eAlOUfoAFmIPaWqrSdtkyUAUqvbK zBQg==
X-Gm-Message-State: AIVw112fw/MEy9GOxX2tbTm7qt38TQlz4onDZ0yST8NUz+49bEmhcsas z9eCe2kFJToJuTG5/Y9c2W6ziOsG6ria
X-Received: by 10.176.17.26 with SMTP id e26mr3592340uab.94.1499993311379; Thu, 13 Jul 2017 17:48:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.59.203 with HTTP; Thu, 13 Jul 2017 17:48:30 -0700 (PDT)
From: Zhen Cao <zhencao.ietf@gmail.com>
Date: Fri, 14 Jul 2017 08:48:30 +0800
Message-ID: <CAFxP68zkBqhW15Vsd0LK7RS-VxGDqyPG2yO9rtu2L6PE=F2k=A@mail.gmail.com>
To: lwip@ietf.org, draft-jadhav-lwig-nbr-mgmt-policy@ietf.org
Cc: 6lo@ietf.org, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/bPM_ckUfPEDfV7qaIr48Pb-iz9A>
Subject: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00
X-BeenThere: 6lo@ietf.org
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." <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: Fri, 14 Jul 2017 00:48:37 -0000

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