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

[Rahul Jadhav <[e-mail]>]

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

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


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 <[e-mail]> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 14:12
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



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.





________________________________

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



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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 11:44
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



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.



________________________________

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



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.



[RJ] This makes sense to me now.



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?



[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?



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



Please find my response inline.



________________________________

From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Sent: 13 April 2020 11:14 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[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]<mailto:[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]<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