Re: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

[Rahul Jadhav <[e-mail]>]

Thanks for the response.

PFA my comments inline.

One more comment:  Section 5.2 says "non-storing Mode DAO to the Root may
contain multicast addresses in the RPL Target Option (RTO),"
An RTO cannot contain multiple addresses. Is it meant to say that multiple
RTOs may contain the different multicast addresses within the same DAO?

Thanks,
Rahul

On Wed, 8 Jun 2022 at 21:23, Pascal Thubert (pthubert) <pthubert=
[e-mail]> wrote:

> Hello Rahul
>
>
>
> Many thanks for your review!!
>
>
>
> Please see below:
>
>
>
> >  storing MOP handling: Even though the draft mentions that storing MOP
> should also work, the details seem to be missing (or it might be an
> oversight on my side).
>
>
>
> This is effectively
> https://datatracker.ietf.org/doc/html/rfc6550#section-12; this is
> indicated in the introduction and the overview. Effectively the TID must be
> ignored and the RFC misses text to that effect. This oversight (of ours at
> the time of RFC 6550) is corrected in the cases covered by the draft though
> we do not specifically update RFC 6550 to clarify that it also applies to
> MOP3. I’m adding text to be more specific on this:
>
>
>
> “
>
>    Though it was implicit in [RFC6550], this specification
>
>    clarifies that the freshness comparison based on the TID field is
> ignored
>
>    for RPL multicast operations. A RPL router maintains a remaining Path
>
>    Lifetime for each DAO that it receives for a multicast target, and
> sends it
>
>    own DAO for that target with the longest remaining lifetime across its
>
>    listening children.
>
> “
>
> Same for MOP 5
>
> “
>
>    As with MOP 3, the freshness comparison based on the TID field is
> ignored
>
>    for RPL MOP 5 multicast operations. The Root maintains a remaining Path
>
>    Lifetime for each DAO that it receives, and the 6LRs generate the DAO
> for
>
>    multicast addresses with the longest remaining lifetime across its
> registered
>
>    6LNs.
>
> “
>
>
>
> There is no route cleanup. There’s history of async clean up to do damage
> in race conditions. It’s hard enough for unicast, we do not attempt for
> multicast or anycast. So we leave it to lifetime elapsing.
>

Ok. That's what I assumed but wanted an explicit response.
Multicast/Anycast proactive cleanup is not possible to handle and lifetime
elapsing sounds fine to me. Should this be explicitly stated?



>
>
> > This opens up a lot of possibilities and I am not sure how the hybrid
> mode would work.
>
>
>
> Well, the  announced MOP is 1 but there’s storing mode DAO for multicast
> happening as well. Some out of band control would allow this to happen. We
> can remove that text if people think it is open ended…
>

I feel it is open-ended.


>
>
> > "MUST retain a routing table entry for each children", is a change from
> the default behaviour and thus has impact on backward compatibility which
> is not called out in the corresponding backward compatibility section.
>
>
>
> This is described in section 12 of RFC 6550 for MOP 3:
>
> “
>
>
>
>    As a result, multicast routing states are installed in each router on
>
>    the way from the listeners to the DODAG root, enabling the root to
>
>    copy a multicast packet to all its children routers that had issued a
>
>    DAO message including a Target option for that multicast group.
>
>
>
> “
>
>
>
> > What is the preferred mode for sending syntax fixes since I dont see
> this draft on github?
>
>
>
> The git is https://github.com/pthubert/6lo-multicast-registration; you’re
> very welcome to submit a pull request. I pushed the changes above in
> https://github.com/pthubert/6lo-multicast-registration/commit/02f5b9144f39f54e76ee2c8b480703449450ddf3
>

I have raised a PR to your repo here
<https://github.com/pthubert/6lo-multicast-registration/pull/1>.



> I suggest to move it to the ROLL git when we transfer focus to ROLL?
>
>
>
> Many thanks again
>

MAny Thanks

>
>
> Pascal
>
>
>
>
>
>
>
> *From:* Roll <[e-mail]> *On Behalf Of *Rahul Jadhav
> *Sent:* vendredi 3 juin 2022 17:16
> *To:* lo <[e-mail]>; Routing Over Low power and Lossy networks <
> [e-mail]>
> *Subject:* [Roll] draft-ietf-6lo-multicast-registration: route cleanups
> and storing MOP handling
>
>
>
> Hello Pascal, Authors,
>
>
>
> Thank you for this work. We had discussions before where the ability to
> register anycast/multicast addresses for 6LN nodes spanning RPL (or even
> non-RPL) network was missing. This work fulfills that requirement.
>
>
>
> Following is my review of the draft:
>
> 1. storing MOP handling: Even though the draft mentions that storing MOP
> should also work, the details seem to be missing (or it might be an
> oversight on my side). Consider following instances (for storing MOP):
>
>    a. in the case where multiple 6LNs subscribe to the same multicast
> address in the same DODAG, how will the intermediate 6LR handle this
> situation? Is it expected that the 6LR maintains state for all DAOs? Note
> that the DAOs may come from different paths when the parent switching
> happens and thus bloat the state. The only new thing added in the context
> is the 'M' flag in the RTO. The path-sequence, TID seems to be getting
> mandatorily ignored as per the text.
>
>   b. How would the route cleanup happen for multicast/anycast addresses?
>
>
>
> From non-storing mode perspective, I realize that it will be much easier
> handling since the DAO from the 6LR is directly targeted to the root and
> thus the root would be able to handle all the complexity.
>
> But the text seem to be loosely specified in the context of storing mode.
> For e.g., consider section 5.1 which talks about storing MOP handling... it
> states,
>
>  "Though it is preferred to build separate RPL Instances,
>
>    one in MOP 1 and one in MOP 3, this specification allows to hybrid
>    the Storing Mode for multicast and Non-Storing Mode for unicast in
>    the same RPL Instance, more in Section 10."
>
> This opens up a lot of possibilities and I am not sure how the hybrid mode
> would work.
>
>
>
> I see text in Section 5.3 that roughly handles some part by stating,
>
> "Like the 6LR, a RPL router in Storing Mode propagates the route to
>
>    its parent(s) in DAO messages once and only once for each address,
>    but it MUST retain a routing table entry for each of the children
>    that advertised the address."
>
> "MUST retain a routing table entry for each children", is a change from
> the default behaviour and thus has impact on backward compatibility which
> is not called out in the corresponding backward compatibility section.
>
>
>
> What is the preferred mode for sending syntax fixes since I dont see this
> draft on github?
>
>
>
> Again, thanks for this work.
>
>
>
> Best Regards,
>
> Rahul
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>