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

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

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 <[e-mail]> a écrit :

Please find my response inline.

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

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?

[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


Le 13 avr. 2020 à 15:07, Rahul Jadhav <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll