Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt

<dominique.barthel@orange.com> Mon, 01 July 2019 15:26 UTC

Return-Path: <dominique.barthel@orange.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 36C76120128 for <roll@ietfa.amsl.com>; Mon, 1 Jul 2019 08:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 8ePGTvrfkKXn for <roll@ietfa.amsl.com>; Mon, 1 Jul 2019 08:26:27 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36DF12011B for <roll@ietf.org>; Mon, 1 Jul 2019 08:26:26 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45crnF06Kvz5vw1; Mon, 1 Jul 2019 17:26:25 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 45crnD53P4zDq7t; Mon, 1 Jul 2019 17:26:24 +0200 (CEST)
Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([fe80::8899:bbc3:9726:cd5e%21]) with mapi id 14.03.0439.000; Mon, 1 Jul 2019 17:26:24 +0200
From: dominique.barthel@orange.com
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "aris@ariskou.com" <aris@ariskou.com>, Pascal Thubert <pthubert@cisco.com>, "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt
Thread-Index: AQHVMCFX3KMwTFoADUOgqJOvBfE8KQ==
Date: Mon, 01 Jul 2019 15:26:23 +0000
Message-ID: <20818_1561994784_5D1A2620_20818_214_5_D93FEF87.62BE1%dominique.barthel@orange.com>
References: <156139562335.17453.10181644975970552720@ietfa.amsl.com> <CAK76Pr=cOTdAfnxyC9Bq2BPqEzwsH=2LvbZsGuSJjuV6uyvqrQ@mail.gmail.com>
In-Reply-To: <CAK76Pr=cOTdAfnxyC9Bq2BPqEzwsH=2LvbZsGuSJjuV6uyvqrQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_D93FEF8762BE1dominiquebarthelorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/kLaG9banQUWtmegBrkgminv12l8>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt
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: Mon, 01 Jul 2019 15:26:31 -0000

Hello Aris, Georgios and all,

[removing I-d-announce@ietf.org<mailto:I-d-announce@ietf.org> from the CC list]
Thanks for your the new draft revision and for your responses itemised below.
See my comments inline.
In short, 2 points out of 3 are "clear to go" from my side, and the third one is "ask Pascal, I leave him the final word".
Best regards,

Dominique


De : Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Remous-Aris Koutsiamanis <aris@ariskou.com<mailto:aris@ariskou.com>>
Répondre à : "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Date : Tuesday 25 June 2019 11:04
À : "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Cc : "Dominique.Barthel@orange-ftgroup.com<mailto:Dominique.Barthel@orange-ftgroup.com>" <Dominique.Barthel@orange-ftgroup.com<mailto:Dominique.Barthel@orange-ftgroup.com>>, "i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>" <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Objet : Re: [Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt

Hello,

we have updated the draft-ietf-roll-nsa-extension draft to address most of the comments from Dominique.
The remaining comments that we are awaiting an answer to follow below to make it easy to focus on the remaining issues.

Best,
Aris

On Mon, Jun 24, 2019 at 7:00 PM <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : RPL DAG Metric Container Node State and Attribute object type extension
        Authors         : Remous-Aris Koutsiamanis
                          Georgios Papadopoulos
                          Nicolas Montavont
                          Pascal Thubert
        Filename        : draft-ietf-roll-nsa-extension-02.txt
        Pages           : 14
        Date            : 2019-06-24

Abstract:
   Implementing Packet Replication and Elimination from / to the RPL
   root requires the ability to forward copies of packets over different
   paths via different RPL parents.  Selecting the appropriate parents
   to achieve ultra-low latency and jitter requires information about a
   node's parents.  This document details what information needs to be
   transmitted and how it is encoded within a packet to enable this
   functionality.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02
https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-nsa-extension-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll


