Subject: Re: [Roll] IoT-dir last call review of draft-ietf-roll-useofrplinfo

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 18:29:54 +0300

Hi Charlie,

Many  thanks for your review, we really appreciate all your comments and
suggestions to improve the draft. we believe that version 30 addresses your
concerns.

Please find answers in-line.

--------------------------------------------

My main technical concern has to do with the attempt to classify RPI Option
Types 0x23 and 0x63 as somehow being variants of the same Option Type.  I
don't think this is really legitimate; they have to be considered to be two
different Options. I believe the idea is that it should be simple to
implement both together, and type 0x23 is likely to survive traversal of
the Internet.  An intermediate device that implements 0x63 but not 0x23
will not process any of the configuration options present in 0x23, but at
least the packet won't be dropped. I'm not sure how serious this problem is
for intermediate 6LRs in the path of a 0x23 packet traversing the LLN, but
those configuration options are meant for consumption by such intermediate
6LRs.

<author>

We believe that is the same Option Type, with the value updated from 0x63
to 0x23.

The network would switch to 0x23 when all the nodes are capable to process
it.

</author>

One thing that would help, is to include in the overview a very succinct
list of design requirements and also a list of assumptions made during the
design.  I had wanted to create this list but that would take another day.
Here is a start, and I hope that any misunderstanding that I have will be
minor:

Requirements:

1. RPI has to be in every packet that traverses the LLN

2. Because of (1), packets from the Internet have to be encapsulated

3. Extension headers may not be added or removed except by the sender or
the receiver

4. Packets that will traverse RPI-unaware nodes need encapsulation, but
only sender or receiver can add the new RPI option (0x23)

5. Non-storing mode requires downstream encapsulation by root for RH

Assumptions:

- Each IPv6 node (including Internet routers) obeys RFC 8200, so that 0x23
RPI can be safely inserted.

- All 6LRs obey RFC 8200

These requirements and assumptions determine the entries in the dozens of
tables included within the document.  Without a clear grasp of them, it is
easy to get lost in the sea of details about header insertion and
encapsulation.

<author>

Very good idea, thank you.

We added a list of Requirements and Assumptions.

Requirements:

1- The RPI option has to be in every packet that traverses the LLN

2-. Because of (1), packets from the Internet have to be encapsulated

3-. A Header cannot be inserted or removed on the fly inside an IPv6 packet
that is being routed.

4-- Extension headers may not be added or removed except by the sender or
the receiver.

5-- RPI and RH3 headers may be modified by routers on the path of the
packet without the need to add and remove an encapsulating header

6-- An RH3 or RPI Option can only be removed by an intermediate router if
it is placed in an encapsulating IPv6 Header, which is addressed to the
intermediate router.

.7 Non-storing mode requires downstream encapsulation by root for RH3.

Assumptions:

  This document assumes that the LLN is using the no-drop RPI option

      (0x23).

      - Each IPv6 node (including Internet routers) obeys [RFC8200]

     8200, so that 0x23 RPI can be safely inserted.

      - All 6LRs obey [RFC8200].

      - The RPI is ignored at the IPv6 dst node (RPL-unaware-leaf).

      - The leaf can be a router 6LR or a host, both indicated as 6LN.

      - Non-constrained uses of RPL are not in scope of this document.

      - Compression is based on [RFC8138].

      - The flow label [RFC6437] is not needed in RPL.

</author>

Most of my many comments are editorial.  I think that the draft could be
easier to read with fewer digressions, and more consistent use of
acronyms.  I have made a great many example revisions directly into the
attached text file, which I hope will receive consideration by the
authors.  Each editorial comment individually is typically less important
than a technical error, but taken together I think they would greatly
promote readability and thus increase the likelihood that implementers will
be able to understand the intention of the specification.   I have also
inserted additional comments into the file, tagged by my initials "CEP:".
Here are some overall comments.

   -

    not-RPL-aware --> RPL-unaware
   -

    Raf could be confused as "RPL-aware forwarder".   Please change
   acronyms. One possibility: ~Raf --> RuL,   Raf --> RaL (for.,
   "RPL-aware-Leaf", "RPL-unaware-Leaf", respectively)

