Re: [Roll] enrollment priority

Rahul Jadhav <> Sat, 11 April 2020 07:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17AD73A0D20 for <>; Sat, 11 Apr 2020 00:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 IlkSJv9yEaMF for <>; Sat, 11 Apr 2020 00:49:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A55C3A0D1F for <>; Sat, 11 Apr 2020 00:49:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=PRw7+2qHYeog5IEB2mqMtMBA+oAy7BMLJpCsSYgGoTfWz+ZIIrv2uilXvQnSpDtNFE2E4ElkquUVmk0sI3MLNJ41H6JXoH05lMqgoPQC4AZp3faX/+mYi/ND9JggKpe2aD+tir0WsnYUYv3eWnJdpgfdO+Z/2oPOprcw71hCZXtahRXfPNZv4VUXozBR6qWvrELujzGzwLRbryfvuPoYfNiu9id+wOMb6UxaA+8q+7f7xRWrpblg2TfO0TbPuJ9h9E3t8IuRakY04nOPzNryxN13vl5fCW31tAkY17CGFAraxVmKiGGbs/WmdteTmQK4SlmyIj+bLk8CVMmsfti1oA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+6UaHfhhqCGg7Z1VHyZqsIK6O3fm+fh6HyTPjUnzL0M=; b=TBz+XSvvIKcp1PQmC4TfLKs/MADICiQ7UJW8L4OVz2VuNFoBrBAL54d9ubVSKJv2moYMRsHkxiEAe3ZIW7qqa7iEj7TUbbdCpUEwy3OoKqTDF0W+cj1/TQiViqWFPxMWwcjMPgKkTiiMImMng6vyX6iLmBe7FjjfmzZxLCss9c+KFc18q0W8xoSkNpVczbfgyo68ZcRQ1atFvJ9TjO0wbZUT3/71Eecp7WxeKSTPyn44s6vPuFJzSqKExnjSYVYnyQ/42lb3L7KpZa/PkwTJWc+FxQEhheidlk+L9B0vQ/z6tl21eb9AevwLaBvEVoZb3squX0t63Rlh6ENYvaAYgQ==
ARC-Authentication-Results: i=1; 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+6UaHfhhqCGg7Z1VHyZqsIK6O3fm+fh6HyTPjUnzL0M=; b=HGhC7bB7jecpbq49ekOaCijSOdECDuZEC/UwizaaMTb9yS68pLplWiEKUpEKt4noPq/v4ScWfovsDey2vXKUtSlSslJPl4My3WiHAsobVJebIkQgIRYtDSxQhfYQyq/9sP24KKFoNkcKP7XUDodglkfsUJQu0qOePGHzxpi9a8N3J8zvBJUTgKP3Tg8S1E4Y/DwtbSAXAQInGZU/FA+myYUWXUsYGC6feFgYxirE5fVGCuyVWXQ3pT5FY82E+gd4AdtCb5LC8i6EFQABYCu6Dm+pBBtILVlQaet+DkWL1Q5pqMi4DBJgS1gsOLau8T3shHhTEnxMWvTSrDEA1SkLzQ==
Received: from (2a01:111:e400:7ebe::50) by (2a01:111:e400:7ebe::428) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Sat, 11 Apr 2020 07:49:19 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Sat, 11 Apr 2020 07:49:19 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050%6]) with mapi id 15.20.2900.026; Sat, 11 Apr 2020 07:49:19 +0000
From: Rahul Jadhav <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] enrollment priority
Thread-Index: AQHWDxLaq4ESG8ufGECibz9W2Pb+W6hy5DGAgABLdL0=
Date: Sat, 11 Apr 2020 07:49:19 +0000
Message-ID: <BM1PR01MB402069CD033662DD56D11B0BA9DF0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <>, <8722.1586555051@localhost>
In-Reply-To: <8722.1586555051@localhost>
Accept-Language: en-IN, en-US
Content-Language: en-IN
x-incomingtopheadermarker: OriginalChecksum:B1E77C2638FC49586CC089A862B87F574BDBE352267396E0A1BCD2667CC13FE3; UpperCasedChecksum:36FC199482C65916F1BF6492F15339BB11F8713DEDEBCACCB112C985CFB77E74; SizeAsReceived:6820; Count:44
x-tmn: [PHh+ps+6kF4Bp5C+Eyxk5jCCBGu+vZxB]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 74622e7d-3b7a-455b-f5af-08d7ddecd76e
x-ms-traffictypediagnostic: PU1APC01HT213:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Yk7RJVNxxfLpbI4la9j6+AF7eS6awQC/A7569qFOVuaydXMD/lObknkUPr0iv1w2IawSo6rlvqHxNgso8M3D1nTUnC/T+wAn2yVWvDrLESfaJmBu9w7oddD1hQoi/KorOcjSKdowAiKZcUfJWMgZr0Sg9A4IGhyeCNQOo8i79HapvIZlKGxjtpWPEy9m1ScQ
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: +KFzZkecr0PsHhfOE8FpKWXgt+04tK7UvGSyeMra2+aXWHSKAi2qpBvsGgcw00Qocjm4jlnJmZZ8aOAcqH1ruH3/JG64AzvnYYcnN5yHmWZhKg5tep1R8szfpLR3aItgs4YKGtnbTmhLohWIjSVSjw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402069CD033662DD56D11B0BA9DF0BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 74622e7d-3b7a-455b-f5af-08d7ddecd76e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2020 07:49:19.1688 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT213
Archived-At: <>
Subject: Re: [Roll] enrollment priority
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Apr 2020 07:49:24 -0000

Please find my resps inline.



    > 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
    > network?

First, I think that if node C had a MP of 127, then it would *NOT* advertise
itself as a Join Proxy.

[RJ] Consider non-6tisch case, where the 6LR's resources are full and does not want any new nodes to connect to it. In this case, it still needs to advertise its DIO for all the existing nodes which have already joined through it. The new nodes will see MP=127 and hence won't join. But the gist is, Node C has to keep advertising for all its existing nodes. It cannot stop sending DIOs.

So if it was sending Enhanced Beacons, then it
  a) set proxy prio to 0x7f.
  b) maybe even stop sending EBs [have to think about this]
[RJ] Not sure in case of 6tisch too if it can stop sending EBs? Since it may be needed for existing nodes who have already joined.
  c) not accept any unencrypted traffic!

so yeah, node D would be out of luck.

If node C *does* change to node A, then it would change it's priority.
But it has to do that, and maybe there are reasons why A won't accept it.

[RJ] Sure node A might have its own reasons to not accept it, but the MP suggests that it is willing to accept node C. The problem is when node C switches to Node A, the whole sub-DODAG rooted at C switches and this may result in node A's MP to reach 127. Since node B is now free, it's MP value will decrease. This can result in oscillations in the network.
At the very least these scenarios can be provided to the reader and if possible some mechanism/guideline to handle it.

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

I have added:

  This document uses the extensions mechanism designed into {{!RFC6550}}.
  It does not need any mechanism to enable it.

  6LRs that support this option, but whose parent does not send it SHOULD
  assume a value of 0x40 as their base value.
  The nodes adjust this base value based upon their observed congestion,
  emitting their adjusted DIO value to their children.

(0x40 is my wet-finger-in-the-air, seat-of-the-pants guess)

[RJ] Consider that a 6LR who does not support MP gets a DIO with MP=127. The 6LR will ignore the MP field and sends it DIO without MP and the downstream nodes will assume an MP of 0x40! This may be a problem.

    > 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.

Good.  Would more informative cross-references help?
Do you want to co-author?
[RJ] Yes, I would love to work on this problem statement.