Subject: [Roll] dao-projection review

From: Rahul Jadhav <[email-masked]>
Date: Sat, 20 Nov 2021 00:33:25 +0530

The document has come a long way and limiting it to certain modes (such as
using strictly NSM for base/main MOP) has done a lot to simplify things.

Following is my review:

1. In all the subsections of 3.5.1 ... there is a statement that "From
Neighbor Cache Entry: C delivers the packet to F.". I believe it should be
"E delivers the packet to F". This stmt is in subsection 3.5.1.1/2/3

I very much like section 3.5.1 and its subsections. These subsections have
made understanding the draft much easier.

2. Apart from Path, Track, subTrack, Segment, there are few other terms
used ... "Legs" used in Section 3.6 (also elsewhere) and "Section" used in
Section 6.5.
In section 3.6, the term Legs seems to be indicating the same as Path,
i.e., multiple paths/legs can be combined to form a Track. In some other
places (section 4.1.2), the usage of leg is more closer to Track then paths.
In section 6.5 there is a statement, "This is ensured by installing
the new section
from its last node..." .. Is the section the same as the segment here?

3. The term "namespace" is used multiple times in the document. I
believe it relates to the scope of the TrackID .. It would be better to
define it explicitly. RPL does not use that term.

4. Section 4.1.1 specifies, "This specification generalizes the case of a
parent that can be used to reach a child with that of a whole Track through
which children and siblings of the Track Egress are reachable."
I am not sure if I follow this.

5. In general the document does not seem to be considering backward
compatibility with respect to new changes in RPI P flag, new messages added
etc. Or am I wrong? Is section 8 "Profiles" supposed to take care of
compatibility?

6. In Section 5.4: What exactly is the Step of Rank? Is it:

   1. Difference between the rank of this node and the sibling?
      2. DAGRank() as computed in Section 3.5.1 in RFC 6550? This needs to
      be explained with an example.

Thank you for clarifying the term Anisotropic. Works great in the RPL
context.

Thanks,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Nov 2021 18:03:32 +0000

Hello Rahul

Many thanks for this! Let’s see below:

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: vendredi 19 novembre 2021 20:03
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] dao-projection review

The document has come a long way and limiting it to certain modes (such as using strictly NSM for base/main MOP) has done a lot to simplify things.

Following is my review:

  1.  In all the subsections of 3.5.1 ... there is a statement that "From Neighbor Cache Entry: C delivers the packet to F.". I believe it should be  "E delivers the packet to F". This stmt is in subsection 3.5.1.1/2/3<http://3.5.1.1/2/3>

PT > True, fixed both

I very much like section 3.5.1 and its subsections. These subsections have made understanding the draft much easier.

PT> : )

2. Apart from Path, Track, subTrack, Segment, there are few other terms used ... "Legs" used in Section 3.6 (also elsewhere) and "Section" used in Section 6.5.
In section 3.6, the term Legs seems to be indicating the same as Path, i.e., multiple paths/legs can be combined to form a Track. In some other places (section 4.1.2), the usage of leg is more closer to Track then paths.
In section 6.5 there is a statement, "This is ensured by installing the new section from its last node..." .. Is the section the same as the segment here?

PT> let me define ‘section’ in terminology
“
2.4.13.  Section of a Segment

   A continuous subset of a segment that may be replaced while the
   segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that
   the link C to D might be misbehaving.  The section B=>C=>D=>E in the
   segment may be replaced by B=>C'=>D'=>E to route around the problem.
   The segment becomes A=>B=>C'=>D'=>E=>F.
“

  1.  The term "namespace" is used multiple times in the document. I believe it relates to the scope of the TrackID .. It would be better to define it explicitly. RPL does not use that term.
PT> true. What about
“

2.4.1.  namespace

   The term namespace is used to refer to the scope of the TrackID.  The
   TrackID is locally significant within its namespace.  The namespace
   is identified by an IPv6 Global Unicast Address (GUA) that is used as
   DODAGID for the Track.  The tuple (DODAGID, TrackID) is globally
   unique.
“

4. Section 4.1.1 specifies, "This specification generalizes the case of a parent that can be used to reach a child with that of a whole Track through which children and siblings of the Track Egress are reachable."
I am not sure if I follow this.

PT> reworded the section. I hope it’s more palatable now:
“
   In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO message to
   inform the DODAG Root of all the edges in the DODAG, which are formed by the
   directed parent-child relationships. The DAO message signals to the Root
   that a given parent can be used to reach a given child. The P-DAO message
   generalizes the DAO to signal to the Track Ingress that a Track for which it
   is Root can be used to reach children and siblings of the Track Egress.
   In both cases, options may be factorized and multiple RTOs may be present to
   signal a collection of children that can be reached through the parent or
   the Track, respectively.
“

5. In general the document does not seem to be considering backward compatibility with respect to new changes in RPI P flag, new messages added etc. Or am I wrong? Is section 8 "Profiles" supposed to take care of compatibility?

PT> True. I asked in my reply to Michael’s review whether we should be using the last free but in the RPL dodag config option to signal that this spec is being used globally, and both anycast and multicast can be injected. What do you think?

     *   Difference between the rank of this node and the sibling?
     *   DAGRank() as computed in Section 3.5.1 in RFC 6550? This needs to be explained with an example.
If Rank is a cost then that would be the cost for the hop to the sibling. What about:
“
   Step in Rank:  16-bit unsigned integer.  This is the Step in Rank
      [RPL] as computed by the Objective Function between this node and
      the sibling, that reflects the abstract Rank increment that would
      be computed by the OF if the sibling was the preferred parent.

“

Thank you for clarifying the term Anisotropic. Works great in the RPL context.

Pt> 😊

Many thanks for your excellent review! I committed as https://github.com/roll-wg/dao-projection/commit/d2da2375194f30961882c991b539cbc2ae69ec04. Please let me know your thoughts on using the last DODAG config flag.

Keep safe

Pascal

Thanks,
Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 24 Nov 2021 18:01:50 +0530

Many Thanks Pascal

Please find my comments inline.

Regards,
Rahul

>    "E delivers the packet to F". This stmt is in subsection 3.5.1.1/2/3

[RJ] Thanks. Subsection 3.5.1.3 has the same statement and could use this
fix as well. In all, there were three subsections with the same statement.

> In section 6.5 there is a statement, "This is ensured by installing the
> new section from its last node..." .. Is the section the same as the
> segment here?
>
>
>

[RJ] This is clear to me now.

>
>
>    1. The term "namespace" is used multiple times in the document. I

[RJ] Much clearer. However, is it necessary to say "GUA" for DODAGID? Can't
the DODAGID be a ULA (Unique Local Address, fc00::/64) wherein the PCE,
Root and all the 6LRs are part of the same ULA network prefix? Does the
DODAGID have to be "globally routable"?

>    signal a collection of children that can be reached through the parent
[RJ] Now I get it. Thanks

> PT> True. I asked in my reply to Michael’s review whether we should be
> using the last free but in the RPL dodag config option to signal that this
> spec is being used globally, and both anycast and multicast can be
> injected. What do you think?
>

[RJ] I would rather have it explicitly specified as "Backward Compatibility
Considerations" section, since I am sure we will get this comment during
next higher-level reviews.

>       2. DAGRank() as computed in Section 3.5.1 in RFC 6550? This needs
>       to be explained with an example.
>

[RJ] "... computed by the OF if the sibling was the preferred parent."
clarifies things for me.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Nov 2021 17:18:16 +0000

Very fine Rahul.

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mercredi 24 novembre 2021 13:32
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] dao-projection review

Many Thanks Pascal

Regards,
Rahul

On Tue, 23 Nov 2021 at 23:34, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:

PT > True, fixed both

[RJ] Thanks. Subsection 3.5.1.3 has the same statement and could use this fix as well. In all, there were three subsections with the same statement.

PT> Argl, fixed. I also note that the description of Segment routing applies equally well in a Non-Storing LLN where the SRH is that of RFC 6554 possibly compressed as a SRH-6LoRH, or in an ANIMA Storing Mode Network where SRH can be per RFC 8754. To prevent the trouble at the IESG review, I added terminology to clarify.

“

2.4.13.3.  Segment Routing and SRH

   The terms Segment Routing and SRH refer to using source-routing to
   hop over segments.  In a Non-Storing mode RPL domain, the SRH is
   typically a RPL Source Route Header (the IPv6 RH of type 3) as
   defined in [RFC6554].

   If the network is a 6LoWPAN Network, the expectation is that the SRH
   is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
   specified in section 5 of [RFC8138].

   On the other hand, if the RPL Network is less constrained and
   operated in Storing Mode, as discussed in Section 7.1, the Segment
   Routing operation and the SRH could be as specified in [RFC8754].
   This specification applies equally to both forms of source routing
   and SRH. “

2.4.1.  namespace

[RJ] Much clearer. However, is it necessary to say "GUA" for DODAGID? Can't the DODAGID be a ULA (Unique Local Address, fc00::/64) wherein the PCE, Root and all the 6LRs are part of the same ULA network prefix? Does the DODAGID have to be "globally routable"?

 Actually this is already said in section 3.4.2. so I simplified here to:
“
    The term namespace is used to refer to the scope of the TrackID. The TrackID
    is locally significant within its namespace. The namespace is identified by
     the DODAGID for the Track. The tuple (DODAGID, TrackID) is globally unique.
“

[RJ] I would rather have it explicitly specified as "Backward Compatibility Considerations" section, since I am sure we will get this comment during next higher-level reviews

PT> This seems consistent with Michael’s review so I added the IANA section to claim the last bit in the RPL DODAG configuration option. I used similar text as in RFC 9010 to do so.We need to do mopext soon!

To your point here, I added a new section as follows:

9.  Backwards Compatibility

   This specification can operate in a mixed network where some nodes
   support it and some do not.  There are restructions, though.  All
   nodes that need to process a P-DAO must support this specification.
   As discussed in Section 3.7.1, how the root knows whether the nodes
   capabilities and whether it support this specification is out of
   scope.

   This specification defines the 'D' flag (see Section 4.1.6, in the
   RPL DODAG Configuration Option to signal that upgraded nodes can
   request the creation of Tracks.  The requester may not know whether
   the Track can effectively be constructed, and whether enough nodes
   along the preferred paths support this specification.  Therefore it
   makes sense to only set the 'D' flags in DIO when the conditions of
   success are in place, in particular when all the nodes that could be
   on path of tracks are upgraded.

Works?

Many thanks!

Pascal