Subject: [Roll] Call for reviews for draft-ietf-roll-nsa-extension

From: Ines Robles <[email-masked]>
Date: Thu, 6 Jun 2019 13:12:59 +0300

Dear all,

We would like to have reviews for draft-ietf-roll-nsa-extension-01.

Please let us know if you want to review it.

Thank you very much,

Ines and Peter

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Jun 2019 01:09:35 +0200

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.

AB

On Thu, Jun 6, 2019 at 12:13 PM Ines Robles <mariainesrobles=
[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 15:11:32 +0000

Hello all,

Here is my review of draft-ietf-roll-nsa-extension-02.
I found it well written, with the appropriate amount of introductory material and references.
I only have a few comments, as well as, this being me, a list of editorial nits. See below.
Best regards

Dominique

==

Comments

  *   section 3.4: I believe OPTIONAL and MAY should be lowercase here, since this draft only specifies the DMC extension, not the Objective Function.
  *   sections 4.1.1 and 4.1.2: the DMC header fields are defined in RFC6551, not 6550.
  *   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. ;-)
  *   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.
  *   Appendix A: does the experimental implementation do compression? If so, for information, what's the DIO size?

Nits

  *   section 2: missing colons after the two terms being defined.
  *   section 3: “included in operation” —> “included in the operation”
  *   section 3: alternative parent —> AP
  *   section 3: alterantive —> alternative
  *   section 3.1: “the source node S must know its grandparent sets both through nodes A, B, C, and D.” —> “both” is anadequate and can be removed altogether.
  *   section 3.2: “Therefore, node S can decide to use node B or D as its AP node, since given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D PD(D) = {Y, Z}.”. Invalid grammatical construct. Breaking this complex sentence into two simpler ones might help.
  *   section 3.3: “the node will check if its the Parent Set (PS) of its Preferred Parent (PP), has a common node with the PS of the potential AP.” —> “the node will check if the Parent Set (PS) of its Preferred Parent (PP) has a node in common with the PS of the potential AP.”
  *   section 4, 6LoRH type: is “https://tools.ietf.org/html/rfc8138#section-5.1” an editing mistake?
  *   section 4.1: “since it can help the alternative path from significantly deviating from the preferred path.” —> “since it can help the alternative path to not significantly deviate from the preferred path.”
  *   section 4.1.1: “Given the intended usage, when using the PS, the NSA object it is contained in MUST be used as a constraint in the DAG Metric Container.”. Complex sentence. Consider rephrasing, or simply remove it altogether.
  *   Section 5: “however it’s use” —> “however its use”
  *   Appendix A: “immediatelly” —> “immediately”. (several occurences).
  *   Appendix A: “Links are reset uniformly randomly between 70% and 100% every 60 seconds”. I guess you mean “Every 60 s, a new Packet Delivery Rate is randomly drawn for each link, with a uniform distribution spanning the 70% to 100% interval”.

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Ines Robles <mariainesrobles=[email-masked]<mailto:mariainesrobles=[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Thursday 6 June 2019 12:12
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [Roll] Call for reviews for draft-ietf-roll-nsa-extension

Dear all,

Thank you very much,

Ines and Peter

_________________________________________________________________________________________________________________________

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.

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Thu, 20 Jun 2019 11:39:32 +0200

Thank you so much Dominique for your review.
We will come back with an updated version, as well as with point to point responses to your comments.

Best,
Georgios and Aris

> On Jun 19, 2019, at 17:11, [email-masked] wrote:
> 
> Hello all,
> 
> section 3.4: I believe OPTIONAL and MAY should be lowercase here, since this draft only specifies the DMC extension, not the Objective Function. 
> sections 4.1.1 and 4.1.2: the DMC header fields are defined in RFC6551, not 6550.
> 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. ;-)
> 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. 
> Appendix A: does the experimental implementation do compression? If so, for information, what's the DIO size?
> 
> Nits
> section 2: missing colons after the two terms being defined.
> section 3: “included in operation” —> “included in the operation”
> section 3: alternative parent —> AP
> section 3: alterantive —> alternative
> section 3.1: “the source node S must know its grandparent sets both through nodes A, B, C, and D.” —> “both” is anadequate and can be removed altogether.
> section 3.2: “Therefore, node S can decide to use node B or D as its AP node, since given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and for node D PD(D) = {Y, Z}.”. Invalid grammatical construct. Breaking this complex sentence into two simpler ones might help.
> section 3.3: “the node will check if its the Parent Set (PS) of its Preferred Parent (PP), has a common node with the PS of the potential AP.” —> “the node will check if the Parent Set (PS) of its Preferred Parent (PP) has a node in common with the PS of the potential AP.”
> section 4, 6LoRH type: is “https://tools.ietf.org/html/rfc8138#section-5.1” an editing mistake?
> section 4.1: “since it can help the alternative path from significantly deviating from the preferred path.” —> “since it can help the alternative path to not significantly deviate from the preferred path.”
> section 4.1.1: “Given the intended usage, when using the PS, the NSA object it is contained in MUST be used as a constraint in the DAG Metric Container.”. Complex sentence. Consider rephrasing, or simply remove it altogether.
> Section 5: “however it’s use” —> “however its use”
> Appendix A: “immediatelly” —> “immediately”. (several occurences).
> Appendix A: “Links are reset uniformly randomly between 70% and 100% every 60 seconds”. I guess you mean “Every 60 s, a new Packet Delivery Rate is randomly drawn for each link, with a uniform distribution spanning the 70% to 100% interval”.
> 
> 
> De : Roll <[email-masked] <mailto:[email-masked]>> on behalf of Ines Robles <mariainesrobles=[email-masked] <mailto:mariainesrobles=[email-masked]>>
> Répondre à : "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> À : "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 21 Jun 2019 21:55:31 +0200 (CEST)

