Subject: [Roll] (Was: review of dao-projection -22)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Jan 2022 10:20:14 +0000

Dear all: we had this thread as part of Li's review:

About "5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry."

[Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A.

[PT] we used to have that (B Flag for bidir) but we removed it for simplification. I'm OK to add it back, but we still lake a good description of how the node will know that the link is roughly symmetrical.

[Li] Some physical layer measurements such as RSSI/LQI have forward and reverse direction. Can it indicate symmetrical?
                  In layer 3, receiving DIO/NS messages from each other indicate symmetrical

[PT] There's a nuance between bidir and symmetrical.  Maybe the ping works but the link quality is very different in both directions. If so the Rank increment computation would differ widely and we would need both sides.

At the moment the text says:
"
   B:  1-bit flag that is set to indicate that the connectivity to the
      sibling is bidirectional and roughly symmetrical.  In that case,
      only one of the siblings may report the SIO for the hop.  If 'B'
      is not set then the SIO only indicates connectivity from the
      sibling to this node, and does not provide information on the hop
      from this node to the sibling.
"

We need to clarify what the B flag means, when it can be set, and what is expected from the Root/ PCE about path computation when it is set or not set.

Suggestions welcome;

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] review of dao-projection -22

Hello Authors,

Thanks for your great effort. The PDAO draft looks more clear and detailed. Following is some concern:

3.5.2 Using Non-Storing Mode joining Tracks
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-C,F,G

   [Li] ->  Should it be ?
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-E,F,G

    Otherwise RIBs in A cannot include destination to E.

4.1. Extending RFC 6550
To ensure that the PDR and P-DAO messages can flow at most times, it is RECOMMENDED that the nodes involved in a Track ===mantain=== multiple parents in the Main DODAG, advertise them all to the Root, and use them in turn to retry similar packets. It is also RECOMMENDED that the Root uses diverse source route paths to retry similar messages ===ot=== the nodes in the Track.¶

[Li] -> Typo for "mantain" and "ot"?

4.1.6.
This specification defines a new flag "Projected Routes Support" (D).
The DODAG Configuration option is copied unmodified from parents to children. ====xref target='RFC6550'/>====  states that:

[Li] -> Typo for "xref target='RFC6550'/>".  Why is flag named as "D"? There is no D in "Projected Routes Support"...

5.1 The Root may use an asynchronous PDR-ACK with an negative status to indicate that the Track was terminated before its time.

[Li] -> What's the difference between negative status PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchronous PDR-ACK?
In storing mode, root should use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still needed?
In non-storing mode, No-Path P-DAO to ingress node is also enough.
But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Path P-DAO?

5.1 One and only one RPL Target Option MUST be present in the message.

[Li] -> Is it possible to remove the limitation?  It's not flexible If PDR can only carry one RTO.
For instance in figure 7, if node I requests P-Route to B&H together, Root can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.
If Root cannot computer one Track to multiple RTO, it can response with a special PDR-ACK Status.

5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry.

[Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A.

6.2  There is no notification to the requesting node when those changes happen.

[Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send notification to the requesting node when those changes happen.

6.3 In a particular deployment where PDR are not used, the namespace can be delegated to the main Root, which can assign the TrackIDs for the Tracks it creates without collision.

[Li] -> Can you add some description for the collision case? E.g., node trusts itself than Root.

6.4.1 In both cases the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful

[Li] ->  Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g. any flags?  Normally, root won't receive any DAO-ACK from nodes.
Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.

8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs; this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments.

[Li] -> Profile 0 is the Legacy support of [RPL<https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-22.html#RFC6550>] Non-Storing Mode. I'm confuse about "this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments."

Best regards,
Li

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Jan 2022 09:28:39 +0200

On Fri, Jan 14, 2022 at 12:21 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Dear all: we had this thread as part of Li’s review:
>
>
>
>
>
> About “5.4 only the router with the lowest Interface ID in its registered
> address needs report the SIO, and the Root will assume symmetry.”
>
>
>
> [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise,
> if A chooses B as sibling, but B doesn't choose A as sibling, Root may
> treat SIO from A as symmetry incorrectly when only receiving SIO from A.
>
>
>
> [PT] we used to have that (B Flag for bidir) but we removed it for
> simplification. I’m OK to add it back, but we still lake a good description
> of how the node will know that the link is roughly symmetrical.
>
>
>
> [Li] Some physical layer measurements such as RSSI/LQI have forward and
> reverse direction. Can it indicate symmetrical?
>
> [PT] There’s a nuance between bidir and symmetrical.  Maybe the ping works
> but the link quality is very different in both directions. If so the Rank
> increment computation would differ widely and we would need both sides.
>
>
>
> “
> “
> We need to clarify what the B flag means, when it can be set, and what is
> expected from the Root/ PCE about path computation when it is set or not
> set.
>

I think the flag needs more than two possibilities for connectivity issues,
could we have two bits?

AB

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Jan 2022 07:49:40 +0000

Hello Abdussalam

Possibly. We need a list of conditions we would advertise and of the different behaviours that would be expected when signaled…
Do you have a starting point?

Keep safe;

Pascal

From: Roll <[email-masked]> On Behalf Of Abdussalam Baryun
Sent: mercredi 19 janvier 2022 8:29
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] (Was: review of dao-projection -22)

On Fri, Jan 14, 2022 at 12:21 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Dear all: we had this thread as part of Li’s review:

About “5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry.”

[PT] we used to have that (B Flag for bidir) but we removed it for simplification. I’m OK to add it back, but we still lake a good description of how the node will know that the link is roughly symmetrical.

[PT] There’s a nuance between bidir and symmetrical.  Maybe the ping works but the link quality is very different in both directions. If so the Rank increment computation would differ widely and we would need both sides.

I think the flag needs more than two possibilities for connectivity issues, could we have two bits?

AB