Hello Tom:
I agree nunicast is weird and I'm not inclined to use it.
About your proposed "6LN network": we do not have that language so far. We have
LLN but that does not imply 6LoWPAN ND, and RFC 8505 does not imply constrained
networks. It is a stateful AAD operation, it consumes less resour
Hello Gene:
The intention in the TID is to sequence the mobility of the target address
exposed in NS(EARO). NA (EARO) is supposed to respond unicast to the NS(EARO),
or be used as an asynchronous response to that NS. IOW, this broadcast NA about
target=self is new, and the fields have no specif
Hello Michael:
What if we start like:
"
3. Overview
This specification extends [RFC8505] and inherits from [RFC8928] to
provide a registration method - called subscription in this case -
for anycast and multicast address. [RFC8505] is agnostic to the
routing protocol in which the a
Hi Pascal,
The problem I am trying to solve is that currently Wi-SUN FAN is specifying
that once a node responds to a NA(EARO) (request to reregister) it ignores all
others for 5 minutes. This is to minimize flooding. The problem with that
approach is that it is not uncommon for a meter to exp
Oh!
Well, at least there's text for that. The next paragraph is about incrementing
the TID when resending, but not the way a real TID operates, quoting
"
In an unreliable environment, the multicast NA(EARO) message may
be resent in a fast sequence, in which case the TID must be
That sounds like it will work. Thanks for addressing our use case.
Gene Falendysz
Office:(864)718-6676 / Mobile: (864)723-1395
-Original Message-
From: Pascal Thubert (pthubert)
Sent: Friday, November 18, 2022 9:46 AM
To: Falendysz, Gene ; Pascal Thubert (pthubert)
; 6lo@ietf.org
Subje
Pascal Thubert (pthubert) wrote:
> What if we start like:
Good.
> " 3. Overview
>This specification extends [RFC8505] and inherits from [RFC8928] to
> provide a registration method - called subscription in this case - for
> anycast and multicast address. [RFC8505] is a
