Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

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) <pthubert@cisco.com> 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 <6lo-bounces@ietf.org <mailto:6lo-bounces@ietf.org>> On Behalf Of Dario Tedeschi
> Sent: lundi 11 octobre 2021 22:09
> To: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org <mailto:pthubert=40cisco.com@dmarc.ietf.org>>
> Cc: 6lo@ietf.org <mailto:6lo@ietf.org>
> 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) <pthubert=40cisco.com@dmarc.ietf.org <mailto:pthubert=40cisco.com@dmarc.ietf.org>> 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: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> 
> Sent: vendredi 8 octobre 2021 16:45
> To: Pascal Thubert (pthubert) <pthubert@cisco.com <mailto:pthubert@cisco.com>>
> 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
> 6lo@ietf.org <mailto:6lo@ietf.org>
> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>