Re: [Roll] RUL and RootACK

Thanks Rabi, I missed/forgot the IP-in-IP encap part. So source routing is
not needed to be supported in RPL network even if RUL is advertised to root
in NS-MOP.

But still, I don't understand Figure 9 in unaware-leaves draft. It shows
RUL target advertisement using DAO in storing MOP.

On Fri, 5 Jun 2020 at 09:18, rabi narayan sahoo <rabinarayans0828@gmail.com>
wrote:

> 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
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>