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
[email protected] 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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
