Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Dario Tedeschi]

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  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) 
, 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 ::/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) 
 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) 
> wrote:


Dear all:

This draft is a continuation of our work on RFC 8505, 8928, and 8929.

Comments welcome!

Pascal

-Original Message-
From: internet-dra...@ietf.org  
mailto:internet-dra...@ietf.org>>

Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) >; Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>>
Subject: New Version Notification for 
draft-thubert-6lo-unicast-lookup-01.txt



A new version of 

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

Hello Dario

Please see below;


Le 5 oct. 2021 à 20:15, Dario Tedeschi  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), 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.

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.

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.

What do others think?

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)  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.

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?

I mean should the 6LR signal unicast to the root like for unicast traffic when 
serving a RPL unaware leaf?

 If so wouldn’t it be expected that the Root makes n unicast to all 6LRs that 
have listeners?

Should we describe that mode as well?

Pascal

Regards
Dario


On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
 wrote:

Dear all:

This draft is a continuation of our work on RFC 8505, 8928, and 8929.

Comments welcome!

Pascal

-Original Message-
From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) 
mailto:elevy...@cisco.com>>; Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>>
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
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Dario Tedeschi]

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) 
, 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


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) 
  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?
   
Regards
Dario


> On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) 
>  wrote:
> 
> Dear all:
> 
> This draft is a continuation of our work on RFC 8505, 8928, and 8929.
> 
> Comments welcome!
> 
> Pascal
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: lundi 27 septembre 2021 15:29
> To: Eric Levy- Abegnoli (elevyabe) ; Pascal Thubert 
> (pthubert) 
> 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
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo