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

[Pascal Thubert <[e-mail]>]

Hello Kyle:

Many thanks for your review!  Please see below;

Le 05/03/2024 à 22:23, Kyle Rose via Datatracker a écrit :
> Reviewer: Kyle Rose Review result: On the Right Track 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 
> [e-mail] 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. 
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?
proposed text:
"
   Note that due to
    the unreliable propagation of packets in the LLN, it cannot be 
guaranteed that
    any given packet is delivered once and only once. If a breakage 
happens along
    the preferred parent tree that is normally used for multicast 
forwarding,
    the packet going up may be rerouted to an alternate parent, leading 
to potential
    failures and duplications, whereas a packet going down will not be 
delivered
    in the subtree. It is up to the ULP to cope with both situations.
"

> ## 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.
> ## 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.
> 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?
RFC 8505 and its update in this spec are not limited to LLNs. The need 
for anycast is for instance showing in RIFT, see around 
https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift#section-6.8.4.3. 
ideally we would publish this in time to update RIFT.
6LoWPAN and RFC 8505 may be used in IIoT, which leverages hardware 
redundancy for reliability and safety purposes. ISA100.11a uses the IP 
address as device ID, also meaning that you can replace a device by 
another, but you need to configure the same IP address in both.
For the RPL side, the most common need I'm aware of is the one in the 
quote above. Say you have a RPL Unaware Leaf 
(https://datatracker.ietf.org/doc/html/rfc9010#section-9.2.1)  such as a 
domotics controller that wishes some redundancy in the LLN for a better 
availability. It is not really aware that there is routing above, and it 
cannot control the injection sequence (TID). As RPL only retains the 
most recent one, the behavior in the network is not well controlled and 
only what RPL sees as freshest is conserved. This is as opposed to a RAN 
that knows to set the same TID in the various route injections it makes. 
The ask to RPL is to ignore the TID because the most recent injection 
(bsed on TID) is not necessarily the only valid one.
Is the above along the lines you'd like to see in the draft?
> 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.
I'm not clear what anycast routing would mean in other environments. I 
guess you would tag the advertisements to recognize the various 
injection point or end points of the same address, retain/compute as 
many routes as address/tag tuples,  and route and individual packet to 
one of the tags, something like that. I'm not prone to have that 
discussion in this draft either.
In the context of RPL, we mostly want to ignore the TID and retain paths 
that look older when in fact they are just different. So it's a behavior 
in between the unicast and multicast ones, which is the main reason you 
find it in the same document as multicast. Selecting on next hop down 
kind of eliminates some alternate possibilities without the need for a 
tag that identifies the end point.

> ## 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. 
Dan's review seems to support that.

> # 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". 
Done

> * 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. 
Added in the introduction

I pushed my proposed resolution to

github.com

Kyle's review · pthubert/6lo-multicast-registration@eb5d57f 
<about:blank?compose#>

Contribute to pthubert/6lo-multicast-registration development by 
creating an account on GitHub.

🔗 
https://github.com/pthubert/6lo-multicast-registration/commit/eb5d57fa4c52edf1ca42b121cd22c42e42857635#diff-ad315e0600ca3c4a9292625c4a0cd79e0518579351f2ecc698e47dd7a285984f 
<https://github.com/pthubert/6lo-multicast-registration/commit/eb5d57fa4c52edf1ca42b121cd22c42e42857635#diff-ad315e0600ca3c4a9292625c4a0cd79e0518579351f2ecc698e47dd7a285984f> 


  Please let me know your thoughts, and again many thanks;

Pascal