Re: [Last-Call] Tsvart last call review of draft-ietf-6lo-multicast-registration-16

[Kyle Rose <[e-mail]>]

On Mon, Mar 11, 2024 at 11:19 AM Pascal Thubert <[e-mail]>
wrote:

> The original idea was to use the preferred parent *tree* (each node has
> one) for the multicast registration. So in normal operation there is no dup.
> When forwarding a multicast packet to the preferred parent tree fails, the
> text above allows to forward up to an alternate parent to ensure the packet
> goes up and can be flooded from the root down the rest of the DODAG.
> Arguably, this could create duplicates. e.g., if the preferred parent of
> this node gets the packet later from above, and can now talk again to this
> node. At this point, this node may get a second copy that it may forward
> down. It is a trade off between a risk distributing 2 copies vs a risk of
> having a major part of the DODAG not getting the packet at all.
> We can mention that the unreliable nature of the LLN makes the mast
> distribution unreliable and incurs the risk of duplication, and both issues
> need to be handled by the ULP. Is that what you are suggesting?
>

I think the above explanation of the steady-state behavior in a subsection
specific to multicast duplication is probably sufficient. Again, that
behavior might be obvious to experts in this space, but it would help
others avoid ratholing on something that isn't as significant a concern as
it might appear at first to someone with only a naive understanding of what
is proposed.

## 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.
>
> The version of IPv6 ND (RFC 8505, see draft-ietf-6man-ipv6-over-wireless)
> we use in LLNs does not leverage MLD. LLNs live with no MLD at all. Wi-Sun
> came with the need to get a better mcast support than MPL but would not
> implement MLD. This draft is the result of the work with them to optimize a
> LLN solution that already has RFCs 8505 and RFC 6550.
>

Tail-wagging-the-dog aside, my objections are mostly in the category of
"this seems inelegant" or "this seems unnecessarily different". Based on
8550, it sounds like this has been discussed ad nauseam and has already
achieved IETF consensus, so we don't need to relitigate it.

## 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.
>
> I'd argue that we are more explicit  about something that is already
> there, which is not making things worse, just more visible.
> One use case is an external source that injects the same address at
> multiple edge points, think, like, multi-homing in cloud). Which is not
> really multiple owner devices, but multiple interfaces on that device with
> the same address or multiple routes to that device. From the perspective of
> routing, we want to retain all the routes as opposed to just one?  Quote
> from the draft "An external destination (address or prefix) that may be
> injected as a RPL target from multiple border routers should be injected as
> anycast in RPL to enable load balancing". Advertising anycast as unicast
> the way we did before has its own side effects like possible flapping and
> did not have this capability.
>

I guess my question is really "why is multi-homing with a single address
desirable within an LLN, vs. other solutions that involve multiple
addresses and unambiguous or explicitly-configured routing?" It sounds like
the answer to this question invokes justifications involving routing
topology autoconfiguration within data centers. Lacking any direct
experience with the issues that motivate RIFT, I don't have a strong
opinion about it, and will leave it to RTG to decide the desirability of
this kind of pattern.

Thanks,
Kyle