Subject: Re: [Roll] WGLC on draft-ietf-roll-unaware-leaves-13

From: Ines Robles <[email-masked]>
Date: Tue, 7 Apr 2020 12:57:51 +0300

Dear all,

We hope that you all are doing well and stay healthy

This is a kindly reminder of the WGLC for unaware-leaves draft.

It would be great if you could state your opinion on it.

Have a great day and thank you in advance,

Ines, Dominique and Michael

On Wed, Mar 25, 2020 at 5:45 PM <[email-masked]> wrote:

> Dear all,
>
> This is a gentle reminder that we are half-way through the WGLC for
> draft-ietf-roll-unaware-leaves-13.
> Please consider reading it and commenting on it.
> Thanks
>
> Dominique
>
> De : "[email-masked]" <[email-masked]>
> Date : Wednesday 18 March 2020 12:40
> À : "[email-masked]" <[email-masked]>
> Cc : Dominique Barthel <[email-masked]>
> Objet : WGLC on draft-ietf-roll-unaware-leaves-13
>
> Dear all,
>
> A Working Group Last Call (WGLC) starts today (03/18) until 04/01 for the
> draft-ietf-roll-unaware-leaves-13.
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
> Please review this draft to see if you think that it is ready for
> publication and send comments to the list stating your view.
> Thank you very much in advance,
>
> Ines and Dominique
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 8 Apr 2020 14:32:25 +0800

Dear Authors-of-unaware-leaves,

Following are my comments for the draft -13:

1. The draft requires that the first registration (EDAR/EDAC) is
directly handshaked with the 6LBR but all the subsequent refreshes
using DAO/DAO-ACK goes through the Root which in turn generates
anonymous EDAR/EDAC handshaked with the 6LBR.
**Can't we have the 6LR simply use DAO always to Root which generates
the EDAR(with ROVR)/EDAC to 6LBR?** This would simplify the handling
of 6LR. With the updated target option it is now possible to send ROVR
in target option in a backward-compatible fashion. The root is anyways
handling the anonymous EDAR/EDAC and thus has all the required
handling needed to proxy non-anonymous EDAR/EDAC. Also, the
de-registration is also handled through Root which means Root also has
to proxy non-anonymous EDAR/EDAC in that case? The de-registration
case is not clarified in the Figures 7,8,9.

2. The document introduces the term RAN for any RPL aware node which
can act as a parent node for the RUL. But in the document,
subsequently, the term 6LR is used to depict the parent node with
which the RUL attaches. Wondering why? Isn't RAN the appropriate term
to be used?

3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with the
"R" flag reset and a Registration Lifetime that is not 0, and the 6LR
was redistributing the Registered Address due to previous NS(EARO)
messages with the flag set, then it MUST stop injecting the address."
In this case, should the 6LR also evict the corresponding NCE?

4. Section 9.2.3: "the Registration Lifetime is adapted from the Path
Lifetime in the TIO by converting the Lifetime Units used in RPL into
units of 60 seconds used in the 6LoWPAN ND messages;"
The unit of lifetime for RPL is not a multiple of 60sec like that of
6lo ND. Thus it is possible that absolute conversion is not possible
in some cases. I guess the implementation should round-up in this
case?

5. Section 5 ... "anonymous message can only increase the lifetime"
... It should be "anonymous message can only update the lifetime"

6. Section 9.1 ... "On the first Address Registration, illustrated in
Figure 5 and Figure 8" ... Figure 8 currently does not show first
address registration.

7. Nits:
Sec 9.2.2 "that is sends in response" -> "that is sent in response"
Sec 10: "unicast to each if the interested children" -> "unicast to
each of the interested children"
Sec 10: "Layer-2 acknoledgement" -> "Layer-2 acknowledgement"
Sec 11: " whereby the it is possible to validate" ->  "whereby it is
possible to validate"
Sec 12.4: "DAO-ACK and RCO" -> "DAO-ACK and DCO"
Appendix A: " Follows the RPI-6LoRH and then the IP-in-IP 6LoRH." ->
Need to be rephrased

Thank you.

Best,
Rahul

