Hi Pascal,
I think the 2nd and 4th cases can be merged, by allowing a root node to
automatically propagate the following multicast messages, using MPL:
* All scope 3 (Realm-Local) multicast messages it either originates or
receives on an MPL interface.
* All Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306) higher
than scope 3, where the network prefix (given in the mulitcast
destination address), matches the prefix of the DODAG ID (the RPL
network's subnet).
Automatic forwarding of the 2nd address type could be optional and
administratively configured.
If nodes are interested in other multicasts higher than scope 3, they
must explicitly inform the root by sending DAO messages with appropriate
Target Options.
---------
The 3rd case, I think, needs its own mop code (i.e. "Non-storing mode
with source-routed multicast").
For the 1st and 3rd cases, how do you envision multicasts propagating up
the DODAG (towards the root)? Would a node simply L2 unicast to its
preferred parent?
Regards
Dario
On 10/6/21 6:00 AM, Pascal Thubert (pthubert) wrote:
OK Dario, so we’d have 4 optional combinations:
unicast = mop 1 multicast = mop 3 (what the draft does today)
unicast = mop 1 multicast = MPL (that I believe the draft allows today
but should clarify); in that mode, not message to the Root, the root
floods all multicast messages with the idea that there’s always a
listener somewhere
unicast = mop 1 multicast = mop 1 (to be added) in that mode the 6LR
sends a DAO to the root for a multicast target, and the Root sends n
messages that are unicast source routed to the n 6LR that have
listeners, only the last address in the SRH is multicast
unicast = mop 1 multicast = MPL (that I believe the draft allows today
but should clarify); in that mode, in that mode the 6LR sends a DAO to
the root for a multicast target, and the root uses MPL only when
there’s known listeners
Do we describe them all? Should we consume RPL MOPs?
I suggested that AODV RPL reuses MOP 4 to leave room…
Pascal
*From:* Dario Tedeschi <[email protected]>
*Sent:* mercredi 6 octobre 2021 0:05
*To:* Pascal Thubert (pthubert) <[email protected]>
*Cc:* [email protected]
*Subject:* Re: [6lo] New Version Notification for
draft-thubert-6lo-unicast-lookup-01.txt
Hi Pascal
See my comment below.
On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
Hello Dario
Please see below;
Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email protected]>
<mailto:[email protected]>a écrit :
Hi Pascal,
Thank you for new draft. However I do have some
comments/questions.
What benefit does the ‘M’ bit provide over simply detecting a
multicast address in the Target Address field?
The IPv6 multicast address type is clearly defined in RFC 4291
(section 2.4)
<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>,
and the detection of such an address is trivial. Most (if not
all) Stacks have a simple function/macro to do that job and
many existing protocols already use this mechanism to
distinguish between unicast and multicast addresses. It seems
to me that a special bit to indicate multicast registration
would be redundant and require handling for 4 different cases,
2 of which would be errors:
* M = 1, Target = multicast addr
* M = 1, Target= unicast addr — ERROR
* M = 0, Target = multicast addr — ERROR
* M = 0, Target= unicast addr
True enough. Dario.
I’ve been pondering that too. On the one hand it seems cleaner to
announce the service that the 6LN expects. Otoh as you point out
it can be inferred from the address.
Another way of seeing this is that the error cases that you
indicate can be detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an
implementation could do something useful with that knowledge, other
than just discarding the message.
Then there’s anycast which is missing from both RPL and ND , which
cannot be distinguished by the look of the address and thus
requires a bit.
[DT] As for the anycast address, I suppose the question to ask is what
would a router do differently knowing such information? I suspect we
would have to define some new behavior along with the new bit.
Then there’s possibly the need of an IPv4 AF. All in all I tended
to favor having the bit but that’s really not a strong position,
happy to be convinced otherwise.
[DT] I presume you are talking of "IPv4-Compatible" and "IPv4-Mapped"
IPv6 addresses. If my presumption is correct, aren't these still
easily identifiable through their unique prefixes (::/96 and
::ffff/96, respectively)?
What do others think?
[DT] I have no strong opinion. The M bit just seemed redundant.
I also wonder about the requirement for non-storing RPL
networks to propagate multicast membership up the DODAG. My
understanding is that non-storing networks typically use MPL
(RFC 7731) <https://www.rfc-editor.org/rfc/rfc7731.html> which
does not need multicast memberships to be propagated
throughout the DODAG. It uses a flooding mechanism to forward
multicast datagrams, and does not unicast at L2. Could the new
document accommodate non-storing networks using MPL?
Sure;
Bottom line here is that for MPL all the multicast packets of
interest for the LLN are flooded throughout so I suspect that
there is no need for the 6LR to signal to the root.
[DT] Yes, that's my understanding as well.
If that’s the case then there’s nothing to standardize. All I
need to clarify is that the RPL behavior in the spec is the one
expected in a RPL domain that supports mop 3 otherwise what is
done is out of scope for this doc.
Do you see it otherwise?
[DT] I agree that only RPL mode 3 needs to be defined and other modes
are left out of scope.
I mean should the 6LR signal unicast to the root like for unicast
traffic when serving a RPL unaware leaf?
[DT] That certainly could be an optimization for non-storing mode so
that a border-router might know what multicast groups to forward from
outside the network. Unfortunately though there is no MOP that is
"Non-storing with multicast", although one could argue semantics and
simply use MOP 1.
[DT] If we were to opt for such behavior, 6LR nodes could simply add
RPL Target options to their DAO's, for the multicast groups they were
interested in (including those requested by leaf nodes).
If so wouldn’t it be expected that the Root makes n unicast to
all 6LRs that have listeners?
[DT] I'm not sure that would make sense when MPL is being used, but it
makes for an interesting alternative to MPL.
Should we describe that mode as well?
[DT] As an alternative to MPL? Sure.
Pascal
Regards
Dario
On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert)
<[email protected]
<mailto:[email protected]>> wrote:
Dear all:
This draft is a continuation of our work on RFC 8505,
8928, and 8929.
Comments welcome!
Pascal
-----Original Message-----
From: [email protected]
<mailto:[email protected]>
<[email protected] <mailto:[email protected]>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) <[email protected]
<mailto:[email protected]>>; Pascal Thubert (pthubert)
<[email protected] <mailto:[email protected]>>
Subject: New Version Notification for
draft-thubert-6lo-unicast-lookup-01.txt
A new version of I-D, draft-thubert-6lo-unicast-lookup-01.txt
has been successfully submitted by Pascal Thubert and
posted to the IETF repository.
Name:draft-thubert-6lo-unicast-lookup
Revision:01
Title:IPv6 Neighbor Discovery Unicast Lookup
Document date:2021-09-27
Group:Individual Submission
Pages:15
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt
Status:
https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/
Html:
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup
Diff:
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01
Abstract:
This document updates RFC 8505 in order to enable
unicast address
lookup from a 6LoWPAN Border Router acting as an Address
Registrar.
The IETF Secretariat
_______________________________________________
6lo mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
