Re: [Roll] MOPex updates and extended control option query Mon, 01 November 2021 08:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B92E3A1140 for <>; Mon, 1 Nov 2021 01:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Status: No, score=-1.598 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ds67D2q8NXqA for <>; Mon, 1 Nov 2021 01:32:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E98733A1115 for <>; Mon, 1 Nov 2021 01:32:01 -0700 (PDT)
Received: from (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4HjR8w1y0rz5wD4 for <>; Mon, 1 Nov 2021 09:32:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1635755520; bh=fxQv781SI1lHRrbRsWsKYGsl+OSSVTSTCiGLynPedaM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=FovxFxaUJewPNKmnhKRGg4fDF8dA8e0DQaRGhnf0lCiyeBo/1yBbJMwehS+LpCodk DEgHf4u9DtPoLaRAwvmni66dUtRjThV5OorZ24JVV6r4V/alJjfIXi+jrUOpnxhAeA nVbeegLW6bywMGJHOcv3kyKfr6pcdBrCdWQYdUAfwQbT8WKcHRtt7XWUV3aIS9Dw+V eTYYlxv4FXtLuAlGkeDqPZOY7BSSoY8yOe01XTg6aGFW39LrgvNqz0UNJj01moZ4zC 26OYdbrdNz2mP1EQ3eizIMKUq6GmWYV6fcC7YdVBI14p8W69yW7175fK2azGo/PRF6 Enhd96Hx/Ld6g==
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] MOPex updates and extended control option query
Thread-Index: AQHXJjmlH6pBHSKxB0+avYwO5fCsf6vvqGRg
Date: Mon, 01 Nov 2021 08:31:59 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_36d17c17400c4bf3bad2b8edc9174cfforangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Roll] MOPex updates and extended control option query
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: Mon, 01 Nov 2021 08:32:09 -0000

Hello Rahul,

I’m digging up open items regarding our active documents., sorry if this comes up very late.
I’m curious about your proposal for an option “for the node to not join the network at all (not even as 6LN) if a control option is not understood”.
Do you have a use case for it that you could share?
I fail to see in which circumstance the node should not be allowed to join as a leaf node?


From: Roll [] On Behalf Of Rahul Jadhav
Sent: mercredi 31 mars 2021 16:25
To: Routing Over Low power and Lossy networks <>
Subject: [Roll] MOPex updates and extended control option query

Hello All,

The MOPex draft is refreshed with just editorial changes in this version.

However, I would like to raise one point that Pascal made during the IETF 110 session.

Currently, the MOPex draft extends the RPL control options with certain flags to handle cases where the control option is not understood by the node:
J-flag: Join only as 6LN
C-flag: copy option as-is even if not understood
I-flag: Ignore message altogether.

We could have an option for the node to not join the network at all (not even as 6LN) if a control option is not understood.
Any feedback on this would be appreciated.


---------- Forwarded message ---------
From: <<>>
Date: Wed, 31 Mar 2021 at 19:43
Subject: New Version Notification for draft-ietf-roll-mopex-03.txt
To: Michael Richardson <<>>, Pascal Thubert <<>>, Rahul Arvind Jadhav <<>>

A new version of I-D, draft-ietf-roll-mopex-03.txt
has been successfully submitted by Rahul Arvind Jadhav and posted to the
IETF repository.

Name:           draft-ietf-roll-mopex
Revision:       03
Title:          Mode of Operation extension
Document date:  2021-03-31
Group:          roll
Pages:          9

   RPL allows different mode of operations which allows nodes to have a
   consensus on the basic primitives that must be supported to join the
   network.  The MOP field in [RFC6550] is of 3 bits and is fast
   depleting.  This document extends the MOP for future use.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

The IETF Secretariat


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.