[Roll] draft-qasem-roll-rpl-load-balancing

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 30 March 2017 23:36 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2F129416 for <roll@ietfa.amsl.com>; Thu, 30 Mar 2017 16:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OqwQLLhpAmFM for <roll@ietfa.amsl.com>; Thu, 30 Mar 2017 16:36:35 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39CD126C0F for <roll@ietf.org>; Thu, 30 Mar 2017 16:36:35 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 676A3200A3 for <roll@ietf.org>; Thu, 30 Mar 2017 20:00:34 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CCC5D636BB for <roll@ietf.org>; Thu, 30 Mar 2017 19:36:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: roll@ietf.org
In-Reply-To: <3798.1490894415@obiwan.sandelman.ca>
References: <3798.1490894415@obiwan.sandelman.ca>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 30 Mar 2017 19:36:34 -0400
Message-ID: <23382.1490916994@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/QC-65muwzAzF3bUVbxnAhJ9OkA8>
Subject: [Roll] draft-qasem-roll-rpl-load-balancing
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 23:36:37 -0000

Three thoughts:

1) I think that this an interesting way to easily define a new metric
   ("number of children"), which could be used as part of tie-elimination.

   ** So, it's my thought that this is good work that should be adopted. **

2) It seems to me that on a non-broadcast interface (PPP IPsec tunnels, such as might
   be used in ANIMA for the ACP), that it would be reasonable for an
   implementation not to send a DIO out on the interface which it has chosen
   as it's parent.
   If that occurs, then the parent can't do it's counts correctly.
   But, in the ANIMA case, we are using storing mode, and we will use it with
   DAO-ACK, so we can count DAOs.

3) But, I then thought about other situations with multiple interfaces, and I
   realized that there is another case where there is propogation issues,
   and that is 6tisch.
   It 6tisch, it may well be that the parent is not listening on the slotchannel
   that the child uses to send it's DIOs, and so the parent won't hear.

   I'm not sufficiently familiar with the minimal schedule to know if this
   is commonly a problem, but it seems like a concern.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-