On Tue, 7 Apr 2020 at 17:58, Ines Robles
<mariainesrobles=[email-masked]> wrote:
>> This is a gentle reminder that we are half-way through the WGLC for draft-ietf-roll-unaware-leaves-13.
>> De : "mariainesrobles@googlemail..com" <[email-masked]>
>> A Working Group Last Call (WGLC) starts today (03/18) until 04/01 for the draft-ietf-roll-unaware-leaves-13.
>> The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
>> Please review this draft to see if you think that it is ready for publication and send comments to the list stating your view.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Apr 2020 16:44:23 +0000

Many thanks Rahul!

I hope all is going right for you and your family; 

Let's see below, I need more precisions from you:

> 1. The draft requires that the first registration (EDAR/EDAC) is directly
> handshaked with the 6LBR but all the subsequent refreshes using DAO/DAO-
> ACK goes through the Root which in turn generates anonymous EDAR/EDAC
> handshaked with the 6LBR.
> **Can't we have the 6LR simply use DAO always to Root which generates the
> EDAR(with ROVR)/EDAC to 6LBR?** This would simplify the handling of 6LR.

Here is why: The 6LR does the traditional DAD and ensures that the address is not a duplicate before it injects it in RPL. 

On paper DAD is really a special operation that allows the address in the network. Using the address before DAD is against IPv6 and prone to attacks. 

E.g., if we skip that step, and RPL is not aware of the new ROVR field, then in storing mode the duplicate will take over the path as the DAO progresses upwards, and that's not desirable security-wise. When the Root comes back with a NPDAO, it's too late. At the moment, we do not change RPL to process the ROVR. Hopefully in the future we'll do more.

Arguably in non-storing we could do it because the flow is nested and the root can check with the 6LBR before it updates its state. That would be an even deeper integration of RPL and ND. Is that more useful than dangerous?

> With the updated target option it is now possible to send ROVR in target
> option in a backward-compatible fashion. The root is anyways handling the
> anonymous EDAR/EDAC and thus has all the required handling needed to
> proxy non-anonymous EDAR/EDAC. Also, the de-registration is also handled
> through Root which means Root also has to proxy non-anonymous
> EDAR/EDAC in that case? The de-registration case is not clarified in the Figures
> 7,8,9.

You're right we should add text on the deactivation of the state.

If the root cannot do non-anonymous then the state will stay as is in the 6LBR if an anonymous EDAR comes in with lifetime 0. The idea is really to add the ROVR to the DAO.

I will:
1) add figures for flows with lifetime=0
2) add text in the 6LBR section that indicates that a lifetime 0 is ignored in an anonymous EDAR. This is implicit already
" 
  an anonymous message can only increase the lifetime and/or increment the TID of an existing state at the 6LBR.
"
3) There is no mandate for using the ROVR in the target option. It is a SHOULD, should it be a MUST?

> 
> 2. The document introduces the term RAN for any RPL aware node which can
> act as a parent node for the RUL. But in the document, subsequently, the term
> 6LR is used to depict the parent node with which the RUL attaches. Wondering
> why? Isn't RAN the appropriate term to be used?
> 

This is by reference to RFC 8505, to echo what happens there. Wouldn't the use of RAN blur things?

> 3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with the "R" flag
> reset and a Registration Lifetime that is not 0, and the 6LR was redistributing
> the Registered Address due to previous NS(EARO) messages with the flag set,
> then it MUST stop injecting the address."

The NCE does not depend on the "R" flag. The flag controls the redistribution into RPL only.

> 
> 4. Section 9.2.3: "the Registration Lifetime is adapted from the Path Lifetime
> in the TIO by converting the Lifetime Units used in RPL into units of 60
> seconds used in the 6LoWPAN ND messages;"
> The unit of lifetime for RPL is not a multiple of 60sec like that of 6lo ND. Thus
> it is possible that absolute conversion is not possible in some cases. I guess
> the implementation should round-up in this case?

Yes, I can add "rounded up to the upper value". Is that OK?

> ... It should be "anonymous message can only update the lifetime"

I really meant that in terms of configuration, it can only increase the duration of the lifetime parameter but not reduce it, e.g., to 0. A lifetime value of less than the current value will trigger a restart of the current value.

That behavior on an anonymous can really be discussed. Think that anyone could send it, what change can we allow it to cause?

> 
> 6. Section 9.1 ... "On the first Address Registration, illustrated in Figure 5 and
> Figure 8" ... Figure 8 currently does not show first address registration.
> 

Oups fig 8 it was repurposed, because it was too obvious. Fixed in github. The paragraph becomes

"
   On the first Address Registration, illustrated in Figure 5 for RPL
   Non-Storing Mode, the Extended Duplicate Address exchange takes place
   as prescribed by [RFC8505].  Any combination of the logical functions
   of 6LR, Root and 6LBR might be collapsed in a single node.
"
> Sec 9.2.2 "that is sends in response" -> "that is sent in response"
Actually I meant "it sends" : )

> Sec 10: "unicast to each if the interested children" -> "unicast to each of the
> interested children"

> Sec 11: " whereby the it is possible to validate" ->  "whereby it is possible to
> validate"

> Appendix A: " Follows the RPI-6LoRH and then the IP-in-IP 6LoRH." -> Need to
> be rephrased

Wasn't that high poetry? Changed to

   The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
   When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
   precede it are also removed.

Many thanks again Rahul, waiting for your advice on the issues raised.

Be safe

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 10 Apr 2020 16:10:57 +0800

Please find my rsps inline.

Best,
Rahul

> I hope all is going right for you and your family;

[RJ] All is well, many thanks. And hope the same for you and all.

> Arguably in non-storing we could do it because the flow is nested and the root can check with the 6LBR before it updates its state. That would be an even deeper integration of RPL and ND. Is that m…

[RJ] I get the proposition now. I guess, it's better to leave the
initial EDAR/EDAC flow separate in all cases as specified in the
draft.
Another thing is the retry policy. EDAR/EDAC is sent multi hops away
and the loss probability is too high in our networks. It would be
great if implementers have some idea on what basis and how many times
to retry if the EDAC is not received. Wondering if this is covered in
other drafts, and I skimmed through 8505 without finding anything.
Ideally, a 6LR should make itself available for RULs only once it has
itself joined the network. In case of storing mode, we know from our
experience, this is not easy to ascertain (i.e., DAO-ACK does not mean
that end to end path is estd). But I guess, the worst case is that
EDAC will be lost and will be retried. But not sure who does the
retry, the RUL or the 6LR itself?

Also, the draft should make it clear that the 6LR should attempt the
DAO for the RUL only when the initial registration is successful. Not
doing this would possibly result in DAO for RUL reaching before
initial EDAR to the root causing problems (DAO reaching before would
mean the generation of anonymous EDAR and since 6LBR will not have an
entry it would answer "Removed" which in turn would be used as Status
in DAO-ACK)

> 1) add figures for flows with lifetime=0
[RJ] Thanks
>   an anonymous message can only increase the lifetime and/or increment the TID of an existing state at the 6LBR.
[RJ] Making it explicit will help.

> 3) There is no mandate for using the ROVR in the target option. It is a SHOULD, should it be a MUST?

[RJ] The ROVR will be a MUST only when a DAO for RUL is sent with a
lifetime of zero by the 6LR. If this is what you mean then yes, I
think it should be a MUST.

> This is by reference to RFC 8505, to echo what happens there. Wouldn't the use of RAN blur things?

[RJ] Yep it would blur when you read it in context to 8505. The only
reason why I brought this up is that without been routing-aware the
6LR cant handle things on behalf of RUL. We will just let this be as
it is.

> The NCE does not depend on the "R" flag. The flag controls the redistribution into RPL only.

[RJ] ok. Is there any scenario where RUL will reset 'R' flag
subsequently after setting it? I am wondering if 6LR should invalidate
the path when it gets 'R' flag is reset.

> Yes, I can add "rounded up to the upper value". Is that OK?

[RJ] Yep

> That behavior on an anonymous can really be discussed. Think that anyone could send it, what change can we allow it to cause?

[RJ]  thought it is possible for intermediate 6LRs to generate DAO on
behalf of RUL without any direct trigger from the RUL. In this case,
the lifetime will be a lower non-zero value.

> Wasn't that high poetry?
[RJ] Indeed it was and like any other high poetry, I couldn't
understand a thing! :-)