Comments from Dominique:
On Wed, Jun 19, 2019 at 5:11 PM <dominique.barthel@orange.com<mailto:dominique.barthel@orange.com>> wrote:

  *   section 4.1.1: in RFC6551, the Prec field is meant to be used for metrics, not for constraints. Therefore, it is unused for this NSA extension, which is a constraint. Unfortunately, RFC6551 forgot to specify a default value. Is this the reason why you say “used according to RFC…”? I suggest you use the same text for the Prec and A fields. It could be quoting the text from RFC6551, of referring the reader to it, or say nothing.
  *   section 4.1.2: “For clarity reasons, the usage of the PS places no additional restrictions on the NSA flags (’A’ and ’O’), which can be used as normally defined in [RFC6550]”. The clarity reasons escaped me, as well as the additional restrictions that could have been placed but which have not! Anyway, RFC6551 states that the A Field is not used with constraints. Overall, I think this whole subsection could go away since it specifies nothing, says that it does not specify anything but does not say why it says it. ;-)

We replaced 4.1.1 and 4.1.2 with just "The PS is used only within NSA objects configured as constraints and is used as per [RFC6551<https://datatracker.ietf.org/doc/html/rfc6551>]." in Section 4.1
[DB] sounds good.

  *   Section 4.2: "Therefore, the PS IPv6 address(es) field SHOULD be compressed using the compression method for Source Routing Header 6LoRH (SRH-6LoRH)". I understand that a similar compression mechanism could be used. However, this requires defining a protocol element that does not exist today, unless I missed something. Therefore, the normative SHOULD is irrelevant. I guess this section is merely suggesting future work.

We do have this almost fully implemented (almost: only works in single root RPL instances).
Would it make sense to spell out the exact specification of the compression even if it is largely a copy of the SRH-6LoRH compression method?
I can lowercase the SHOULD, but using this kind of compression really makes big difference in practice.
[DB] talk to Pascal about this, he looks pretty knowledgeable in SHOULDs. Anyway, if you capitalise SHOULD, then you have to explain the consequences of not following the recommendation. Whereas if you lowercase it, it's only free advice. You can stil explain why you think it is a good idea. My worry is that a capitalised SHOULD here will stop the draft later in the IESG processing because you are referring to a non-existent specification (formally speaking). Again, ask Pascal, I totally trust him on this question.


  *   Appendix A: does the experimental implementation do compression? If so, for information, what's the DIO size?

Yes, it does do compression.
The size depends on the other DIO options present.
We have tested using Contiki with 802.15.4-TSCH, so the max packet size is 127 bytes without fragmentation.
Without compression we can fit max 2 parents in the PS and we have to remove the Prefix Information Option (if i remember correctly).
I can look up the actual byte count if that's helpful.
[DB] fine, I was just curious. Good to hear that this compression is actually implemented, even at preliminary stage.


Comments from Abdussalam:
On Mon, Jun 17, 2019 at 1:10 AM Abdussalam Baryun <abdussalambaryun@gmail.com<mailto:abdussalambaryun@gmail.com>> wrote:
Hi Ines and Peter,

IMHO the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase, and using references of architectures does not help us understand but makes it more difficult.

Thank you very much for reading this draft and providing us with your comments. It is very much appreciated.

I would like to ask some clarifying questions if you don't mind.
"the draft is not clear in its use-case, I think it must include rfc8578 to clarify its usecase"
We are aware of the DetNet usecases and following your comment we will point to the rfc8578 and specifically Section 5. Wireless for Industrial Applications, which is what we are aiming at with this draft.
We have attempted to strike a balance between the introductory material present in the draft (to help it stand alone) and referencing other sources to avoid reiterating things.
If you think that just referencing rfc8578 Section 5. Wireless for Industrial Applications is insufficient, maybe you could provide a bit more detail on what should and should not be present in the draft.

"using references of architectures does not help us understand but makes it more difficult"
Could you please be more explicit?
We reference two architectures in this draft.
In Section 1 Introduction, we refer to the 6TiSCH architecture, as the base upon which this draft builds.
In Section 1 Introduction  we reference the DetNet architecture as context for aim of maximizing packet delivery rate and minimizing latency and jitter.
In Section 5 Controlling PRE we reference the DetNet architecture specifically as an example to allow the fine-grained control of PRE usage via flow labels.

Which of these or other references to architectures did you have in mind?


[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

_________________________________________________________________________________________________________________________

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.