Re: [Roll] Querying PDAO

Hello Randy:

I went through that thread again. Sorry it went stale.

The discussion on multiple destinations percolated and is accommodating by generating a track that contains the nodes you want to reach. The D in DODAG is the root and the source of the packets. We’re missing explanatory text on that.

When we signal the path request there can be a constraint as a list of targets just like there can a constraint in bandwidth or latency.

I like the idea of a DIS for this and can propose text. Is there a disagreement on the list that we move forward with this?

Pascal

Le 26 juil. 2019 à 05:37, Turner, Randy <Randy.Turner@landisgyr.com<mailto:Randy.Turner@landisgyr.com>> a écrit :

Hi All,

Apologies for missing the ROLL meeting this week…this “requesting PDAO” item sounds like a proposal I made back in May on the ROLL list (https://mailarchive.ietf.org/arch/msg/roll/jRrtG5gualJno2BIXcpQ5euvsMo) – at the time, most of the use cases I had in mind were mesh-endpoint-driven, not necessarily pushed out by the PCE, although I do see value in the original draft as well.  I was originally thinking this would be a (somewhat) inexpensive way for non-storing nodes to have at least a couple of routes stored that they cared about.

Randy

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, July 25, 2019 12:58 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] Querying PDAO

I see, Li. Let’s see if others object or wish to add stuff?

All the best,

Pascal

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Li Zhao (liz3)
Sent: jeudi 25 juillet 2019 09:03
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] Querying PDAO

Yes. Use target as a prefix is to reserve the capability of creating a path to a subnet. Maybe we can use another way to keep the capability.

Suboption for route parameter is a good idea. We can define some TLV to identify these parameters.

Best regards,
Li

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Date: Thursday, July 25, 2019 at 7:53 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] Querying PDAO

Looks good Li.

I’m confused that you see the target as a prefix; would you like to create a path to the nearest router that serves a subnet?
I guess that the route parameters should be a place for suboptions.
Suboptions I can fathom would be a max sum of steps of Rank, a max latency, and a reliability level. Should be extensible though.
Which means that the sibling and transit information in the DAO should provide enough metrics to build this.

Assessing the list here, do we have a consensus to add a PDAO query DIS to the PDAO draft?

All the best,

Pascal

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Li Zhao (liz3)
Sent: mercredi 24 juillet 2019 16:42
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] Querying PDAO

Dear all,

Following up on querying PDAO from root at the meeting today:

It makes sense to provide a querying mechanism for node which can get PDAO from root. Then node can query special PDAO route entry according to its special requirement. For example, route hop, latency, route algorithm, remaining lifetime.

We can enhance DIS to query PDAO if adding a flag in DIO Base Object to identify it is a PDAO query DIS.
And this DIS need to carry a new Control Message Options because existing Control Message can’t identify the requirement.
A possible Control message is as following:

        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |   Type = TBD | Option Length | Prefix Length | alg    | Resvd |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                                                               |

       .                   Target Prefix (Variable Length)             .

       .                                                               .

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                        route parameter                        |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

alg: route algorithm such as latency/hop limited/common ancestor.
hops/latency/remaining lifetime are some route parameter.

Is it possible to add some text about it?

Best regards,
Li

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll