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

Hello Dario

Please see below;

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

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

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