Subject: [Roll] DAO Projection

From: Rahul Jadhav <[email-masked]>
Date: Tue, 7 Mar 2017 22:13:22 -0800

Hello authors,

Installing routes by DAO projection in NS-MOP will help in establishing
optimized P2P paths, as well as it will help in containing the 6lo
fragmentation resulting out of bulged SRH at 6LBR.
Thanks for the work.

There are few observations/Qs:
1. The draft discusses about projecting DAO for route installations. But i
assume the same projection mechanism can be used for route removal (?).
This might be needed considering that NPDAO is not required in NS-MOP and
that the VIA lifetimes could be high.
2. Did you also considered installing an SRH (for downstream dest) at
intermediate 6LR rather that installing routes along a segment (segment as
per defn in the draft)?
3. There is a redundant paragraph and missing lines at the end of section 5
which tries explaining the example. Please fix the draft and will be nice
to check that example.

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Mar 2017 08:18:32 +0000

Hello Rahul :

Thanks for your comments, all spot on : )

Please see below

Installing routes by DAO projection in NS-MOP will help in establishing optimized P2P paths, as well as it will help in containing the 6lo fragmentation resulting out of bulged SRH at 6LBR.
Thanks for the work.

1. The draft discusses about projecting DAO for route installations. But i assume the same projection mechanism can be used for route removal (?). This might be needed considering that NPDAO is not required in NS-MOP and that the VIA lifetimes could be high.

[Pascal] Right. A sentence indicating that a lifetime of zero will trigger a NP DAO and do the cleanup should suffice. Do you agree?

2. Did you also considered installing an SRH (for downstream dest) at intermediate 6LR rather that installing routes along a segment (segment as per defn in the draft)?

[Pascal] This is yet a new mechanism. I’m all for it. The 6LoRH make the task of encaps/insertion a lot easier now. All: if you disagree to the addition please let us know now.

3. There is a redundant paragraph and missing lines at the end of section 5 which tries explaining the example. Please fix the draft and will be nice to check that example.

[Pascal] oups! Will fix before cutoff.

Take care,
Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Mar 2017 14:14:38 +0000

Hello Again Rahul :

For item 1, there was already text indicating that the lifetime in the Via Information option is similar to that in the Transit Information option (e.g. in section 3.1).
Proposal: in the text below, the first sentence was already present and the suggestion is to add the following one.

     A lifetime of 0 in the Via Information option along the segment is used to
     clean up the state. The DAO is forwarded as described above, but the DAO
     is interpreted as a No-Path DAO and results in cleaning up existing state
     as opposed to refreshing an existing one or installing a new one.

For item 2 I suggest the following operation:
    The Via Information option MUST contain at least one Via Address.
    The first address in a Via Information option denotes an intermediate router
    in which a routing state is to be installed to reach the target indicated in the RPL
    Target Option.
    If there is only one address, then the routing state to be installed in the
    intermediate node that owns the Via Address is a storing mode route to the
    target in the RPL Target Option via the source of the DAO. When forwarding a
    packet to the target, there is no need to add a source route header or an
    encapsulation

    If more than one address is present in the Via Information option, then the
    additional Via Addresses denote a source routed path to the source of the
    DAO that must be used to reach the target in the RPL Target Option. In
    that case, the routing state to be installed in the intermediate node that
    owns the first Via Address is a non-storing mode route to the target via the
    other Via Addresses in the Via Information option and then the source of the
    DAO. When forwarding a packet to the target, the intermediate node MUST
    encapsulate the packet using Via Address 1 as source and Via Address 2
    as destination, and add a source routed header that contains any additional
    Via Addresses in the order of the Via Information option, and the source of
    the DAO message.

     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 = 0x0A | Option Length | Path Sequence | Path Lifetime |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                     Via Address 1                             .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                              ....                             .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                     Via Address n                             .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We’ll probably need to restructure the doc a bit, but I’d wish to agree on the operation first.

Does the above work for you?

Take care,

Pascal

From: Pascal Thubert (pthubert)
Sent: mercredi 8 mars 2017 09:19
To: Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: RE: [Roll] DAO Projection

Hello Rahul :

Please see below

Take care,
Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 8 Mar 2017 21:00:45 -0800

Hello Pascal,

Please find my resp inline...

Regards,
Rahul

On 8 March 2017 at 06:14, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Again Rahul :
>
>
>
> For item 1, there was already text indicating that the lifetime in the Via
> Information option is similar to that in the Transit Information option
> (e.g. in section 3.1).
>
> Proposal: in the text below, the first sentence was already present and
> the suggestion is to add the following one.
>
>
>

