Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

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

Hello Pascal,

Ingress as Root looks better because
1.  It is consistent with the way RPL usually works. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.
2.  For non-storing-mode P-DAO, currently ingress sends upward traffic to egress(root) with SR header. But in RPL, only downward traffic carries SR header.
3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local Instance ID. Ingress as root can propose TrackId from its namespace.


And for storing-mode P-DAO, if we make ingress as root and ingress sends PDR, can PCE send P-DAO to egress then egress forwards it towards predecessor to ingress?
Maybe it helps to make P-DAO looks like a DAO message.


Best regards,
Li


From: Roll <[e-mail]>
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Dear all

Whether to make the P-DAO bidirectional is an intriguing question. It could be done, just like we can send packets DOWN a classical DODAG.
But if we take that path, we reopen the question of who is root and which direction the P-DAO flies.

Could we make either the ingress OR the egress root? How does it matter?

At the moment the Root is the egress and the storing-mode P-DAO flies from the Track egress to the track ingress, and the track egress is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. If we wanted to build multicast Tracks the root should logically be the ingress. And for bidirectional Tracks it could be either.

Up to -24 the 6TiSCH Architecture expected the ingress to be root. I changed in the latest to map we do here, that it is the egress; maybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?

Also if we build bidir Tracks in storing mode, the nodes that forward the DAO will have to build routes in both directions based on the P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up one way?

Please let me know your thoughts

Pascal


From: Roll <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: [Roll] IETF 109 open Questions on P-DAO

Dear all

The slides for the P-DAO discussion at IETF 109 are available here:

https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/

There are a number of open questions that we starting discussing, and would need to progress on the list.
Some of them were expressed on the list, e.g., from Huimin She. I’d like to progress on them all with individual threads.
The questions are:


  1.  Lifetime Unit: could we use a different unit for P-DAO?
  2.  How to differentiate a P-DAO from a normal DAO in a local instance; new flag?
  3.  Make P-DAO bidirectional?
  4.  Who sends the PDR? Does it have to be the ingress? If it was egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5.  Maintaining the sibling state. Should we have text on using RFC 8505 there?
  6.  Whether ingress and egress are listed in NPO? Today they are both, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6LoRH. Note that the ingress must consume the first entry and use it as source.
  7.  Track in Track vs. SR Header reload models, see slides

Let me open threads to follow up.

Keep safe

Pascal