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

Remous-Aris Koutsiamanis <aris@ariskou.com> Fri, 28 February 2020 23:52 UTC

Return-Path: <aris@ariskou.com>
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 2AA823A041A for <roll@ietfa.amsl.com>; Fri, 28 Feb 2020 15:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=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=mailfence.com header.b=FnGJHDFt; dkim=pass (2048-bit key) header.d=ariskou.com header.b=DWTk29Rt
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 iTwj_ks97VRw for <roll@ietfa.amsl.com>; Fri, 28 Feb 2020 15:52:02 -0800 (PST)
Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F853A0408 for <roll@ietf.org>; Fri, 28 Feb 2020 15:52:01 -0800 (PST)
Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DD0EF1B72 for <roll@ietf.org>; Sat, 29 Feb 2020 00:51:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1582933919; bh=iZaD2KpshyW7H+70dUOFmDAM/B5JMGIQv8pNdZA48xA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FnGJHDFtbIkfchTGObQoQxlg9zJd2c6euoW0t9bVdT3inArVQS4Qnas8DRB2TrpOq 0kLHdoSdy9jZ3AxI7Kj2XWEn89z+YIJaziXav/1oY6Dd/FMV23/AHaVNSbpAYksZj1 G5oTuIaa/N/UtcTNl/UxaQ+I2MBZdZrJ2Sd5Ogf071Ky+aGOLZTn0e1Ge8jY+d7b2o 1ZjdopmeM45QA0apzMsmGXwSDdafL7U+gxCt54HlMyZOTXmLiAN2B9G2QOIiNUT+iL +6MPcIxeCjL/nBTVfp4OgRLzWMPKsJuaPNZwjG+Si8GZBazvm2pFvhUKudcFMGqu7s zvaVm+w8qtfzQ==
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1582933919; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Content-Type; l=21522; bh=iZaD2KpshyW7H+70dUOFmDAM/B5JMGIQv8pNdZA48xA=; b=DWTk29RtIcXVS3eqtfncsas94T9h0xNF2WpE1tdR7UlmyGusJnm8vqFlBOQhMDlK JajI41uYiW0D2cIcCl0ASZWH6oDXqB1pZX86WwWSdp5i5qBFYpVmSPpJK/MRBMV2aZa SspS8ErcnF5BI/gcmTX1cit9R9JmKBwmLywMnXjpg6Nuz2Ws+HZdOBZBIAYcZQfgv9W yWR5KQEBr9xt3KiZQEkDDXvAOkkQ6HaXryUvKfpsihIGdIJKUtCb048HEoP9lDx+Hg3 jQiv68LLQmS6EMnMGVdfbTBCtElNiZH+wFRfrGSQQX0g7sKb22fbGCTKDl/hFsx/UAE fd2HBCiUHg==
Received: by smtp.mailfence.com with ESMTPA for <roll@ietf.org> ; Sat, 29 Feb 2020 00:51:54 +0100 (CET)
Received: by mail-il1-f172.google.com with SMTP id a6so4333878ilc.4 for <roll@ietf.org>; Fri, 28 Feb 2020 15:51:53 -0800 (PST)
X-Gm-Message-State: APjAAAXJnyl2v4NktmndHdxsUYE8KAWBNrGS4uWjN3UbUFrgbppzHlx8 +kvjAaLB2DX+2j7FXXrdADW3ZAA1FL6K/UkOabg=
X-Google-Smtp-Source: APXvYqzP9mGq46rh4f03i31G6MBXeTvH4zU60/AM3e9YmIYfD60Rg7Rhd9NXOxPQziF9B8PEXxioPr5MT1o1ftxoy5Q=
X-Received: by 2002:a05:6e02:c8d:: with SMTP id b13mr6961519ile.42.1582933909240; Fri, 28 Feb 2020 15:51:49 -0800 (PST)
MIME-Version: 1.0
References: <CAO0Djp2W2N-_eACyQNZcapah=AugHRC0fwsg2nhuovZaXa7mUw@mail.gmail.com> <D9CDCE2C-92B4-4B92-AB17-01CC3ECD1047@imt-atlantique.fr> <28813_1582714957_5E56504D_28813_497_1_DA7C05D5.71025%dominique.barthel@orange.com>
In-Reply-To: <28813_1582714957_5E56504D_28813_497_1_DA7C05D5.71025%dominique.barthel@orange.com>
From: Remous-Aris Koutsiamanis <aris@ariskou.com>
Date: Sat, 29 Feb 2020 00:51:56 +0100 (CET)
X-Gmail-Original-Message-ID: <CAK76PrmcuDnJ3hVBZkgCZ6z2eLNAREtKL244BGRXtA6CsVu3xA@mail.gmail.com>
Message-ID: <CAK76PrmcuDnJ3hVBZkgCZ6z2eLNAREtKL244BGRXtA6CsVu3xA@mail.gmail.com>
To: dominique barthel <dominique.barthel@orange.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, Rahul Jadhav <rahul.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005d00a8059fab85b2"
X-ContactOffice-Account: com:113819248
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/d-UcEPW3ess3-rAZzalXU6gW2X4>
Subject: Re: [Roll] NSA PS-set metric/constraint
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, 28 Feb 2020 23:52:05 -0000

Hello Dominique,

thank you very very much for this. Comments inline.

On Wed, Feb 26, 2020 at 12:02 PM <dominique.barthel@orange.com> wrote:

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

Oh, better now than later :)


> 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
> constraint."
> The behaviour proposed in this draft would have to create an exception for
> all of the above.
>

You are, of course, absolutely right.

It is interesting that when we started this work
(draft-pkm-roll-nsa-extension-00 / April 2018) we initially specified a
metric instead of a constraint, but in the immediately next version
(draft-koutsiamanis-roll-nsa-extension-01 / July 2018) we switched to the
constraint specification.
I absolutely agree that making an exception to this is undesirable.
>From the very first moment we wanted to avoid changing as few things as
possible to keep things simple and predictable.


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

So I read a bit more about this. So C=0 means "use as a routing metric", OK.
R=1 means "use as a recorded metric", i.e. not aggregated, because
aggregated makes no sense, OK.
Now, P=1 means that one or more of the nodes on the path did not record the
metric. So, it's less a "command" and more a report of previous behaviour.

My question is: it seems impossible that *all* the parent sets can be
recorded along the path due to size, so each node *replaces* the received
parent set with it's own.

We can specify this with text of course, but I have not seen another
existing metric that behaves like this.
On the other hand, the NSA metric object is not used a lot, and if it makes
sense for any metric to be replaced rather then appended to a list of
metrics, that metric would be NSA.

I am not sure about that P=1 part though and how it relates to replacing
the existing metrics.
If I understand this correctly, a node reporting it's own parent set in the
NSA will set P=1 basically to let the receiving nodes know that they should
not expect to find inside all the metric along the whole path, but only a
part of it, and in our case from just the sending node.

Am I getting this right?



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


Actually, MRHOF does use DMCs, but only additive ones:

page 3:
   "Because MRHOF seeks to minimize path costs as described by metrics,
   it can only be used with additive metrics.  MRHOF does not support
   metrics that are not additive."

  "For example, the use of MRHOF with the latency
   metric allows RPL to find stable minimum-latency paths from the nodes
   to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]."


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


No problem here.


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


There is only minor issue. The fact is that the information in the parent
set is used a filter to filter out the nodes that do not comply with the
Common Ancestor policy selected.
So, the PS / NSA metric would actually need to have *higher* precedence
(lower prec) than the other metric used (e.g. ETX).
However, this should be simple to explain.


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

This is needed, but just so that we can specify prec >0 for the ETX metric.


> Thoughts?
>
> Dominique
>

Again, thank you so much.
This was something which we definitely should have handled.

Please let me know if this solution is OK, and I will update the draft ASAP
to make the March 9th cut-off date.

Best,
Aris



>
> Le 11/02/20 11:25, « Roll on behalf of Georgios Z. Papadopoulos »
> <roll-bounces@ietf.org on behalf of
> georgios.papadopoulos@imt-atlantique.fr> 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
> >understood.
> >
> >
> >Best regards,
> >Georgios and Aris
> >
> >
> >> On Feb 11, 2020, at 04:32, Rahul Jadhav <rahul.ietf@gmail.com> 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@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >
> >_______________________________________________
> >Roll mailing list
> >Roll@ietf.org
> >https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>