[RJ] Yes this works fine. I somehow missed the VIA option with lifetime 0.
I assume this NPDAO_via0 (VIA with lifetime=0) flows the same path as DAO.
Also consider the following scenario where the previously installed p2p
path is not available due to link breakage. Based on foll topology diagram,
if B switches path to C, if NPDA0_via0 is sent to B then we know that the
route cleanup wont be done at A since NPDAO_via0 will fail since the link
is not available. I understand that 6LBR will eventually know about this
since it wont receive DAO_ACK from A but m not sure what actions it can
take to ensure cleanup...
What if the route cleanup is initiated from common parent? i.e. from A and
flows downwards... i.e. NPDAO_via0 is sent to A and then it goes to B ...
this will result in more efficient cleanup. But i understand that now the
semantic changes between DAO and NPDAO_via0.
Note that without cleanup there is an impact on P2P traffic, hence it might
be needed to ensure cleanup if not much overhead is added.

>     DAO that must be used to reach the target in the RPL Target Option.
>

[RJ]: What does "to the source of the DAO" means in this context ?

> In

[RJ]: Yes the scheme works for me. If i m correct, this messaging which
involves having one or more addresses in VIO will now allow to install SRH
as well as storing mode routes using the same DAO message. Nice!

>
> Take care,
>
>
>
> Pascal
>
>
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mercredi 8 mars 2017 09:19
> *To:* Routing Over Low power and Lossy networks <[email-masked]>;
> [email-masked]
> *Subject:* RE: [Roll] DAO Projection
>
>
>
> Hello Rahul :
>
>
>
> [Pascal] Right. A sentence indicating that a lifetime of zero will trigger
> a NP DAO and do the cleanup should suffice. Do you agree?
>
>
>
> [Pascal] This is yet a new mechanism. I’m all for it. The 6LoRH make the
> task of encaps/insertion a lot easier now. All: if you disagree to the
> addition please let us know now.
>
>
>
> 3. There is a redundant paragraph and missing lines at the end of section
> 5 which tries explaining the example. Please fix the draft and will be nice
> to check that example.
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Mar 2017 08:45:40 +0000

Dear all :

Thanks to Rahul’s excellent comments, I actually reworked more than I thought I would the structure of the document, as I was inserting the changes we discussed.

Please feed back on the new version https://tools.ietf.org/html/draft-ietf-roll-dao-projection-01

You’ll find that:

1)      A lot of the descriptive text that was really use cases is now moved to appendix, making the specification piece a lot lighter.

2)      Non-storing Projected DAO is now described. This introduced an issue with the size of the address in the Via Info option, that we need to discuss. With this version of the draft, the address(es) is (are) not compressed.

3)      At the moment, the draft allows to mix any form of P-DAO (Storing vs non storing) with any mode of RPL. We need to discuss if that flies or not.

Take care,

Pascal

From: Pascal Thubert (pthubert)
Sent: mercredi 8 mars 2017 15:15
To: Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: RE: [Roll] DAO Projection

Hello Again Rahul :

     0                   1                   2                   3

Take care,

Pascal

From: Pascal Thubert (pthubert)
Sent: mercredi 8 mars 2017 09:19
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Roll] DAO Projection

Hello Rahul :

Please see below

Take care,
Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Mar 2017 15:39:24 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 3) At the moment, the draft allows to mix any form of P-DAO (Storing vs
    > non storing) with any mode of RPL. We need to discuss if that flies or
    > not.

If this permits the root to learn which nodes support P-DAO, and networks can
do incremental upgrades, that's a win to me.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Mar 2017 07:34:43 +0000

A good point to discuss at the meeting Michael.

In non-storing mode, the root has the DODAG topology, and we can extend the metrics containers to add node capabilities.

OTOH, in storing and for transversal routes in general, we are lacking means to provide the needed topological and node capabilities information, and the draft currently expects external means, such as YANG/TEAS. 

All in all, the question is whether we extend non storing DAOs in all cases, or define a new communication to the root.

That's probably a good thing to discuss at the meeting in Chicago.

Take care,

Pascal

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: lundi 13 mars 2017 20:39
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: [email-masked]
Subject: Re: [Roll] DAO Projection

    > non storing) with any mode of RPL. We need to discuss if that flies or

If this permits the root to learn which nodes support P-DAO, and networks can do incremental upgrades, that's a win to me.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-