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

[Pascal Thubert <[e-mail]>]

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 
> <[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