Changed to
>    precede it are also removed.
[RJ] Great, Thanks.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 11 Apr 2020 13:10:01 +0000

Hello Rahul:

I ended up doing multiple changes for your review so I published a 14 to help you validate them:

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

Continuing below:

> > Arguably in non-storing we could do it because the flow is nested and the root
> can check with the 6LBR before it updates its state. That would be an even
> deeper integration of RPL and ND. Is that more useful than dangerous?
> 
> [RJ] I get the proposition now. I guess, it's better to leave the initial EDAR/EDAC
> flow separate in all cases as specified in the draft.

Ack and agreed. No action.

> Another thing is the retry policy. EDAR/EDAC is sent multi hops away and the
> loss probability is too high in our networks. It would be great if implementers
> have some idea on what basis and how many times to retry if the EDAC is not
> received. Wondering if this is covered in other drafts, and I skimmed through
> 8505 without finding anything.

Good point! This is really inherited from RFC 6775 that stipulates:
"

8.2.6.  Recovering from Failures

   If there is no response from a 6LBR after RETRANS_TIMER [RFC4861],
   then the 6LR would retransmit the DAR to the 6LBR up to
   MAX_UNICAST_SOLICIT [RFC4861] times.  After this, the 6LR SHOULD
   respond to the host with an ARO Status of zero.

"
Note that the default RFC4861 values are usually not appropriate from deep inside a mesh.

Action add the last sentence in the text below:
"

3.3.  RFC 8505 Extended DAR/DAC

   [RFC8505] updates the periodic DAR/DAC exchange that takes place
   between the 6LR and the 6LBR using Extended DAR/DAC messages which
   can carry a ROVR field of variable size.  The exchange is triggered
   by an NS(EARO) message and is intended to create, refresh and delete
   the corresponding state in the 6LBR for a lifetime that is indicated
   by the 6LN.  It is protected by the ARQ mechanism specified in 8.2.6
   of [RFC6775], though in an LLN, a duration longer than the
   RETRANS_TIMER [RFC4861] of 1 second may be necessary to cover the
   Turn Around Trip delay from the 6LR to the 6LBR.
".

> Ideally, a 6LR should make itself available for RULs only once it has itself joined
> the network.

By which you mean "reachable through RPL" I guess. 

Having completed the join process (fig 5 of https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-4.2.1) is usually what people mean by joined.

I understand that you mean that beyond fig 7, you also ascertained that the 6LR's address is reachable though RPL. And I agree from the points you made earlier that we are lacking a reachability test.

Note that a successful EDAR/EDAC exchange on behalf of the RUL is such a proof. But it happens a bit late, the 6LR would waste a lot of energy retrying EDARs if it is not effectively reachable. We can probably do better. Ready when you are, but that's a different scope.

> In case of storing mode, we know from our experience, this is not
> easy to ascertain (i.e., DAO-ACK does not mean that end to end path is estd). But
> I guess, the worst case is that EDAC will be lost and will be retried. But not sure
> who does the retry, the RUL or the 6LR itself?

Both retries are defined. The RUL will retry the NS(EARO) on its own time in case that is what was lost, also per RFC 6775. RFC 6775 is not specific about the retry, so it is inherited from the NS process in RFC 4861. 
"
   The response to an address registration might not be immediate, since
   in route-over configurations the 6LR might perform Duplicate Address
   Detection against the 6LBR.  A host retransmits the Address
   Registration Option until it is acknowledged by the receipt of an
   Address Registration Option.

"
Certainly the timer on the RUL must be longer than that in the 6LR, but anyway there's no limit to the number of retries.

No action.

> 
> Also, the draft should make it clear that the 6LR should attempt the DAO for the
> RUL only when the initial registration is successful. Not doing this would possibly
> result in DAO for RUL reaching before initial EDAR to the root causing problems
> (DAO reaching before would mean the generation of anonymous EDAR and
> since 6LBR will not have an entry it would answer "Removed" which in turn
> would be used as Status in DAO-ACK)

The text already has:
"

   When successful, the flow creates a Neighbor Cache Entry (NCE) in the
   6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO-
   ACK exchanges all the way to the RPL DODAG Root.  The protocol does
   not carry a specific information that the Extended Duplicate Address
   messages were already exchanged, so the Root proxies them anyway.

