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

[Remous-Aris Koutsiamanis <[e-mail]>]

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 <[e-mail]> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>


*Comments from Dominique: *
On Wed, Jun 19, 2019 at 5:11 PM <[e-mail]> 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

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

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




*Comments from Abdussalam: *
On Mon, Jun 17, 2019 at 1:10 AM Abdussalam Baryun <
[e-mail]> 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?