Subject: [Roll] unaware leaves - graceful shutdown of attached-6LR

From: Rahul Jadhav <[email-masked]>
Date: Mon, 13 Apr 2020 13:06:29 +0000

Hello Pascal/Authors,

In the event that the attached 6LR needs to gracefully shutdown, it needs to inform the RUL(s) to detach and possibly move to another 6LR.
I believe this could be done using NA(EARO, Status="Removed"); from the attached-6LR. Can this NA be multicasted if the attached-6LR has more than one RULs attached to it?
Is this correct/allowed? For RPL we have route-poisoning using which a 6LR does a graceful shutdown, but the route-poisoning is not applicable to RULs. I believe this should be clarified in the text.

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Apr 2020 15:14:17 +0000

Great point Rahul.

Normally this is done using a final RA. But the RA is broadcast so unicasting a NA with ‘R’ flag off is a great idea. This is the exact signal that this router does not serve this node. Lifetime 0 would indicate that the router removes the NCE.

Status removed indicates an error. I’d rather use status 0, lifetime 0, ‘R’ off. Don’t you think?

Keep safe.

Pascal

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

Hello Pascal/Authors,

In the event that the attached 6LR needs to gracefully shutdown, it needs to inform the RUL(s) to detach and possibly move to another 6LR.
I believe this could be done using NA(EARO, Status="Removed"); from the attached-6LR. Can this NA be multicasted if the attached-6LR has more than one RULs attached to it?
Is this correct/allowed? For RPL we have route-poisoning using which a 6LR does a graceful shutdown, but the route-poisoning is not applicable to RULs.. I believe this should be clarified in the text.

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

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 14 Apr 2020 02:04:48 +0000

Please find my response inline.

________________________________
From: Roll <[email-masked]> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]>
Sent: 13 April 2020 11:14 PM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Great point Rahul.

[RJ] Imo, Lifetime is something that is controlled by the target/owner. There has never been (?) a case where someone else changes lifetime on behalf of the target node.
RFC 8505 states: "Removed: The binding state was removed.  This Status MAY be placed in an NA(EARO) message that is sent as the rejection of a proxy registration to an IPv6 ND Registrar, or in an asynchronous NA(EARO), at any time."
I still feel using Status="Removed", 'R' off may be applicable more.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Apr 2020 08:25:19 +0000

Hello Rahul

For the lifetime I do not necessarily agree with your wording. My reading is that the registration lifetime is requested by the 6LN and granted by the 6LBR. What the 6LBR returns might be less than what the 6LN requested. This might not be very explicit in RFC 6775 but “5.5.2.  Processing a Neighbor Advertisement” says

“

   The host saves the Registration Lifetime from the ARO
   for use to trigger a new NS well before the lifetime expires.
”
Which tells you that the network has the ultimate control, which is good in a managed network.

Then “8.2.3.  6LR Sending a Duplicate Address Request” says
“

      The EUI-64 and Registration Lifetime are copied from the ARO

      received from the host.
”
Which tells you that the 6LR is just an transmission but has no say in the story.

Normally:
- If the 6LR stops being a router at all the signal is a final RA. We could actually mandate to unicast it to all registered nodes.
- If the 6LR accepts a registration it should keep it as long as it is a router so ‘removed’ comes from above.
- if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.

So we are talking about a unexpected case where the 6LR would drop an NCE on its own but continue being a router, IOW break its contract with the 6LN.

I see the value of using status “Removed” there. The problem I have here is to clarify what comes from the 6LBR which means that the address is not usable at all vs what comes from the 6LR, which means that this 6LR is not useable, but the 6LN can try with another 6LR. I thought the lifetime helped but on second thought it does not. “Removed” and lifetime are both 6LBR decisions.

