Re: [Roll] NSA PS-set metric/constraint

<> Wed, 26 February 2020 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DE2F3A0771 for <>; Wed, 26 Feb 2020 03:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3vV0p-rGJrS0 for <>; Wed, 26 Feb 2020 03:02:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D5893A0770 for <>; Wed, 26 Feb 2020 03:02:39 -0800 (PST)
Received: from (unknown [xx.xx.xx.68]) by (ESMTP service) with ESMTP id 48SCZ54n0xz1ySS; Wed, 26 Feb 2020 12:02:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1582714957; bh=L6DakGDpv5F+Y3arkV80cUTUxkCiGYTSs9xNWWdaSSQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=aj50HUQWHHM4BBoBbLZCja3qOTKp57qmb2DPN3ZCBPMTWGQJjCSbExIrtxYN646zt 8qfjKI4cYJ7qqcTZALPgp68FLqtVUrw0v0PikoAT0CcH1x0qKLT460iECh4nZAxuWU D7NGnroUOom66g+ASCXolZJa7pssZThrNba2tJZji5Ja3cWbbseLe6tCkYKTlA8s1Q tvmy5lrdjfXKgNDhFTrNjOxa6OX/8C9e8YkVWIX2brjAEECO8CPTadvf1tPMC5fGSt 9+QflFmUxk30rRc+PQVC759VACJ2L+k6St9MKtq0sHeBoQ5W79053XLgBf+zQT5quU NvFByVjXsmC6g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by (ESMTP service) with ESMTP id 48SCZ5409Rz1xpY; Wed, 26 Feb 2020 12:02:37 +0100 (CET)
Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([fe80::81c9:5f:b9c5:1241%21]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 12:02:37 +0100
To: Routing Over Low power and Lossy networks <>, "Georgios Z. Papadopoulos" <>, Remous-Aris Koutsiamanis <>
Thread-Topic: [Roll] NSA PS-set metric/constraint
Thread-Index: AQHV4Ivxjv+kUNuhZ06uTfBtagn0rg==
Date: Wed, 26 Feb 2020 11:02:37 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <4CB81F6BFED16448A2243A17F56E09A7@adroot.infra.ftgroup>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Roll] NSA PS-set metric/constraint
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: Wed, 26 Feb 2020 11:02:43 -0000

Hello all,

The discussion below prompts me to question the way the Parent Set (PS)
appears in the Dodag Metric Container (DMC). Sorry if this comes up late
in the process.

The NSA object carrying the PS TLV is currently specified to be Contraint.
This shows up only once in the text (page 11).
There are some issues associated with the PS being part of a constraint:
RFC6551 says
"In the presence of a constraint, a node MUST include a metric of the
same type.  That metric is used to check whether or not the   constraint
is met.  In all cases, a node MUST not change the content   of the
The behaviour proposed in this draft would have to create an exception for
all of the above.

Alternate proposal:
Could the PS be part of an NSA Metric? After all, it is used to help
select which parent(s) are best suited for upward routing, not to prune
downlink propagation of the DIO along a path that exceed some metric
value. C=0, R=1, P=1 comes to mind for this metric.
I understand that you are trying to create a CA OF that mimicks as much of
the MRHOF as possible, and MRHOF says it doesn't use DMCs. So you would
have to specify that the CA OF is different in that it has to look at the
NSA Metric sub-object inside the DMC object. But in the current situation,
you already have to specify that the CA OF has to look at the NSA
Constraint sub-object inside the DMC object. With a metric, you could use
the Prec. field to highlight the fact that the PS TLV s a secondary
metric, beyond the implied ETX of MRHOF. Or you could send the ETX Metric
sub-object explicitely, at the expense of a few extra bytes, and state
that the CA OF simply uses DMCs.



Le 11/02/20 11:25, « Roll on behalf of Georgios Z. Papadopoulos »
< on behalf of> a écrit :

>Dear Rahul and all,
>Once again, thank you for spotting this issue. Great catch!
>We are happy with any of the following solutions :
>- We can indeed tie the PS set metric to CAOF specifically in the draft.
>Furthermore, the policies in CAOF are extensible (we only specify
>examples), so potentially another policy could make a different use of PS
>as part of CAOF.
>- We can indeed explain the issue in the draft so that the implementers
>decide on their own how to handle it.
>Additionally, since the whole RPL instance uses the same OF, we would
>expect that if an OF which understands the TLV is used, then all the
>nodes will know how to process it.
>So, this issue should not be very common.
>- Another option would be to add an exception to the "all TLVs need to be
>propagated” rule from RFC 6551 specifically for the PS TLV.
>The exception would specify that the PS TLV would be dropped if not
>Best regards,
>Georgios and Aris
>> On Feb 11, 2020, at 04:32, Rahul Jadhav <> wrote:
>> Hello Authors of NSA extn and all,
>> One more question in the context:
>> The draft adds new routing metrics/constraints (PS set) nested as part
>> of the NSA parent metric.
>> My question is with regards to what happens if this routing metric is
>> used outside of the CAOF. Any metrics/constraints could be used by any
>> OF and thus PS set metric defined by the draft can be used by other
>> OF.
>> RFC 6551 says that if the metric is not understood by the node and if
>> it is a 6LR then it may not process it but it has to propagate it.
>> Unlike other metrics, the PS set metric in this case contains
>> link-local values that cannot be used beyond link-local. As such upon
>> propagation, any downstream 6LR that understands the PS set metric
>> would use the information and get impacted adversely.
>> Should we tie the PS set metric to CAOF specifically in the draft, in
>> which case this problem won't be there? Or we can specify this issue
>> as it is for the readers to understand the problem if the PS set is
>> used outside of the CAOF. Either way works for me.
>> Best,
>> Rahul
>> _______________________________________________
>> Roll mailing list
>Roll mailing list


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.