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

[Rahul Jadhav <[e-mail]>]

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.

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


OTOH that EDAR may collision with another if the node moved. RFC 8505 has text for that.
What do you think?

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




> Le 12 avr. 2020 à 08:06, Rahul Jadhav <[e-mail]> a écrit :
> 
> 
> 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?
> 
> [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.