If that’s a problem with the 6LR only, we need to signal that. RFC 8505 helps us there. Section “5.7.  Maintaining the Registration States” indicates that
“

   space is exhausted.  In that situation, the EARO is returned in an NA

   message with a status code of "Neighbor Cache Full" (Status 2; see

   [RFC6775<https://tools.ietf.org/html/rfc6775>] and Table 1), and the Registering Node may attempt to

   register to another 6LR.

   If the registry in the 6LBR is full, then the 6LBR cannot decide

   whether a registration for a new address is a duplicate.  In that

   case, the 6LBR replies to an EDAR message with an EDAC message that

   carries a new status code indicating "6LBR Registry Saturated"

   (Table 1).  Note: This code is used by 6LBRs instead of "Neighbor

   Cache Full" when responding to a Duplicate Address message exchange

   and is passed on to the Registering Node by the 6LR.  There is no

   point in the node retrying this registration via another 6LR, since

   the problem is network-wide.  The node may abandon that address,

   de-register other addresses first to make room, or keep the address

   "tentative" [RFC4861<https://tools.ietf.org/html/rfc4861>] and retry later.

“

So I’d suggest that we mandate unicast final RA if the router goes away, and if the router just drops that NCE then use "Neighbor Cache Full" in the NA.
Works?

Note: The 6BBR draft uses it for the 6LBR to clean up a state in the old 6BBR when registering to a new 6BBR. As a second thought it appears that ‘moved’ would be better. That’s what 6BBRs do with one another when it’s a different 6LBR. I’ll fix that unless someone raises an issue.

Regards,

Pascal

Le 14 avr. 2020 à 04:05, Rahul Jadhav <[email-masked]> a écrit :

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,
Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 14 Apr 2020 09:44:23 +0000

Thanks for the detailed response. Please find my response inline.

One key point you mentioned is that EARO parameters are managed by 6LBR. The initial registration happens using EDAR/EDAC through 6LBR and using EDAC(EARO-lifetime) the 6LBR can control the lifetime in the NA(EARO).
But during lifetime refresh, the keepalive NS sends a lifetime and the 6LR replies directly using NA using the same lifetime. Won't this lifetime create problems? Is it expected that the 6LR remembers the lifetime sent from 6LBR and uses it in the subsequent refresh NA(EARO) reply?

To instantiate this point, consider Figure 10 which shows that DAO is created from NS(EARO) and the lifetime of EARO is converted to lifetime in DAO-transit option. This DAO results in anonymous EDAR from Root to 6LBR and a response EDAC. The response EDAC status value is used in the DAO-ACK but the (possibly updated) lifetime from EDAC is dropped.

Sent: 14 April 2020 04:25 PM

Hello Rahul

“

”

[RJ] This makes sense to me now.

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

[RJ] So essentially NA(EARO) is strictly controlled by the 6LBR. Using 'Neighbor Cache Full' will tell the 6LN to move to other 6LR, and this should work, even though the status code does represent the appropriate reason.

I understand mandating final RA but why only unicast? Can't a multicast final RA be sent by a 6LR who is about to go down and has several RULs connected via it?

Regards,

Pascal

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,

Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Apr 2020 11:34:02 +0000

Hello Rahul

I agree, our proxy mechanism doesn’t allow to change the period in run time by the 6LBR. Note that the 6LBR or the Root could send an EDAC back to the 6LR asynchronously. There’ s not much text on that in the existing specs but it’s doable.

The multicast final RA is the normal behavior. Unicasting it is possible and more reliable. That was true already so I agree we do not need to mandate anything new here. It is something that we could have said in RFC 8505, nothing specific to RULs.

For the reason why the 6LR would on its own remove just one BCE, I only see the cache full. What else do you have in mind?

Cheers,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 11:44
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

________________________________
From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Sent: 14 April 2020 04:25 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Hello Rahul

“

”

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

Regards,

Pascal

Le 14 avr. 2020 à 04:05, Rahul Jadhav <[email-masked]<mailto:[email-masked]>> a écrit :

From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Sent: 13 April 2020 11:14 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Great point Rahul.

Keep safe.

Pascal

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

Hello Pascal/Authors,

Regards,

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

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 14 Apr 2020 12:11:59 +0000

Neighbor Cache full seems the only code that is applicable in this context.

However, can RA carry an EARO? RFC 8505/6775 mentions ARO/EARO only in context to NS/NA.

Sent: 14 April 2020 07:34 PM

Hello Rahul

Cheers,

Pascal

Hello Rahul

“

”

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

Regards,

Pascal

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,

Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Apr 2020 12:59:51 +0000

Hello Rahul

The RA would be a traditional final RA.

  1.  If the 6LR stops being a router at all the signal is a final RA. We could actually mandate to unicast it to all registered nodes.

  1.  if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.

  1.  If the 6LR accepts a registration it should keep it as long as it is a router. If -and that’s your case- the 6LR drops the registration but keeps acting for other registration. This is where it would send an EARO (Neighbor Cache full)

 Makes sense?

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 14:12
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Hello Rahul

Cheers,

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 11:44
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Hello Rahul

“

”

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

Regards,

Pascal

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,

Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 14 Apr 2020 13:06:08 +0000

Yes, it does make sense.
I think this covers it all.

Thanks,
Rahul
Sent: 14 April 2020 08:59 PM

Hello Rahul

 Makes sense?

Pascal

Hello Rahul

Cheers,

Pascal

Hello Rahul

“

”

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

Regards,

Pascal

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,

Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Apr 2020 11:35:19 +0000

Hello again Rahul.

So I’ll add:

“

   The 6LN signals the termination of a registration with a 6LR using an
   NS(EARO) with a Registration Lifetime set to 0.  Upon this, the 6LR
   MUST perform an EDAR/EDAC exchange to clean up the state at the 6LBR,
   as illustrated in Figure 8, unless it uses the ROVR in the RPL
   Target Option and, in Storing Mode, it is propagated to the Root.

“
And

“
   The 6LR may at any time send a unicast asynchronous NA(EARO) with the
   "R" flag reset to signal that it stops providing routing services,
   and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
   removes the NCE.  It may also send a final RA, unicast or multicast,
   with a Router Lifetime field of zero, to signal that it stops serving
   as router, as specified in section 6.2.5 of [RFC4861].

“

With this I believe we’re done. Please have a final look when I post 14.

Many thanks again!

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 15:06
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Yes, it does make sense.

Thanks,
Rahul

Hello Rahul

2.       if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.

3.       If the 6LR accepts a registration it should keep it as long as it is a router. If -and that’s your case- the 6LR drops the registration but keeps acting for other registration. This is where it would send an EARO (Neighbor Cache full)

 Makes sense?

Pascal

Hello Rahul

Cheers,

Pascal

Hello Rahul

“

”

“

      received from the host.

”

Normally:

“

   register to another 6LR.

“

Works?

Regards,

Pascal

Great point Rahul.

Keep safe.

Pascal

Hello Pascal/Authors,

Regards,

Rahul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2020 16:39:25 -0400

Rahul Jadhav <[email-masked]> wrote:
    > In the event that the attached 6LR needs to gracefully shutdown, it
    > needs to inform the RUL(s) to detach and possibly move to another 6LR.
    > I believe this could be done using NA(EARO, Status="Removed"); from the
    > attached-6LR. Can this NA be multicasted if the attached-6LR has more
    > than one RULs attached to it?

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > Normally this is done using a final RA. But the RA is broadcast so
    > unicasting a NA with ‘R’ flag off is a great idea. This is the exact
    > signal that this router does not serve this node. Lifetime 0 would
    > indicate that the router removes the NCE.

The other reason that I think that we need to unicast the NA is because it
needs to occur when the sleepy device is awake.
That could take some time to reach all devices!

I agree that it would be better to do this before the 6LR goes away, as the
next time a device like a window-smash sensor wakes up could be because it
needs to send an ALERT :-)

I think that in a 6tisch scenario, it might take a few cycles of the schedule
to get all the unicast NAs sent.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-