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

[Rahul Jadhav <[e-mail]>]

Please find my rsps inline.

Best,
Rahul

On Fri, 10 Apr 2020 at 00:46, Pascal Thubert (pthubert)
<pthubert=[e-mail]> wrote:
>
> Many thanks Rahul!
>
> I hope all is going right for you and your family;

[RJ] All is well, many thanks. And hope the same for you and all.

>
> Let's see below, I need more precisions from you:
>
> > 1. The draft requires that the first registration (EDAR/EDAC) is directly
> > handshaked with the 6LBR but all the subsequent refreshes using DAO/DAO-
> > ACK goes through the Root which in turn generates anonymous EDAR/EDAC
> > handshaked with the 6LBR.
> > **Can't we have the 6LR simply use DAO always to Root which generates the
> > EDAR(with ROVR)/EDAC to 6LBR?** This would simplify the handling of 6LR.
>
> Here is why: The 6LR does the traditional DAD and ensures that the address is not a duplicate before it injects it in RPL.
>
> On paper DAD is really a special operation that allows the address in the network. Using the address before DAD is against IPv6 and prone to attacks.
>
>
> E.g., if we skip that step, and RPL is not aware of the new ROVR field, then in storing mode the duplicate will take over the path as the DAO progresses upwards, and that's not desirable security-wise. When the Root comes back with a NPDAO, it's too late. At the moment, we do not change RPL to process the ROVR. Hopefully in the future we'll do more.
>
> Arguably in non-storing we could do it because the flow is nested and the root can check with the 6LBR before it updates its state. That would be an even deeper integration of RPL and ND. Is that more useful than dangerous?

[RJ] I get the proposition now. I guess, it's better to leave the
initial EDAR/EDAC flow separate in all cases as specified in the
draft.
Another thing is the retry policy. EDAR/EDAC is sent multi hops away
and the loss probability is too high in our networks. It would be
great if implementers have some idea on what basis and how many times
to retry if the EDAC is not received. Wondering if this is covered in
other drafts, and I skimmed through 8505 without finding anything.
Ideally, a 6LR should make itself available for RULs only once it has
itself joined the network. In case of storing mode, we know from our
experience, this is not easy to ascertain (i.e., DAO-ACK does not mean
that end to end path is estd). But I guess, the worst case is that
EDAC will be lost and will be retried. But not sure who does the
retry, the RUL or the 6LR itself?

Also, the draft should make it clear that the 6LR should attempt the
DAO for the RUL only when the initial registration is successful. Not
doing this would possibly result in DAO for RUL reaching before
initial EDAR to the root causing problems (DAO reaching before would
mean the generation of anonymous EDAR and since 6LBR will not have an
entry it would answer "Removed" which in turn would be used as Status
in DAO-ACK)

>
> > With the updated target option it is now possible to send ROVR in target
> > option in a backward-compatible fashion. The root is anyways handling the
> > anonymous EDAR/EDAC and thus has all the required handling needed to
> > proxy non-anonymous EDAR/EDAC. Also, the de-registration is also handled
> > through Root which means Root also has to proxy non-anonymous
> > EDAR/EDAC in that case? The de-registration case is not clarified in the Figures
> > 7,8,9.
>
> You're right we should add text on the deactivation of the state.
>
> If the root cannot do non-anonymous then the state will stay as is in the 6LBR if an anonymous EDAR comes in with lifetime 0. The idea is really to add the ROVR to the DAO.
>
> I will:
> 1) add figures for flows with lifetime=0
[RJ] Thanks
> 2) add text in the 6LBR section that indicates that a lifetime 0 is ignored in an anonymous EDAR. This is implicit already
> "
>   an anonymous message can only increase the lifetime and/or increment the TID of an existing state at the 6LBR.
> "
[RJ] Making it explicit will help.

> 3) There is no mandate for using the ROVR in the target option. It is a SHOULD, should it be a MUST?

[RJ] The ROVR will be a MUST only when a DAO for RUL is sent with a
lifetime of zero by the 6LR. If this is what you mean then yes, I
think it should be a MUST.

>
>
> >
> > 2. The document introduces the term RAN for any RPL aware node which can
> > act as a parent node for the RUL. But in the document, subsequently, the term

> > 6LR is used to depict the parent node with which the RUL attaches. Wondering
> > why? Isn't RAN the appropriate term to be used?
> >
>
> This is by reference to RFC 8505, to echo what happens there. Wouldn't the use of RAN blur things?

[RJ] Yep it would blur when you read it in context to 8505. The only
reason why I brought this up is that without been routing-aware the
6LR cant handle things on behalf of RUL. We will just let this be as
it is.

>
>
> > 3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with the "R" flag
> > reset and a Registration Lifetime that is not 0, and the 6LR was redistributing
> > the Registered Address due to previous NS(EARO) messages with the flag set,
> > then it MUST stop injecting the address."
> > In this case, should the 6LR also evict the corresponding NCE?
>
> The NCE does not depend on the "R" flag. The flag controls the redistribution into RPL only.

[RJ] ok. Is there any scenario where RUL will reset 'R' flag
subsequently after setting it? I am wondering if 6LR should invalidate
the path when it gets 'R' flag is reset.

>
> >
> > 4. Section 9.2.3: "the Registration Lifetime is adapted from the Path Lifetime
> > in the TIO by converting the Lifetime Units used in RPL into units of 60
> > seconds used in the 6LoWPAN ND messages;"
> > The unit of lifetime for RPL is not a multiple of 60sec like that of 6lo ND. Thus
> > it is possible that absolute conversion is not possible in some cases. I guess
> > the implementation should round-up in this case?
>
> Yes, I can add "rounded up to the upper value". Is that OK?

[RJ] Yep

>
>
> >
> > 5. Section 5 ... "anonymous message can only increase the lifetime"
> > ... It should be "anonymous message can only update the lifetime"
>
> I really meant that in terms of configuration, it can only increase the duration of the lifetime parameter but not reduce it, e.g., to 0. A lifetime value of less than the current value will trigger a restart of the current value.
>
> That behavior on an anonymous can really be discussed. Think that anyone could send it, what change can we allow it to cause?

[RJ]  thought it is possible for intermediate 6LRs to generate DAO on
behalf of RUL without any direct trigger from the RUL. In this case,
the lifetime will be a lower non-zero value.

>
> >
> > 6. Section 9.1 ... "On the first Address Registration, illustrated in Figure 5 and
> > Figure 8" ... Figure 8 currently does not show first address registration.
> >
>
> Oups fig 8 it was repurposed, because it was too obvious. Fixed in github. The paragraph becomes
>
> "
>    On the first Address Registration, illustrated in Figure 5 for RPL
>    Non-Storing Mode, the Extended Duplicate Address exchange takes place
>    as prescribed by [RFC8505].  Any combination of the logical functions
>    of 6LR, Root and 6LBR might be collapsed in a single node.
> "
> > 7. Nits:
> > Sec 9.2.2 "that is sends in response" -> "that is sent in response"
> Actually I meant "it sends" : )
>
> > Sec 10: "unicast to each if the interested children" -> "unicast to each of the
> > interested children"
>
>
> > Sec 10: "Layer-2 acknoledgement" -> "Layer-2 acknowledgement"
>
> > Sec 11: " whereby the it is possible to validate" ->  "whereby it is possible to
> > validate"
> > Sec 12.4: "DAO-ACK and RCO" -> "DAO-ACK and DCO"
>
> > Appendix A: " Follows the RPI-6LoRH and then the IP-in-IP 6LoRH." -> Need to
> > be rephrased
>
> Wasn't that high poetry?
[RJ] Indeed it was and like any other high poetry, I couldn't
understand a thing! :-)

Changed to
>
>    The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
>    When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
>    precede it are also removed.
>
[RJ] Great, Thanks.