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

[Michael Richardson <[e-mail]>]

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?

Why is Wi-SUN mentioned in relation to 802.15.4.
I understand that Wi-SUN is included, but I'm unclear why other 802.15.4
verticals couldn't use this specification?

   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

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"

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.

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"

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.

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?

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

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.
??

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.

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

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

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