all good, then. Many thanks Kyle. Le 12/03/2024 à 15:31, Kyle Rose a écrit :
On Mon, Mar 11, 2024 at 11:19 AM Pascal Thubert <[email protected]> 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 tothat support to subscribethe > 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
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
