Last Call Review of draft-ietf-6lo-multicast-registration-16
review-ietf-6lo-multicast-registration-16-tsvart-lc-rose-2024-03-05-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

From my perspective as a member of the transport area review team, this
document is On The Right Track, a form of "Has Issues".

# Issues

## Duplication

Quoting RFC 6550:

> For a multicast packet sourced from inside the DODAG, the packet is
> passed to the preferred parents, and if that fails, then to the
> alternates in the DODAG.  The packet is also copied to all the
> registered children, except for the one that passed the packet.
> Finally, if there is a listener in the external infrastructure, then
> the DODAG root has to further propagate the packet into the external
> infrastructure.

This algorithm (for storing mode only) seems to admit the duplication of
packets (and consequent need to figure out how to de-dup) in a DAG via a node
sending to its parent and the non-source children, and then from that parent to
some of the same children via a different path. While I surmise that this has
been beaten to death in the working group, I am surprised to see no mention of
packet duplication considerations in this document. If this is adequately
covered elsewhere in the ecosystem, a reference would be helpful. This is a
core problem with multicast in domains with multiple paths.

## MLD vs ND

From the intro:

> In the case of a constrained node that already implements [RFC8505] for
> unicast reachability, it makes sense to extend to that support to subscribe
the > multicast addresses they listen to.

Does it? Or would it make sense to use the MLD wire image with unicast in a
manner analogous to how ND has been adapted to unicast for low-power
environments? I'm torn between two principles of engineering: least surprise
and minimizing effort. There are good arguments for each.

## Anycast

Originally, anycast was merely an artifact of undefined behaviors in global
routing technologies: since networks had no way of enforcing global address
uniqueness and had to do *something* with a packet in the presence of two
viable next hops (forward to one, forward to both, or drop/reject), some local
choice needed to be made. It turned out to be useful: see RFC 1546 and RFC 4786.

That said, there exists a not-completely-resolved tension between anycast
routing and address uniqueness enforced via mechanisms such as DAD. This
document increases this tension further, within the class of low-power
networks, by explicitly supporting multiple devices sharing an IP address on
what appears to a 6LR-oblivious node to be a single link.

One thing I'd like articulated is the set of identified use cases for
supporting this kind of addressing within low-power networks that are
presumably geographically highly-constrained. Is this a solution in search of a
problem?

I am not taking a position on whether or not anycast support is advisable,
primarily because this is not my area of expertise and so I do not understand
all the pros/cons involved, but I would like ADs of both TSV/WIT and INT to
take a close look at this.

## Updating a lot of documents

I agree with some other comments I've read that this set of updates has the
potential to create confusion in the ecosystem. It may be worth doing a -bis
pass to the entire ecosystem at some point in the not-too-distant future.

# Nits and other minor comments

* Please add DAO ("destination address object") to the glossary. This is
especially important because "D" in other similar abbreviations means
"duplicate".

* The paragraph in 6550 describing storing vs. non-storing routing modes would
provide useful context to readers not already steeped in the low-power/lossy
ecosystem. While obviously an implementer needs to have internalized these
foundational documents in their entirety, with care the documents can be made
more easily consumable by others not engaged in implementation.