"
And in section in 9.2.2
"
  Also as prescribed by [RFC8505], the 6LR generates an EDAR message
   upon reception of a valid NS(EARO) message for the Address
   Registration of a new IPv6 Address by a 6LN and for the termination
   of a registration (lifetime of 0).

   If the initial EDAR/EDAC exchange succeeds, then the 6LR installs an
   NCE for the registration lifetime.

"

If the exchange fails, we're in RFC 6775/8505 land, the registration is rejected with status 1 'duplicate'.
To clarify I'm adding the second sentence below:
"
   On the first Address Registration, illustrated in Figure 5 for RPL
   Non-Storing Mode, the Extended Duplicate Address exchange takes place
   as prescribed by [RFC8505].  If the exchange fails, the 6LR returns
   an NA message with a negative status to the 6LN, the NCE is not
   created and the address is not injected in RPL.
"

> 
> >
> > > With the updated target option it is now possible to send ROVR in
> > > target option in a backward-compatible fashion. The root is anyways
> > > de-registration is also handled through Root which means Root also
> > > has to proxy non-anonymous EDAR/EDAC in that case? The
> > > de-registration case is not clarified in the Figures 7,8,9.
> >
> > If the root cannot do non-anonymous then the state will stay as is in the 6LBR
> if an anonymous EDAR comes in with lifetime 0. The idea is really to add the
> ROVR to the DAO.
> >
> > I will:

See the figure and new text in Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-14 

> > 2) add text in the 6LBR section that indicates that a lifetime 0 is
> > ignored in an anonymous EDAR. This is implicit already "

Added the last sentence in
"
   6.  Upon receiving an NS message with an EARO and the "R" flag set,
       the 6LR SHOULD inject the Registered Address in RPL by sending a
       DAO message on behalf of the 6LN.  If the Registration Lifetime
       was 0, the effect is to remove the route and then the NCE; this
       also causes the Root as a proxy to send and EDAR/EDAC to the
       6LBR with a Lifetime of 0.
"

OK will do that

> [RJ] The ROVR will be a MUST only when a DAO for RUL is sent with a lifetime of
> zero by the 6LR. If this is what you mean then yes, I think it should be a MUST.

There will still be the case of a legacy node, to the Root will have to cope with no ROVR.
The text did not MUST on the termination because there is a proposed alternative of doing the EDAR exchange there. 

SHOULD we MUST it all the time? 

It is also useful to control the 6LBR, e.g., reduce the lifetime. 
It is mostly protecting the future for more zerotrust security using the ROVR in RPL. We can work on that rapidly once the RUL work is complete. The cost is the extra bytes obviously.

> > > subsequently, the term
> > > 6LR is used to depict the parent node with which the RUL attaches.
> > > Wondering why? Isn't RAN the appropriate term to be used?
> > >
> >
> [RJ] Yep it would blur when you read it in context to 8505. The only reason why
> I brought this up is that without been routing-aware the 6LR cant handle things
> on behalf of RUL. We will just let this be as it is.
> 

Cool, no change there then

> >
> >
> > > 3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with
> > > the "R" flag reset and a Registration Lifetime that is not 0, and
> > > the 6LR was redistributing the Registered Address due to previous
> > > NS(EARO) messages with the flag set, then it MUST stop injecting the
> address."
> [RJ] ok. Is there any scenario where RUL will reset 'R' flag subsequently after
> setting it? I am wondering if 6LR should invalidate the path when it gets 'R' flag is
> reset.

If the RUL does not want to use that 6LR anymore but say another one. But it still wants to keep the state in the 6LR in case it switches back, or for packets in flight.

> 
> >
> > >
> > > 4. Section 9.2.3: "the Registration Lifetime is adapted from the
> > > Path Lifetime in the TIO by converting the Lifetime Units used in
> > > RPL into units of 60 seconds used in the 6LoWPAN ND messages;"
> > > in some cases. I guess the implementation should round-up in this case?
> >

Will do

