Re: [Roll] RUL and RootACK

Hi
I think here we have two things to address
1- Advertise the RUL address to DODAG root.
2- Data plane communication between the DODAG root and RUL.

Irrespective of RPL network operate in storing and non-storing mode
advertisement of RUL target address to the DODAG root will happen using
Non-Storing mode DAO.
For data packets, from DODAG root to RUL, the root needs to use
Ipv6-in-Ipv6 encapsulation if the RPL network is operating in storing mode
of operation and Source routing in case of a non-storing mode of operation.

Thanks
Rabi

On Fri, Jun 5, 2020 at 6:23 AM Rahul Jadhav <rahul.ietf@gmail.com> wrote:

> Thanks Pascal,
>
> But I am more confused now.
> Figure 5 [1] attaches the RUL in the RPL network in Non-storing mode.
> Figure 9 attaches the RUL in the RPL network using storing mode.
> This is what I always thought.
>
> If RUL "always" uses non-storing signalisation then what does figure 9
> represent?
>
> Also if RUL always uses NS-MOP even if the RPL network is in storing mode,
> doesn't it raise a basic question that the RPL network has to mandatorily
> support source-routing regardless of the MOP? Currently in my network
> source-routing is not enabled if RPL is operating in storing MOP.
>
> [1]
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1
>
>
> On Thu, 4 Jun 2020 at 23:34, Pascal Thubert (pthubert) <pthubert=
> 40cisco.com@dmarc..ietf.org <40cisco.com@dmarc.ietf.org>> wrote:
>
>> Hello Rahul
>>
>> You should look at fig. 5 in
>> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1 not
>> fig. 9 since we are using Non Storing signalisation for RULs in all cases.
>> IOW the root ack problem does not exist for RULs.
>>
>> More details:
>>
>> The idea is for the root to answer a non storing DAO with a DAO ack to
>> the sender.
>>
>> Normally In NS mode the sender is the RAL that advertises its parent as
>> transit and the DAO Ack serves as root ack and confirms reachability.
>>
>> In the RUL case, the Root answers to the parent. That answer confirms to
>> the parent that the RUL is reachable and serves as root ack. Then the
>> parent sends the NA(EARO) which confirms reachability to the RUL.
>>
>> Are we good or do I miss something?
>>
>> Pascal
>>
>> Le 4 juin 2020 à 15:00, Rahul Jadhav <nyrahul@outlook.com> a écrit :
>>
>> 
>> Hi Pascal,
>>
>> Last we discussed handling storing mode RUL flow with RootACK in a way
>> that NA is sent to the RUL after it gets the RootACK. This way RUL can
>> initiate its app traffic once e2e path is established.
>>
>> Figure 9 in
>> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.2
>> handles Storing mode First registration flow for RULs.
>>
>> My problem is (consider the figure 9), how will the Root know whom to
>> send the RootACK. In the regular cases, the target node in DAO is the
>> destination for RootACK. But in this case, the target is RUL and RootAck
>> cannot be sent to RUL. For external targets, can we use ParentAddr in
>> Transit Information Option to send this field? Anyways the 6LR indeed is
>> the parent node for RUL.
>>
>> Any thoughts/suggestions?
>>
>> Thanks,
>> Rahul
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>