Re: [Roll] Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22)

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

Hello Pascal,

It works for me. “If the SIO is effectively received from both sides then the B flag MUST be ignored.”


Best regards,
Li

From: Pascal Thubert (pthubert) <[e-mail]>
Date: Saturday, February 26, 2022 at 00:20
To: Li Zhao (liz3) <[e-mail]>, ROLL WG ([e-mail]) <[e-mail]>
Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22)
Hello Li:

This is an error case  that does not impact interoperation, but I agree it is worth mentioning. I like option 2 since the source knows better.
IMHO If you receive information from both sides you should ignore the B flag.

Proposal to add:
“
                                                       If the SIO is effectively
    received from both sides then the B flag is ignored.
“

Works for you?

Pascal
From: Li Zhao (liz3) <[e-mail]>
Sent: vendredi 25 février 2022 2:10
To: Pascal Thubert (pthubert) <[e-mail]>; ROLL WG ([e-mail]) <[e-mail]>
Subject: Re: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22)

Hello Pascal,

What about the asynchronism cases?

For instance, node A and B are siblings, but node A reports SIO with flag B, node B reports SIO without flag B later.
I think we have three options for this case:

  1.  Root trusts the latest info.
  2.  Root trusts the info from source node.
  3.  Leave it to implementation

I prefer option 3 to simplify the flag definition. What do you think?


Best regards,
Li


From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 24, 2022 at 21:00
To: ROLL WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>>
Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22)
Dear all

This is now issue 11 in github https://github.com/roll-wg/dao-projection/issues/11

The spec alone does not provide a way to assert whether the link is bidir or not.
Some techs may leverage existing L2 information or sync/compare their DLEP state but that needs to be defined for a specific case/technology.

So I suggest we add text like:
“
    The SIO carries a flag (B) that is set when similar performances can be
    expected both directions, so the routing can consider that the information
    provided for one direction is valid for both? The policy that describes the
    performance criteria, and how they are asserted is out of scope.
    In the absence of an external protocol to assert the link quality, the flag
    SHOULD NOT be set.
“

What do you think?

Pascal

From: Pascal Thubert (pthubert)
Sent: vendredi 14 janvier 2022 11:20
To: ROLL WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>>
Subject: (Was: review of dao-projection -22)

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 <[e-mail]<mailto:[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]<mailto:[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