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 tsv-art@xxxxxxxx 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: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.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.
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: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.In the case of a constrained node that already implements [RFC8505] for unicast reachability, it makes sense to extend to that 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.
## 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
Please let me know your thoughts, and again many thanks;
Pascal
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
