Subject: Re: [Roll] IETF 109 open Questions on P-DAO

From: "Huimin She (hushe)" <[email-masked]>
Date: Wed, 25 Nov 2020 02:14:52 +0000

Thank you, Pascal.

I have a few more questions as following.

1. How does the egress know that a local RPL instance is associated with it? For example, in non-storing mode, the P-DAO message is sent to the ingress.

2. A local RPL instance is rooted at the egress. In fact, it is not a normal RPL since there is no RPL maintaining messages such as: DIO, NS, DAO etc.

Best regards,
Huimin 

    Date: Tue, 24 Nov 2020 13:22:04 +0000
    From: "Pascal Thubert (pthubert)" <[email-masked]>
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: [Roll] IETF 109 open Questions on P-DAO
    Message-ID:
    	<[email-masked]>

    Content-Type: text/plain; charset="us-ascii"

    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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Nov 2020 09:27:55 +0000

Hello Huimin

> 1. How does the egress know that a local RPL instance is associated with it? For
> example, in non-storing mode, the P-DAO message is sent to the ingress.
 
This is related to the discussion of item 4, and Li's answer to the spun off " Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO" thread.

If the route is established with a PDR from the ingress and the ingress is root then the ingress can suggest a TrackID from its pool. 

But without a PDR, how can the root find an available TrackID? 
- Should we have a message from the Root to get one, like a "PDR request" from the root to stimulate a PDR? Or do we expect that there's always a PDR and that the "PDR request" is an external mechanism? 
- Or that the stimulus is an external thing?

> 2. A local RPL instance is rooted at the egress. In fact, it is not a normal RPL since
> there is no RPL maintaining messages such as: DIO, NS, DAO etc.
 
True that there is no DIO since the Root forms the DODAG in memory so DIO is not needed. 
The P-DAO is a DAO, though. If we make the ingress the Root then the storing mode P-DAO does pretty much what a normal DAO does, though it flies over a constrained path as opposed to the one found by DIO.

Take care,

Pascal

>     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:
> 
> 
>       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?
>       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.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll