Looks good.
I believe all my concerns have been adequately addressed. Thank you.
Just one typo, I think:
Using configuration, is it also possible to control
needs to change to:
Using configuration, it is also possible to control
Regards
Dario
> On Oct 12, 2021, at 2:07 AM, Pascal Thubert (pthubert) <[email protected]>
> wrote:
>
> Hello Dario:
>
> The minor changes I made so far are visible from the repo at
> https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt
>
> <https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt&url2=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt>
>
> Please let me know if more is needed. I plan to publish near cutoff,
> hopefully with some more comments in.
>
> Keep safe;
>
> Pascal
>
>
> From: 6lo <[email protected] <mailto:[email protected]>> On Behalf Of
> Dario Tedeschi
> Sent: lundi 11 octobre 2021 22:09
> To: Pascal Thubert (pthubert) <[email protected]
> <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>
> Subject: Re: [6lo] New Version Notification for
> draft-thubert-6lo-multicast-registration-02.txt
>
> Thank you Pascal,
>
> The new draft looks good. I only have two concerns:
>
> ------
> It would be helpful if “RTO” was in the Glossary, since its full expansion is
> not seen anywhere.
>
> ------
> The behaviour of MPL is confusing, when used in conjunction with “Non-Storing
> Mode of Operation with multicast". If I understand correctly Section 5.2
> defines the new mop behaviour as requiring 6LRs to send RTOs for multicast
> registrations. Yet the two MPL variations given at the end of section 3
> describe the R bit controlling that behaviour.
>
> Given the two variations, it’s not clear how a root node (running MPL) would
> know when to flood a multicast. Does it base it’s decision on the current mop
> or wait for an RTO with multicast address. If it is the latter, how long does
> it wait for an RTO before deciding to a "flood all" scheme.
>
> It would be clearer if the MOP alone determined what a root must do in
> regards to MPL:
>
> MOP “new": Only flood for multicast groups registered through DAO+RTO
> MOP 1: Flood all multicasts of scope 3 or higher
>
> For MOP “new”, the R bit in the EARO instructs the 6LR to send a DAO+RTO to
> the root. However in MOP 1, the R bit can be ignored by a 6LR running MPL,
> because all multicasts are already flooded and “reachability service” is
> therefore implied.
>
> ------
>
> Regards
> Dario
>
>
>
> On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert)
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Dear all
>
> Based on the conversations on the ML this version of the draft incorporates:
>
> - anycast support in IPv6 ND and RPL
> - non storing mode multicast in RPL
> - alternate multicast operation (e.g., MPL)
> - IANA suggestions
> - proposed formats
> - deployment and backward compatibility considerations
>
> What's left is the detailed operations, to come soon.
>
> Enjoy the week end!
>
> Pascal
>
> -----Original Message-----
> From: [email protected] <mailto:[email protected]>
> <[email protected] <mailto:[email protected]>>
> Sent: vendredi 8 octobre 2021 16:45
> To: Pascal Thubert (pthubert) <[email protected] <mailto:[email protected]>>
> Subject: New Version Notification for
> draft-thubert-6lo-multicast-registration-02.txt
>
>
> A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
>
> Name: draft-thubert-6lo-multicast-registration
> Revision: 02
> Title: IPv6 Neighbor Discovery Multicast Address Registration
> Document date: 2021-10-08
> Group: Individual Submission
> Pages: 21
> URL:
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
>
> <https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt>
> Status:
> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
> <https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/>
> Html:
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
>
> <https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
>
> <https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02
> <https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02>
>
> Abstract:
> This document updates RFC 8505 to enable the address registration of
> IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
> (RPL) add a new Non-Storing multicast mode and support for anycast
> addresses. This document also extends RFC 9010 to enable the 6LR to
> inject the anycast and multicast addresses in RPL.
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> 6lo mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6lo
> <https://www.ietf.org/mailman/listinfo/6lo>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
