Re: [Roll] DAO Projection

[Rahul Jadhav <[e-mail]>]

Hello Pascal,

Please find my resp inline...

Regards,
Rahul

On 8 March 2017 at 06:14, Pascal Thubert (pthubert) <[e-mail]>
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.
>
>
>
>      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.
>

[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.

[image: Inline images 1]

>
>
>
>
>
>
>
>
> 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.
>

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


> 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?
>

[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 <[e-mail]>;
> [e-mail]
> *Subject:* RE: [Roll] DAO Projection
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> [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
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>