<author>

Fixed, to RPL-Unaware-Leaf (RUL) and RPL-Aware-Leaf (RAL)

</author>

   -

    Since the document already uses acronyms in an essential way, please
   also use them to improve clarity and shorten subsection titles, etc.

<author> Fixed </author>

   -

    Captions to figures and subsection titles should typically fit on a
   single line

<author>

We tried to fix as much as possible in one line.

</author>

I would like to verify the design assumptions and design requirements, and
then use that knowledge to check the details of each of the 24 use cases.
One improvement that would be *very* helpful for this purpose, would be to
assert *which* of the design requirements underlies each matrix entry for
the 24 summary tables.

<author> thank you very much for your hard work on the review </author>

===========================================================

   Some of the use cases here described use IPv6-in-IPv6

   encapsulation.  Such uses follow RFC6040 [RFC6040] to construct

   the explicit congestion notification (ECN) field of the IP header upon

   entry to and exit from any IPV6-in-IPV6 tunnel.

   [I-D.ietf-intarea-tunnels] is also related.

CEP: Should say HOW it is related.

<author> Fixed </author>

CEP: Note: the following information does NOT belong in Terminology.

<author> Fixed, added in a new section </author>

   RPL defines the RPL Control messages (control plane) as subtypes of

   ICMPv6 [RFC4443] message Type 155.

CEP: Not sure how much this adds to the clarity of the document, but O.K.

   RPL supports two modes of Downward traffic.  In storing mode,

CEP: The abbreviations here were never used again and so deleted.

<author> Fixed </author>

2.  Terminology and Requirements Language

      Terminology defined in [RFC7102] applies to this document: LBR, LLN,

   RPL, RPL Domain and ROLL.

CEP: Below, it is claimed that LBR is defined in 6775.

<author> Fixed </author>

   Raf: RPL-aware-leaf, i.e., a RPL-aware-node which is a leaf of a

        (Destination Oriented Directed Acyclic Graph) DODAG

   Ruf: RPL-unaware-leaf, i.e., a RPL-unaware-node which is a leaf of a

        (Destination Oriented Directed Acyclic Graph) DODAG

   RPL-aware-node: A device which implements RPL.  Such a device can be

   found inside the LLN or outside LLN.

   RPL-unaware: A device which does not implement RPL.  The device can be

   found inside the LLN.  In this document a RPL-unaware node which is a

   leaf of a DODAG is called RPL-unaware-leaf (Ruf).

   Tolerant: able to accept or forward packets with RPL artifacts

             (whether RPL aware or not)

   Intolerant: unable to accept or forward packets with RPL artifacts

<author> we have fixed the terminology section, but we are unsure about
tolerant and intolerant </author>

CEP: see below.  This terminology isn't needed.

   Flag Day: A transition that involves having a network with different

   values of RPL Option Type.  Thus the network does not work correctly.

  <author> We think that the definition is for helping newcomers </author>

   Non-SM: Non-storing Mode, in which intermediate 6LRs do not maintain

   routing state so that source routes are needed.

   SM: Storing Mode, in which intermediate 6LRs maintain routing

   state so that source routes are not needed.

 <author> added a definition of NonSM and SM</author>

<!--CEP: IPv6 defines the Option Type as the entire octet.  Thus, changing

     the first two bits means that this document is defining a NEW

     Option Type.  As a result, this document does NOT update RFC 6553.  -->

<author>

We believe that is the same Option Type, with the value updated from 0x63
to 0x23.

The network would switch to 0x23 when all the nodes are capable to process
it.

</author>

   0x63 as the RPI value.  A move to 0x23 will not be understood by

   those networks.  It is suggested that implementations accept both

   0x63 and 0x23 when processing.

CEP: Which implementations?  What processing?

<author> Fixed </author>

   When forwarding packets, implementations MUST use the same value as

   was received (the RPI type code MUST remain unchanged [RFC8200]).

   This allows incremental upgrades to the network, and allows the

   DODAG root to know which parts of the network are upgraded.

CEP: Should xref the part of the document which explains this

     in more detail.

<author> Fixed </author>

   When originating new packets, implementations SHOULD be configured

   for which RPI Option to use.  This configuration is controlled

   by a new flag in the DIO Configuration Option as described below.

   A network which is switching from 6lowpan compression [RFCnnnn]

   to that described in [RFC8138] will experience a flag day

   in the data compression anyway, and if possible this change can be

   deployed at the same time.

CEP: Devices in such a network could accept both types of compression.

<author> not applicable  </author>

   By using RPI option type 0x23 instead of 0x63, [RFC8200] Section 4.2

   compliant nodes become tolerant of RPL artifacts.  There is

   therefore no longer a necessity to remove the artifacts when sending

   traffic to the Internet.  This document clarifies when to use an IPv6-

   in-IPv6 header, and what IPv6 addresses to use.  The Hop-by-Hop Options

   Header containing the RPI option MUST always be added when 6LRs

   originate packets without IPv6-in-IPv6 headers.  IPv6-in-IPv6

   headers MUST always be added when a 6LR needs to insert

   a Hop-by-Hop Options Header containing the RPI option.

   The IPv6-in-IPv6 header is addressed to the RPL root when on the way up,

   and to the end-host when on the way down.

CEP: The following paragraph belongs MUCH earlier in the document, probably

     in the overview or else a new section entitled "Applicability"

   Non-constrained uses of RPL are not in scope of this document, and

   applicability statements for those uses may provide different advice,

   E.g.  [I-D.ietf-anima-autonomic-control-plane].

<author> Fixed, moved to Introduction  </author>

3.2.  Updates to RFC6550: DODAG Configuration Option Flag for new RPI.

CEP: I don't think the document really needs to discuss "Flag Days".

     It is *especially* unfortunate in sentences such as the next sentence

     where a "flag" is defined to avoid a "flag day".  The document

     would be better simply mentioning "lack of interoperation" instead.

<author> We define a flag day as a lack of interoperation </author>

   In order to avoid a Flag Day caused by lack of interoperation between

   new RPI (0x23) and old RPI (0x63) nodes, this section defines a DODAG

   Configuration Option flag

   in the DIO Configuration Option, to indicate when then new RPI option

   can be safely used.   RPL-capable nodes then

   know if it is safe to use 0x23 when creating a new RPI.  A node that

   forwards a packet with an RPI MUST NOT modify the option type of the

   RPI.  If the DODAG Configuration Option flag is received with a value

   zero (which is the default), then new nodes will remain in RFC6553

   Compatible Mode, and originate traffic with the old-RPI (0x63) value.

   4.  Sample/reference topology

   A RPL network is typically composed of a 6LBR (6LoWPAN Border

   Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LNs

   (6LoWPAN Nodes) leaves logically organized in a DODAG structure.

CEP: Already defined these in Terminology.

<author> Fixed  </author>

  5.  Use cases

   In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6

   encapsulation are analyzed for a number of representative traffic flows.

   The use cases describe the communication in the following cases:

   - between RPL-aware-nodes with the root (6LBR)

   - between RPL-aware-nodes with the Internet

   - between Ruf nodes within the LLN (e.g. see Section 6.1.4)

   - inside of the LLN when the final destination address resides outside

     of the LLN (e.g. see Section 6.2.3).

   The use cases are as follows:

<author> Many thanks for this text improvements  </author>

 In this specification, an RH3 or RPI Option can only be removed by an

   intermediate router if it is placed in an encapsulating IPv6 Header

   addressed to the intermediate router.  If so, the whole encapsulating
header

   must be also removed, but a replacement may be added.  Sometimes the
outer

   IP headers being addressed to the next hop router use

   link-local addresses.

CEP: Maybe this should ALWAYS be the case, since it's only for a single hop.

<author> we added as requirement  </author>

6.1.1.  Storing Mode: from Raf to root

   In storing mode, RFC 6553 (RPI) is used to send RPL Information

   instanceID and rank information.

CEP: Should probably delete the following paragraph.  It is not germane

     to the subject of this section.

   As stated in Section 16.2 of [RFC6550] a Raf node does not

   generally issue DIO messages; a leaf node accepts DIO messages from

   upstream.  (When the inconsistency in routing occurs, a leaf node

   will generate a DIO with an infinite rank, to fix it).  It may issue

   DAO and DIS messages though it generally ignores DAO and DIS

   Messages.

<author> deleted </author>

   In this case the communication flow is as follows:

   Raf --> 6LR_i --> ... --> 6LR_i --> root(6LBR)

   As previously mentioned, 6LRs and 6LBR are always full-fledged RPL
routers.

CEP: Need definition for full-fledged.  Or, better, delete this sentence.

<author> deleted </author>

   Figure 8 summarizes the headers needed

   for this use case.  In the figure, IP6-IP6 refers to IPv6-in-IPv6.

CEP: Could use "Encaps" instead of "IP6-IP6" (or "Decaps").

<author> fixed in terminology </author>

    Figure 8: Storing mode: The use of headers from Ruf

      to root.  [1] Case where the IPv6-in-IPv6 header is

    addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6

                 header is addressed to the root (Node A).

CEP: Would be better to put [1] and [2] into footnotes, or else into

     the body of the text.

<author> fixed, included in the text </author>

6.2.1.  Storing Mode: from Raf to Internet

   RPL information from RFC 6553 may go out to Internet as it will be

   ignored by nodes which have not been configured to be RPI aware.

CEP: At least the ones that have been updated to obey the newer
specification.

<author> fixed, added in assumptions </author>

   Figure 9 summarizes header processing for this use case.

CEP: Each such table should be a Table, not a Figure.

   In the figure, IP6-IP6 refers to IPv6-in-IPv6.

<author> for complex tables we use ascii  figure </author>

CEP: Should just put IP6-IP6 in Terminology if you're going to use it, to

     avoid duplication.

<author> fixed in terminology </author>

   The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed

   either to the root, or hop-by-hop such that the root can remove the

   RPI header before passing upwards.  The IPv6-in-IPv6 addressed to the

   root cause less processing overhead.  On the other hand, with hop-by-

   hop the intermediate routers can check the routing tables for a

   better routing path, thus possibly more efficient and faster.

   Implementation should decide which approach to take.

CEP: This should be controlled by a configuration parameter,

     maybe something like (ENCAPS_TO_ROOT).

<author> dont understand </author>

   The originating node SHOULD leave the IPv6 flow label as zero

   so that the packet can be better compressed through the LLN.  The

   6LBR will set the flow label of the packet to a non-zero value when

   sending to the Internet.

CEP: Why?  Where is this specified?

<author> “we point to RFC8138 for compression  and RFC6437 for details on
flow label </author>

   The final node should be able to remove the IPv6-in-IPv6

   headers which are addressed to it.  The final node ignores the

   RPI and does not process it.  Further details about

   this are mentioned in [I-D.thubert-roll-unaware-leaves], which

   specifies RPL routing for a 6LN acting as a plain host and not aware

   of RPL.

   The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to

   zero in order to aid in compression.

CEP: Is this really legitimate?  How would the original flow label

     be restored?

<author>

It is inside of the LLN, so when adding the IPv6-in-IPv6 header the root
can set the flow label of zero, since it is not needed for RPL.

</author>

   An example flow could be: F --> D --> B --> E --> H

   6LR_ia (Node D) is an intermediate router from source to the common

CEP: Why were the quotes used below?

   parent (6LR_x) (Node B) In this case, 1 <= ia <= n, where n is the number

   of routers (6LR) that the packet traverses from 6LN (Node F) to

   the common parent (6LR_x).

<author> Fixed </author>

   6LR_id (Node E) is an intermediate router from the common parent

   (6LR_x) (Node B) to destination 6LN (Node H).  In this case, 1 <= id

   <= m, where m is the number of routers (6LR) that the packet traverses

   from the common parent (6LR_x) to destination 6LN.

CEP: The next sentence is implicit in many use cases and belongs elsewhere.

  It is assumed that the two nodes are in the same RPL Domain (that

   they share the same DODAG root).  At the common parent (Node B), the

   direction of RPI is changed (from increasing to decreasing the rank).

<author> we think that includes clarification for the use case of the
common parent </author>

7.  Non Storing mode

<CEP: The first sentence is not true in the case where nodes have neighbors

      at the same depth.  The root does not necessarily know about that.
CEP>

   In Non Storing Mode (Non-SM) (source routed), the 6LBR (DODAG

   root) has complete knowledge about the connectivity of all DODAG

   nodes, and all traffic traverses the root node.  Thus, there is

   no need for all nodes to know about the existence of RPL-unaware

<author>

RFC 6550 states: “  3.  In Non-Storing mode, the DODAG root SHOULD store
source routing

       table entries for destinations learned from DAOs.  The DODAG root

       MUST be able to generate source routes for those destinations

       learned from DAOs that were stored.”

Based on that we believe that the Root has complete knowledge about
connectivity to the nodes.

</author>

Thank you very very much again,

Ines, Michael and Pascal.

On Thu, May 30, 2019 at 12:21 AM Charlie Perkins <
[email-masked]> wrote:

>
> Hello folks,
>
> Due to a lot of confusion on my end, this IoT-Dir review is very very
> late.  I hope it will be found to be useful.
>
> I think the draft needs a bit of work before it can be published.  I have
> quite a few editorial comments and a couple of important technical concerns.
>
> I started to review revision ...25.txt, but before I could finish that
> review, we were already up to revision ...29.txt so I started over with
> that revision.  Most of these are represented, albeit incompletely, in the
> attached file.
>
> My main technical concern has to do with the attempt to classify RPI
> Option Types 0x23 and 0x63 as somehow being variants of the same Option
> Type.  I don't think this is really legitimate; they have to be considered
> to be two different Options.  I believe the idea is that it should be
> simple to implement both together, and type 0x23 is likely to survive
> traversal of the Internet.  An intermediate device that implements 0x63 but
> not 0x23 will not process any of the configuration options present in 0x23,
> but at least the packet won't be dropped.  I'm not sure how serious this
> problem is for intermediate 6LRs in the path of a 0x23 packet traversing
> the LLN, but those configuration options are meant for consumption by such
> intermediate 6LRs.
>
> One thing that would help, is to include in the overview a very succinct
> list of design requirements and also a list of assumptions made during the
> design.  I had wanted to create this list but that would take another day.
> Here is a start, and I hope that any misunderstanding that I have will be
> minor:
>
> Requirements:
>
> 1. RPI has to be in every packet that traverses the LLN
> 2. Because of (1), packets from the Internet have to be encapsulated
> 3. Extension headers may not be added or removed except by the sender or
> the receiver
> 4. Packets that will traverse RPI-unaware nodes need encapsulation, but
> only sender or receiver can add the new RPI option (0x23)
> 5. Non-storing mode requires downstream encapsulation by root for RH
>
> Assumptions:
>
> - Each IPv6 node (including Internet routers) obeys RFC 8200, so that 0x23
> RPI can be safely inserted.
> - All 6LRs obey RFC 8200
>
> These requirements and assumptions determine the entries in the dozens of
> tables included within the document.  Without a clear grasp of them, it is
> easy to get lost in the sea of details about header insertion and
> encapsulation.
>
> Most of my many comments are editorial.  I think that the draft could be
> easier to read with fewer digressions, and more consistent use of
> acronyms.  I have made a great many example revisions directly into the
> attached text file, which I hope will receive consideration by the
> authors.  Each editorial comment individually is typically less important
> than a technical error, but taken together I think they would greatly
> promote readability and thus increase the likelihood that implementers will
> be able to understand the intention of the specification.   I have also
> inserted additional comments into the file, tagged by my initials "CEP:".
> Here are some overall comments.
>
>
>    -  not-RPL-aware --> RPL-unaware
>    -  Raf could be confused as "RPL-aware forwarder".   Please change
>    acronyms.  One possibility: ~Raf --> RuL,   Raf --> RaL  (for.,
>    "RPL-aware-Leaf", "RPL-unaware-Leaf", respectively)
>    -  Since the document already uses acronyms in an essential way,
>    please also use them to improve clarity and shorten subsection titles, etc.
>    -  Captions to figures and subsection titles should typically fit on a
>    single line
>
> I would like to verify the design assumptions and design requirements, and
> then use that knowledge to check the details of each of the 24 use cases.
> One improvement that would be *very* helpful for this purpose, would be to
> assert *which* of the design requirements underlies each matrix entry for
> the 24 summary tables.
>
> Regards,
> Charlie P.
>
>
>
>
>

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 25 Jun 2019 12:23:10 -0700

Hello Ines and all,

Thanks for your detailed follow-up.  Right now I don't have much time, 
but there is one point:

On 6/25/2019 8:29 AM, Ines Robles wrote:
> We believe that is the same Option Type, with the value updated from 
> 0x63 to 0x23.
>
> The network would switch to 0x23 when all the nodes are capable to 
> process it.
>
> </author>
>

RFC 8200 has the following text:

================================================================

4.2.  Options

    Two of the currently defined extension headers specified in this
    document -- the Hop-by-Hop Options header and the Destination Options
    header -- carry a variable number of "options" that are type-length-
    value (TLV) encoded in the following format:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
       |  Option Type  |  Opt Data Len |  Option Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

       Option Type         8-bit identifier of the type of option.

.....

===============================================================

So I don't see how you can avoid having the Option Type be 8 bits long.

And then I don't see how two options with different 8-bit types could 
possibly be called the same option.

Could you explain in more detail why you believe they are the same 
option type?

Please note -- I do not quibble that they are *similar*.  Just not *the 
same*.

Regards,
Charlie P.

---

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 22:52:20 +0300

Hi Charlie,

Thank you very much for your reply. Apologizes if my english is not clear
enough.

We have the RPL Option identified with option type 0x63. Yes, we define a
new value 0x23 to update the 0x63. Yes, it is a new binary combination that
we aim to asign to the RPL Option, in that  way we update RFC6553.
The change of RPI option type from 0x63 to 0x23, makes all [RFC8200]
compliant nodes tolerant of the RPL artifacts.

Hope it helps to clarify your doubts.

Thanks a lot,

Ines.

On Tue, Jun 25, 2019 at 10:23 PM Charlie Perkins <
[email-masked]> wrote:

> Hello Ines and all,
>
> Thanks for your detailed follow-up.  Right now I don't have much time, but
> there is one point:
> Could you explain in more detail why you believe they are the same option
> type?
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 12:14:36 -0400

> possibly be called the same option.

If you like, we could rename the old one to RPI-drop-if-unknown, and
the new one to be RPI-ignore-if-unknown.  (Or maybe in 8200-speak,
"unconfigured to examine")

I don't care about the name, but maybe 6man or the IESG has a stronger
opinion.  I'm not sure if your comment has a proceedural or on-the-wire
impact, or if it is just an editorial change you asking for.

The point is that we want to update RFC6553 to change the behaviour
if unknown so that we don't have to waste many bytes and CPU cycles inserting
and removing useless IPIP headers at every LLN hop.

    > Could you explain in more detail why you believe they are the same option

Because the other 5-bits are the same, and the allocation strategy that IANA
has been told about is not to reuse/overlap the lower-5-bits until necessary.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-