Re: [Roll] RUL and RootACK

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Rahul (as Shepherd), and all

I just submitted a correction of the RUL draft that removes the storing mode section.
Since the publication was already requested, can you please make a pass to validate the diffs?




The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-16

https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-16



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-16

Many thanks indeed!

Pascal

From: Roll <[e-mail]> On Behalf Of Rahul Jadhav
Sent: vendredi 5 juin 2020 09:45
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] RUL and RootACK

This clarifies all for me. Thanks Pascal, Rabi.
________________________________
From: Roll <[e-mail]> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]>
Sent: 05 June 2020 02:46 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] RUL and RootACK

...And for this I’m the one confused. I’m confused that I never removed that section when we decided to use NS signaling for RULs. It’s like that typo that the author can read 10 times and never see.  I need to make a pass!
Great catch Rahul !!!

Pascal


Le 5 juin 2020 à 04:08, Rahul Jadhav <[e-mail]> a écrit :

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll