Re: [Roll] RUL and RootACK

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

Hello Rahul:

All good questions, I’d like the group to consider this.

There’s complexity in the draft for 2 reasons:

  1.  We allow the 6LR to use the old target option without the ROVR. The consequence is that we have all that text about anonymous EDAR. This complexity comes from the days we have storing mode signaling for the RUL’s DAO, since we had to live with legacy nodes in the path. This is gone with the non-storing mode used all the time for RULs. Since we are updating the 6LR can’t we mandate that it uses the updated target option?

If we mandate that it always does, the spec is considerably simpler (like 1 or 2 pages less).

  1.  We allow the 6LR not to request a DAO ack. This causes an async DCO in case of trouble. Should we MUST it?


Now in details to your points

  1.  Section 9 says that all the section flows assume "P" flag to be set essentially meaning that Root has Proxy capability... also meaning that 6LR should refrain from sending EDAR directly (as per section 5). However, the first registration flow Figure 5 in sub-section 9.1 shows that the 6LR is sending the EDAR.
Yes, this is a summary, I can fix it easily by adding “refresh”. The normative text indicates that the first and possibly the last EDARs must be sent directly. The extra complexity in the last depends on whether the 6LR uses the updated target option. If it does, the 6LR only sends the first EDAR (for DAD) and no more.

  1.  Figure 4: Do we need alignment to 4-byte boundary? Octet alignment should be enough and will save bytes for odd prefixes.
Can do.

  1.  Updated Target Option: There is one restriction with updated target option. Earlier it was possible to send partial prefix but full target address, for e.g., Let's say the target address is fd00::1234/128 but the target node also manages the prefix fd00::/64. It was possible to send full fd00::1234 but set the prefix length to 64. This syntax is needed for future extensions such as RootACK wherein the Root needs to send the RootACK to the Target node even though the target node has advertised only a prefix (and not the full address). With updated target option, this is no more possible!
Hum; maybe we could add a flag that says that the address is in full 128 bits and is a valid address of the originator of the DAO? This would avoid implicits…

  1.  Section 9.1 says, " If it is successful, the 6LR creates an NCE and injects the Registered Address in RPL using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root." This wording reflects DAO storing MOP behavior.
Agreed, I’ll fix that to “using a DAO/DAO-ACK exchange with the RPL DODAG Root”
Please let me know your thoughts;
Pascal



From: Roll <[e-mail]> On Behalf Of Rahul Jadhav
Sent: lundi 8 juin 2020 18:02
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] RUL and RootACK

Thanks Pascal,

Few comments:

  1.  Section 9 says that all the section flows assume "P" flag to be set essentially meaning that Root has Proxy capability... also meaning that 6LR should refrain from sending EDAR directly (as per section 5). However, the first registration flow Figure 5 in sub-section 9.1 shows that the 6LR is sending the EDAR.
  2.  Figure 4: Do we need alignment to 4-byte boundary? Octet alignment should be enough and will save bytes for odd prefixes.
  3.  Updated Target Option: There is one restriction with updated target option. Earlier it was possible to send partial prefix but full target address, for e.g., Let's say the target address is fd00::1234/128 but the target node also manages the prefix fd00::/64. It was possible to send full fd00::1234 but set the prefix length to 64. This syntax is needed for future extensions such as RootACK wherein the Root needs to send the RootACK to the Target node even though the target node has advertised only a prefix (and not the full address). With updated target option, this is no more possible!
  4.  Section 9.1 says, " If it is successful, the 6LR creates an NCE and injects the Registered Address in RPL using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root." This wording reflects DAO storing MOP behavior.
Best,
Rahul

________________________________
From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Sent: 08 June 2020 10:11 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] RUL and RootACK


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



This clarifies all for me. Thanks Pascal, Rabi.

________________________________

From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Sent: 05 June 2020 02:46 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll