Re: [Roll] [6lo] Review of draft-ietf-6lo-multicast-registration-04

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael

Many thanks for your kind review! Please see the new 05 and the diffs at https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt

Let's see below:

> I have read draft-ietf-6lo-multicast-registration-04.
> I have perhaps too many relationships with various ROLL documents to
> honestly say if the document is comprehensible to outsiders.  I will say
> that the Introduction,
>   https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-
> 04.html#name-introduction-2
> is similar to the intros of other documents, and Pascal has really refined
> the history of RPL and ND and EARO to a very precise and to the point "how
> did we get here" description.  It's too bad we can just #include <6lo-
> history> and get this text.
> 
> In section 3, it says:
>    _This specification inherits from [RFC6550], [RFC8505], and [RFC8505]_
> 
> maybe one of the RFC8505 is meant to be 6775?  or 7400?

9010 : )

> 
> Why is Wi-SUN mentioned in relation to 802.15.4.

Wi-SUN alliance is the group that asks for this spec. It's worded as "such as" though. 

> I understand that Wi-SUN is included, but I'm unclear why other 802.15.4
> verticals couldn't use this specification?

Added "and 6TiSCH" to show there's more.

> 
>    Note the use of the term "subscribe": using the EARO registration
>    mechanism, a node registers the unicast addresses that it owns, but
>    subscribes to the multicast addresses that it listens to.
> 
> This point is pretty important, and maybe deserves it's own section?
> This section explains the new flags, which I like, but hasn't really named
> them yet.
> 
> I suggest inserting text like:
> 
>   This specification introduces two new flags, detailed in section FOO.
>   The _A_ flag for Anycast, and the _M_ flag for Multicast.  The existing
> _R_ flag
>   gets new behaviour.
> 
> before:
>   With this specification, the 6LNs can now subscribe to the multicast
>   addresses they listen to, using a new M flag in the EARO to signal that
> the
>   registration is for a multicast address. Multiple 6LN may subscribe to
> the
>   same multicast address to the same 6LR. Note the use of the term
> 

Added:

   This specification updates the EARO with two new flags, the A flag
   for Anycast, and the M flag for Multicast, as detailed in
   Section 6.1.  


> About:
>   It is also possible to leverage this specification between the 6LN and
> the
>   6LR for the registration of unicast, anycast and multicast IPv6
> addresses
>   in networks that are not necessarily LLNs, and/or where the routing
>   protocol between the 6LR and above is not necessarily RPL. In that case,
>   the distribution of packets between the 6LR and the 6LNs may effectively
>   rely on a broadcast or multicast support at the lower layer.
> 
> I think that the utility of doing this is for equipment which either does
> not have MLD, doesn't implement properly (common), or for which there are
> interoperability issues with MLD.  I think that in some high density/DC
> scenarios the ToR switch is often at it's limit TCAM entries, and when one
> attempts to turn on IPv6 and MLD for IPv6, that one runs out.  Being able
> to emulate multicast in such a situation would be a win, I think.
> But, in order for it to be a win, then I think that some document has to
> explain how to do things, and not just say, "support at the lower layer"

Changed to

        In that case, the distribution of packets between
   the 6LR and the 6LNs may effectively rely on a broadcast or multicast
   support at the lower layer, e.g., using this specification as a
   replacement to MLD in an Ethernet bridged domain and still using
   either plain MAC-layer broadcast or snooping this protocol to control
   the flooding.  It may also rely on overlay services to optimize the
   impact of Broadcast, Unknown and Multicast (BUM) over a fabric, e.g.
   registering with [I-D.thubert-bess-secure-evpn-mac-signaling] and
   forwarding with [I-D.ietf-bess-evpn-optimized-ir].
> 
> section 4: isn't the A flag also new? (I didn't check RFC7400, I am going
> on what section 3 said).  Or maybe the M/A are added to the RTO.
> Should we have two flags called M?  Well, section 12 cleared it all up for
> me.

There already was an A and the new flag in 7400 covers both multi and anycast.
I agree that the resulting M and A in 7400 can lead to errors. Let's rename to X for X in (uni, multi and any) XCasts 

> 
> section 5.1: updating MOP 3.  Not convinced we can do this, I guess I'll
> know when I read section 9.
> 
>    5.2. New Non-Storing Multicast MOP
>    This specification adds a "Non-Storing Mode of Operation with multicast
> support"
> 
> I feel that there needs to be an adjective inserted here.
>     "Non-Storing Mode of Operation with XXXX multicast support"

What about 
   Non-Storing Mode of Operation with ingress replication multicast support

> 
> maybe XXXX is _emulated_, or _encapsulated_ or _registered_ or ???
> 
> I found section 5.3 difficult to read.
> There seem too many uncertainties in the text/protocol.

OK, I did some clarification but that's vague; We'll talk about that when the doc is transferred to ROLL, maybe?

> 
> 6.2:
>         Section 4 of [RFC6775] provides the same format for DAR and DAC
> messages *by
>         but* the status field is only used in DAC
> 
> Some wording problem here. Maybe *by* is superfluous?

That's a oups, yes.


> 
> Section 8 seems to be only suggesting a new way to do security.
> Maybe it could be more prescriptive?
> 

The beginning is non prescriptive because it describes the art. The end is full of uppercases. Not sure what to do. Help!

> section 9:
>         When encapsulating an packet with an IPv4 multicast Destination
>         Address, it MUST use **form a** multicast address and use the
> appropriate
>         scope, Realm-Local or Admin-Local.
> 
> Maybe it should be:
>         When encapsulating an packet with an IPv4 multicast Destination
>         Address, it MUST use **a form** multicast address and use the
> appropriate
>         scope, Realm-Local or Admin-Local.
> ??
> 

            When encapsulating an packet with an IPv4 multicast
   Destination Address, it MUST use a multicast address with the
   appropriate scope, Realm-Local or Admin-Local.


> Section 9: I guess that for brownfield, nodes that do not know the new MOP
>         will join that DODAG as leaves only. They aren't RULs.
>         That other DODAG would have a different PIO advertised, I think?
> 
> I think that the brownfield situation needs more thought, and maybe we
> need capex here.  I suggest the title be changed to "Brownfield Deployment
> Considrations", or maybe "Mixed support Deployment Considerations" if
> "brown field" is not considered a well enough known term.

Point taken, for ROLL to discuss

> 
> 12.2 why is the I field repeated in this table, if it was defined in 8505?

Because we failed to do in in RFC 8505. We created a I registry but did not book the bits in that registry. Accident may happen.


> The need for an rfc6550bis seems even more important after all these
> patches.

Yep, Internet Standard?

Take care,

Pascal

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
> [
>