[Roll] enrollment priority

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 10 April 2020 08:34 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F049E3A0DF0 for <roll@ietfa.amsl.com>; Fri, 10 Apr 2020 01:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WWabWM1GAnQ1 for <roll@ietfa.amsl.com>; Fri, 10 Apr 2020 01:34:19 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 998A03A1A01 for <roll@ietf.org>; Fri, 10 Apr 2020 01:34:18 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id v1so1546622edq.8 for <roll@ietf.org>; Fri, 10 Apr 2020 01:34:18 -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; bh=lPhnPOG3/OAi8hcDRb83GoRyg0RO2ZzpEHe1BxafTqE=; b=nDeek5JdXRhSkMaoRtg98cM/LvZpLARsO7jEucGCq5cN+sPRtXdiY0wFaBWlIbG3mK KDEtppFCfW/jYzRB4ybX3Ny8OTyJTwUS0kEmxg1ZOsi5zS8uQuqnry8LTNqsXwWdRzXg s1htcgy5iSiS/hnzuKpaiExSSUhJWz9/+22wrV3U5jr21+falH3a7XARE/RXbWOYYcv2 NCTYpD0wrEbi0rFRPTE4q5CLtggCLBD2ZltDXsMCylA84YCRo88OnQUPEbPMvPTIRcZc LT0A/zx9I9E5s2VzcTpOHTxruErAXJJa7tO2RC0v5Jjn6tzbJlPhzltp+RV3fYPMmmbw zU9w==
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; bh=lPhnPOG3/OAi8hcDRb83GoRyg0RO2ZzpEHe1BxafTqE=; b=Rw5Z4YJTfh6Pu2Dc4RcLDzXJ5BTHmc+3RDo7KvyDLG+yQR7veqN+4CEouXgnPlRj4Z EYP2qd4ufYI8XohINbryldmB4iti2adV8eH401DPAcoUzpYCxNxwvLEFkWyWd7SkcK4g nRzPmtyzcXIQE/pg6N40daKkIYyXtTmZpYrNotGcYEqE4i6e2k2xAWJOAA3yP0+90jB+ IguwKMwRvdUYVm+luXyN7cN4Op3x+gA1G2Elw5UZblm87fyQ8ra0y1wK8y27R8HTMqBF ZHrb2NlY8nqsnz9YjSkyr3uaL+gJEYpKeourWyoEXzzxBLjezjoeC+AmFR8lsB4CSaye RqqA==
X-Gm-Message-State: AGi0Pual6w9r/mmCVNiyB9W69R6DUARaFR8DvkAKr+fUaa5l8p7CZudl G+t2M6rPLwtPzCMEv+S22VcxiqWTGODW6HFy3T/14g==
X-Google-Smtp-Source: APiQypLOkWVKgvWECAPs44MUXltw1vI3kKfFSoV5luhNlJnY3/5/Z2H2cFkvj+C9ioBtw4mzlgIkygID83t7utGG9wI=
X-Received: by 2002:a17:906:4d4d:: with SMTP id b13mr2994785ejv.6.1586507656327; Fri, 10 Apr 2020 01:34:16 -0700 (PDT)
MIME-Version: 1.0
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 10 Apr 2020 16:34:05 +0800
Message-ID: <CAO0Djp3p=oYLaUa03wp68Cr+9UxCuLZqykhiNo3kiHi1sqt2bA@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000004a1f8d05a2eb99b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/oXrNjjKJQ66KRMHXo7Vu0yyWKRs>
Subject: [Roll] enrollment priority
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 10 Apr 2020 08:34:21 -0000

Hi Michael,

Following are my thoughts about this work:

IMO, the enrollment-priority is needed for all the use-cases mentioned
in the draft and we had ourselves faced problems [1] where this could
have helped.

The draft may not give a mechanism to calculate min-priority and I
assume there won't be just a single way to calculate it. The draft can
simply mention that value of 127 means that the proxy is not available
for the join process and the draft already does this.

The draft should make it clear that the min-priority can only be
reduced or kept the same (i.e., the min-priority absolute value can
only increase, thus reducing priority) going downstream in the
sub-DODAG. For e.g., if a 6LR sets the min-priority to 10, the
downstream 6LRs can only set the value >= 10 in their min-priority.

Consider the following scenario (the attached image will help explain):
Node C's preferred parent is node B and alt parent is node A. What
happens if the min-priority of node B changes to 127 after the node C
has joined the network with B as a preferred parent? I am assuming
that the min-priority impacts only the newly joining nodes i.e., once
node B changes the priority to 127 then node C also changes the
priority to 127 and thus no new nodes join. However, the change in
node B's min-priority may not impact node C's decision to continue
using node B as the preferred parent (?). What happens when node C has
alternate parent node A whose priority is lesser than 127. Should node
C switch to node A so as to allow new downstream nodes to join the

I don't believe there would be backward compatibility issues with this
new option, but the draft can clarify this explicitly.

We tried working on a problem-statement in the past in LWIG [1] which
talked about how to handle the case where some upstream nodes cache
(routing/neighbor) is full and how would it stop the new downstream
nodes to attach in that path. Enrollment priority was referenced as a
possible solution.


[1] https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy-03