Hello Abdussalam,

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

> not help us understand but makes it more difficult.

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?

Kind regards
Aris

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 21 Jun 2019 22:04:15 +0200 (CEST)

Hello Dominique,

Thank you so very much for the detailed review and comments. They raise
good points and we will address them all carefully in the next version.
Responses to individual points follow inline.

On Wed, Jun 19, 2019 at 5:11 PM <[email-masked]> wrote:

>    - section 3.4: I believe OPTIONAL and MAY should be lowercase here,
>    since this draft only specifies the DMC extension, not the Objective
>    Function.
>
> I agree. I think I got a bit too trigger-happy with the capitalised key
words. Thank you.

>
>    - sections 4.1.1 and 4.1.2: the DMC header fields are defined in
>    RFC6551, not 6550.
>
> Of course, you are right. Incorrect reference. Thanks. Fixed.

>
>    - 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.
>
> You are right. We had received a (reasonable) request to spell out how the
DMC fields should work in the case of this extension and we did so.
And, no, I hadn't noticed that the Prec field does not have a default value
in the case of constraints in RFC6551. Sorry :)
I just assumed that it would be ignored in cases of constraints, so any
value would be valid.
Actually, in our implementation we sort the MCs based on Prec only for
metrics, so the value of Prec does not matter at all in constraints.
I dislike copy-pasting text, so I think that your suggestion makes the most
sense.

>    - 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. ;-)
>
> Yes, you are right and I see the point of it being superfluous.
Again, though, it was requested that we be explicit about the operation of
existing flags.
Basically, for both 4.1.1 (DMC flags) and 4.1.2 (NSA flags) we don't
actually redefine or limit the existing RFC6551 spec.
So, yes, we basically should say nothing other than "This is used only as a
constraint".
Ideally, I prefer to avoid restating things from other documents, but I
don't know what the right balance would be in this case.
What would you think about replacing sections 4.1.1 (DMC flags) and 4.1.2
(NSA flags) with a simple statement like:
*"The PS is used only within NSA objects configured as constraints"*

>
>    - 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.
With this in mind, what do you thing we should do? (pun intended)

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

>
> Nits
>
>    - section 2: missing colons after the two terms being defined.
>
> Fixed, thanks.

>
>    - section 3: “included in operation” —> “included in the operation”
>
> Fixed, thanks.

>
>    - section 3: alternative parent —> AP
>
> Fixed, thanks.

>
>    - section 3: alterantive —> alternative
>
> Fixed, thanks.

>
>    - section 3.1: “the source node S must know its grandparent sets both
>    through nodes A, B, C, and D.” —> “both” is anadequate and can be removed
>    altogether.
>
> Of course, fixed. Thanks.

>
>    - section 3.2: “Therefore, node S can decide to use node B or D as its
>    AP node, since given that PP(PP(S)) = Y, for node B PS(B) = {W, X, Y} and
>    for node D PD(D) = {Y, Z}.”. Invalid grammatical construct. Breaking this
>    complex sentence into two simpler ones might help.
>
> Thanks, it is quite difficult to read. Will use both here and in 3.1 the
same bullet-based presentation as in 3.3.

>
>    - section 3.3: “the node will check if its the Parent Set (PS) of its
>    Preferred Parent (PP), has a common node with the PS of the potential AP.”
>    —> “the node will check if the Parent Set (PS) of its Preferred Parent (PP)
>    has a node in common with the PS of the potential AP.”
>
> Thanks, fixed. Helps readability.

>
>    - section 4, 6LoRH type: is “
>    https://tools.ietf.org/html/rfc8138#section-5.1” an editing mistake?
>
> Yes, definitely. Mistake in XML.

>
>    - section 4.1: “since it can help the alternative path from
>    significantly deviating from the preferred path.” —> “since it can help the
>    alternative path to not significantly deviate from the preferred path.”
>
> Thanks, clearer as you propose. Fixed.

>
>    - section 4.1.1: “Given the intended usage, when using the PS, the NSA
>    object it is contained in MUST be used as a constraint in the DAG Metric
>    Container.”. Complex sentence. Consider rephrasing, or simply remove it
>    altogether.
>
> True, will break up and rephrase. Thanks.

>
>    - Section 5: “however it’s use” —> “however its use”
>
> Thanks, fixed.

>
>    - Appendix A: “immediatelly” —> “immediately”. (several occurences).
>
> Thanks. All fixed.

>
>    - Appendix A: “Links are reset uniformly randomly between 70% and 100%
>    every 60 seconds”. I guess you mean “Every 60 s, a new Packet Delivery Rate
>    is randomly drawn for each link, with a uniform distribution spanning the
>    70% to 100% interval”.
>
> Yes, exactly that. Will use your rephrasing as it's clearer.

Again, thank you very much for the comments and I look forward to your
reply.

Kind regards,
Aris

>
> De : Roll <[email-masked]> on behalf of Ines Robles <
> mariainesrobles=[email-masked]>
> Répondre à : "[email-masked]" <[email-masked]>
> À : "[email-masked]" <[email-masked]>