> > I really meant that in terms of configuration, it can only increase the duration
> of the lifetime parameter but not reduce it, e.g., to 0. A lifetime value of less
> than the current value will trigger a restart of the current value.
> >
> > That behavior on an anonymous can really be discussed. Think that anyone
> could send it, what change can we allow it to cause?
> 
> [RJ]  thought it is possible for intermediate 6LRs to generate DAO on behalf of
> RUL without any direct trigger from the RUL. In this case, the lifetime will be a
> lower non-zero value.

True, and the router has the ROVR so it can reduce the lifetime. If that 6LR is an attacker, since it is on, it can do anything, changing the lifetime is only one out of many possibilities. What we want to prevent here is that other nodes not on-path may alter the path. This reduces the perimeter of attacks.

> > > 6. Section 9.1 ... "On the first Address Registration, illustrated
> > > in Figure 5 and Figure 8" ... Figure 8 currently does not show first address
> registration.
> > >
> >
> [RJ] Indeed it was and like any other high poetry, I couldn't understand a thing!
> :-)

Arfffff!!!

> >    precede it are also removed.

There's the MUST on each DAO that's still open, otherwise I believe I covered it all in 14.

Please let me know!

Many thanks, Rahul 😊

Keep safe;

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Sat, 11 Apr 2020 15:38:52 +0000

I went through the diff and it seems ok to me. Thanks
Regarding ROVR, pls find my rsp inline.

[RJ] Sorry, but I am still not clear on the proposition here. Are you proposing that all the DAO target options MUST carry a ROVR field even in regular case? I understand that using ROVR might improve security in the future but the cost is high in my opinion.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 11 Apr 2020 16:38:13 +0000

Yes that was the proposal and yes the cost is high. Maybe we could MUST a knob to turn it on if it is not always?

Regards,

Pascal

Le 11 avr. 2020 à 17:39, Rahul Jadhav <[email-masked]> a écrit :

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 12 Apr 2020 06:05:53 +0000

[RJ] Agree, conditionally will be better. One more thing that I realized that intermediate 6LRs won't be able to generate a DAO with the ROVR when they generate it by themselves i.e., on parent-switch, ... unless they maintain ROVR in the routing entry context. Is this the case?
Another thing to consider for backward compatibility, in storing MOP the intermediate 6LRs who do not support this draft may just zero out the ROVRsz and the ROVR field depending on how the implementation is done. For e.g., contiki-ng just forwards the DAO based on the downstream input DAO and won't have an issue but any other implementation which generates the DAO locally based on routing entry will have an issue.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 12 Apr 2020 15:34:55 +0000

Hello Rahul 

That’s interesting because the 6LR would not know that a parent erased the ROVR. So it’s probably safer to send the EDAR upon a termination NS AERO.

OTOH that EDAR may collision with another if the node moved. RFC 8505 has text for that.

What do you think?

Pascal

> Le 12 avr. 2020 à 08:06, Rahul Jadhav <[email-masked]> a écrit :
> 
>

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 13 Apr 2020 00:57:47 +0000

[RJ] It's probably safer to send EDAR from attached-6LR upon a termination NA EARO to 6LBR. This would remove the dependency on ROVR been sent intact en route the storing MOP path. However, all these issues are with storing MOP only. In non-storing MOP, this additional EDAR will be wasteful since target+ROVR can be carried safely to the root.

[RJ] If EDAR collides, we can count on TID to handle this. 8505 makes it clear.

> Another thing to consider for backward compatibility, in storing MOP the intermediate 6LRs who do not support this draft may just zero out the ROVRsz and the ROVR field depending on how the implementation is done. For e.g., contiki-ng just forwards the DAO
 based on the downstream input DAO and won't have an issue but any other implementation which generates the DAO locally based on routing entry will have an issue.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Apr 2020 07:49:08 +0000

WFM, Rahul 

Note that the issue is the lifetime 0 arriving faster than over the new path, causing the 6 LBR to temporarily remove the state. This is why there’s a timer at the 6LBR. The new text in the RUL draft also indicates to send the lifetime =0 last. This is not a guarantee but it helps.

Stay safe and many thanks again!

Pascal

> Le 13 avr. 2020 à 02:58, Rahul Jadhav <[email-masked]> a écrit :
> 
>