Re: [Roll] review of dao-projection -22

["Li Zhao (liz3)" <[e-mail]>]

Hello Pascal,

Please find my comments inline.

Best regards,
Li

From: Roll <[e-mail]> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]>
Date: Friday, January 14, 2022 at 01:31
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] review of dao-projection -22
Hello Li

A great many thanks for your excellent review! Such are much needed at this time.

> [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
[PT] correct, great catch!


> [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?

[PT]  The no path DAO flow along the reverse path and cleans it; so the end result would be that the Track is terminated as you figured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a completion (IOW not an ack). How could we justify a status in all DAOs? I’m unclear why the async PDR ack is an issue. If the PDR can not be served, the track ingress already needs to support a PDR ack that ”terminates” a Track.

To clarify that sentence we can say:
“
   The main Root MAY indicate to the Track Ingress that the Track was terminated
   before its time and to do so, it MUST uses an asynchronous PDR-ACK with an
   negative status.
“
Should that be more than a MAY?

>>>> [Li] Yes. It’s more clear. So PDR-ACK is for original PDR. And for maintain or tear down case, Root should use No-Path P-DAO to terminate P-Route. Correct?


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

[PT]  This was done in the interest to simplicity, and yes we can rediscuss that.
We’d need to make decisions on partially successful use cases e.g.,:

  *   What if there’s a path to only a subset? Should the root form more than one track?
  *   Or deny with your special status but then what can the source do after that? Try all combinations?
  *   What is the best path to one target cannot reach all targets but a lower quality path can? Should we use that one?
  *   Maybe there could be one main target and additional desirable targets? In that case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to the main target.

>>>> [Li] Maybe it depends on implement of PCE?  I’d like to keep the flexibility because there is a user case for street lighting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.




> [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?


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

[PT] There’s no protocol element to “send notification to the requesting node when those changes happen”. So it’s hard to say that the root MUST NOT do something that it cannot do. Reworded to

“
      Note that there is no protocol element to notify to the requesting Track
      Ingress when changes happen deeper down the Track, so they are transparent
      to the Track Ingress. If the main Root cannot maintain an expected service
      level, then it needs to tear down the Track completely.
“



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


[PT] I reworded to
“
                                                                                              In a particular deployment
     where PDR are not used, a portion of the namespace can be administratively
     delegated to the main Root, meaning that the main Root is authoritative for
     assigning the TrackIDs for the Tracks it creates..
“

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

[PT] Done; I added a section for the P-DAO-ACK

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

[PT] I really meant Profile 1 enables… Changing that.

I guess that’s it !

I submitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-23

Again many thanks!

Pascal

From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <[e-mail]>
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