Re: [Roll] Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR

[Rahul Jadhav <[e-mail]>]

Just for the record, I am ok with this.
Use of updated target option (which adds ROVR field to the target option) to the root will not only simplify implementation but also reduce the control overhead. The 6LR can simply refresh the RUL route entry using DAO and depend on Root to refresh the EDAR to the 6LBR.
Secondly, ROVR can serve as a verifier for the target IPv6 address in general and its association to the Target is reasonable.

Best,
Rahul
________________________________
From: Roll <[e-mail]> on behalf of Pascal Thubert (pthubert) <pthubert=[e-mail]>
Sent: 09 June 2020 03:35 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: [Roll] Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR


Dear all



Rahul and I are having a thread on the RUL draft. This started with the removal of deprecated text on storing mode that was still there by (my) mistake in the latest version (draft 16). The realization is that if the RUL’s parent uses the Updated Target Option, since we are using non-storing signaling only, the root will always get it, there will not be a storing mode grandparent on the way that may not understand it and loose it. As of now the root already supports it anyway



So one major possible simplification came up, quoting:

“

(PT] We allow the 6LR to use the old target option without the ROVR. The consequence is that we have all that text about anonymous EDAR. This complexity comes from the days we have storing mode signaling for the RUL’s DAO, since we had to live with legacy nodes in the path. This is gone with the non-storing mode used all the time for RULs. Since we are updating the 6LR can’t we mandate that it uses the updated target option?

If we mandate that it always does, the spec is considerably simpler (like 1 or 2 pages less).



[RJ] Mandating updated Target Option simplifies considerably. And like you mentioned the 6LR needs to be modified anyway. One more thing to point out is that the modified target option needs to be supported only by the RUL-attaching-6LR (not all 6LRs/6LNs) and the Root.





“



Since we passed WGLC, the question to the group is whether we all agree that the parent 6LR MUST use the Updated Target Option – a SHOULD right now. I’m doing it in my sandbox as an exercise. If there is no opposition I wish to commit it as 17 before the IESG rounds start.



Are we OK? Do I miss something?



Take care



Pascal