Subject: [Roll] RUL and RootACK

From: Rahul Jadhav <[email-masked]>
Date: Thu, 4 Jun 2020 12:59:51 +0000

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jun 2020 15:33:58 +0000

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 <[email-masked]> a écrit :

Hi Pascal,

Thanks,
Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jun 2020 08:52:49 +0800

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

---

From: rabi narayan sahoo <[email-masked]>
Date: Fri, 5 Jun 2020 06:48:23 +0530

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 <[email-masked]> wrote:

> 40cisco.com@dmarc..ietf.org <[email-masked]>> wrote:
>
>> Hello Rahul
>>
>> 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

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jun 2020 10:07:31 +0800

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 <[email-masked]>
wrote:

>> 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]
>> 40cisco.com@dmarc..ietf.org <[email-masked]>> wrote:
>>
>>> Hello Rahul
>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Jun 2020 06:46:13 +0000

...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 <[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Pascal,

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:[email-masked]>> wrote:
Hello Rahul

More details:

Pascal

Le 4 juin 2020 à 15:00, Rahul Jadhav <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Thanks,
Rahul
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jun 2020 07:44:45 +0000

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

Great catch Rahul !!!

Pascal

Thanks
Rabi

More details:

Pascal

Hi Pascal,

Thanks,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 14:11:21 +0000

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

Pascal

Thanks
Rabi

More details:

Pascal

Hi Pascal,

Thanks,
Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 8 Jun 2020 16:02:06 +0000

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

Sent: 08 June 2020 10:11 PM

Many thanks indeed!

Pascal

Great catch Rahul !!!

Pascal

Hi

Thanks

Rabi

Thanks Pascal,

Hello Rahul

More details:

Pascal

Hi Pascal,

Thanks,

Rahul

---

From: rabi narayan sahoo <[email-masked]>
Date: Mon, 8 Jun 2020 22:03:36 +0530

Hi Pascal

Section 6.2 *of RPL Unaware Leaves draft* states that

“Section 4.1 of [USEofRPLinfo] provides a set of rules that MUST be
followed for the routing operations to a RUL.

A 6LR that is upgraded to act as a border router for external routes
advertises them using Non-Storing Mode DAO messages that are unicast
directly to the Root, even if the DODAG is operated in Storing Mode.”

*Section 4.1 of the RPL Data Plane* (USEofRPLinfo) also states the same
thing

“This specification updates [RFC6550] to RECOMMEND that external targets
are advertised using Non-Storing Mode DAO messaging even in a Storing-Mode
network”

Here Non-Storing Mode DAO is basically a DAO message with transit
information option having a valid parent address.

*Do these statement overrides the rule mentioned in section 9.8 of RFC
6550?*

“In Storing mode, RPL routes messages Downward by the IPv6 destination address.
The following rules apply to nodes that are in Storing

mode:

1. The DODAG Parent Address subfield of a Transmit Information option MUST
be empty.”

Implementations  complying  with RFC 6550, operating in storing mode can
reject DAO messages, with transit information having a valid parent address
subfield.

I feel both the draft need to update this MUST clause of RFC 6550 and it’s
missing in both the drafts.

Thanks

Rabi

On Mon, Jun 8, 2020 at 7:42 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> *From:* Roll <[email-masked]> *On Behalf Of *Rahul Jadhav
> *Sent:* vendredi 5 juin 2020 09:45
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* Re: [Roll] RUL and RootACK
>
>
>
> ------------------------------
>
> *From:* Roll <[email-masked]> on behalf of Pascal Thubert
> (pthubert) <pthubert=[email-masked]>
> *Sent:* 05 June 2020 02:46 PM
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *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
>
>
>
> On Fri, 5 Jun 2020 at 09:18, rabi narayan sahoo <
> [email-masked]> wrote:
>
> Hi
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jun 2020 17:10:16 +0000

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 <[email-masked]> On Behalf Of Rahul Jadhav
Sent: lundi 8 juin 2020 18:02
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] RUL and RootACK

Thanks Pascal,

Few comments:

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

Many thanks indeed!

Pascal

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

From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Sent: 05 June 2020 02:46 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] RUL and RootACK

Great catch Rahul !!!

Pascal

Le 5 juin 2020 à 04:08, Rahul Jadhav <[email-masked]<mailto:[email-masked]>> a écrit :

Hi

Thanks

Rabi

Thanks Pascal,

Hello Rahul

More details:

Pascal

Hi Pascal,

Thanks,

Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 9 Jun 2020 02:25:09 +0000

Hi Pascal, Please find my comments inline.

Sent: 09 June 2020 01:10 AM

Hello Rahul:

[RJ] Mandating updated Target Option simplifies considerably. And like you mentioned the 6LR needs to be modified anyway. One more thing to point out is that the modified target option needs to be supported only by the RUL-attaching-6LR (not all 6LRs/6LNs) and the Root.

[RJ] I am not sure if we should MUST it. The Root may want to use DCO only in async case and use DAO-ACK with negative status (even without explicit ACK request in DAO, 6550 allows this). Another point is, with Non-storing DAO, intermediate 6LRs do not install the routes for RUL. Thus, the need for explicit DCO is even less necessary. DCO will be used to only clear the NCE on the attaching-6LR. Depending on the deployment there may be other ways to handle that cleanup.

[RJ] Yes, I feel "refresh EDAR" as a term will help.

Can do.

[RJ] This works great for me.

[RJ] Works great.

Pascal

Thanks Pascal,

Few comments:

Best,

Rahul

Many thanks indeed!

Pascal

Great catch Rahul !!!

Pascal

Hi

Thanks

Rabi

Thanks Pascal,

Hello Rahul

More details:

Pascal

Hi Pascal,

Thanks,

Rahul