[Roll] some comments / questions on dao-projection

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 24 December 2016 17:02 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323F21295BB for <roll@ietfa.amsl.com>; Sat, 24 Dec 2016 09:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIen4mssoOKG for <roll@ietfa.amsl.com>; Sat, 24 Dec 2016 09:02:24 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4585B1293F0 for <roll@ietf.org>; Sat, 24 Dec 2016 09:02:24 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D6AC3E1EF for <roll@ietf.org>; Sat, 24 Dec 2016 12:20:48 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 02A8C63770 for <roll@ietf.org>; Sat, 24 Dec 2016 12:02:23 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roll <roll@ietf.org>
In-Reply-To: <c0985e7e40220d98906818db3674a8cd@xs4all.nl>
References: <c0985e7e40220d98906818db3674a8cd@xs4all.nl>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 24 Dec 2016 12:02:22 -0500
Message-ID: <18041.1482598942@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/oqHJBf0hkb5eFxK16nyZTlbsH-M>
Subject: [Roll] some comments / questions on dao-projection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Dec 2016 17:02:26 -0000

Hi, I had intended to finish this as part of the adoption call, having
previously read the document, but was late.  These comments are probably
more useful now anyway.  I can open tickets as appropriate if chairs direct.

Let me leave editorial comments to the end of this email.

1) Didn't we have an errata about default lifetime units when there was no
   configuration option?

No, we didn't.  I wonder if this plagues us everywhere, that 6550 should
have specified a default Lifetime units in the absense of a Configuration
option.


2) RFC6551 reference:

>   or the RPL routing extensions specified in Routing for Path
>   Calculation in LLNs [RFC6551].  Based on that information, the root

huh? the title of 6551 is: Routing Metrics Used for Path Calculation in
                           Low-Power and Lossy Networks

so, what exactly did you mean here?

3) does dao-lifetime eclipse need for no path dao?

4) resource calculations

"but how the root figures the amount of
   resources that are available is out of scope."

I disagree. I would like some mechanism to be in scope.
  And you suggest NMS and 6551 later on... which seems to make it in scope.
  I'm not sure how 6551 can be used here.

5) section 4 needs subsections! Too many concepts in one heading.

6) On the use of a new MOP.

Are we sure that we need a new MOP?  Could we use Non-Storing MOP, with
some indication of which nodes speak DAO-Projection?  Could that work?

Or do you really want to force a forklift upgrade here?
Why does the entire network need to be aware of this new mode?

7) page 8 is too dense!

8) I just didn't understand the english here.
   I think that "last node" needs a better term.  Maybe colour
   the nodes or otherwise mark them and use those terms?

   The last node in the segment may have another information to reach
   the target(s), such as a connected route or an already installed
   projected route.  If it does not have such a route then the node

9) running out of resources:

it seems that it ought to be said that the new node might not be one that the
last node had previously talked to.  There is the issue of both routing
storage (from storing mode), but also neighbor cache resources.

10) more hard to understand statements...

>   For the targets that could be located, last node in the segment
>   generates a DAO to its loose predecessor in the segment as indicated
>   in the list of Via Information options.

woe!  What?

11) create new section on route cleanup

>   A NULL lifetime in the Via Information option along the segment is
>   used to clean up the state.

needs new 4.x section on cleanup.

12) move / replicate diagrams into this section, and use numbered diagrams

>   In the example below, say that there is a lot of traffic to nodes 55

new section, move diagram here.

make figure 5 and 6 more like figure 3, numbered, etc.

13) Q: retransmission timers, etc. appropriate for these projected DAO messages?
    How do we handle packet loss?

14) Security Considerations will need to be written.

The security threats documents details very specific threats, and indicating
if this protocol changes things is important.  Also, some consideration
SHOULD be given to when A=1.  Are the affects of the new flow of control messages?

So for instance Security Considerations should probably consider how
projected DAO messages could be abused by
  a) rogue nodes
  b) via replay of messages
  c) if use of projected DAO messages could in fact deal with any threats?


======== START of EDITORIAL comments

Change:
   Additionally, RPL storing mode is optimized or Point-to-Multipoint
   (P2MP), root to leaves and Multipoint-to-Point (MP2P) leaves to root
   operations, whereby routes are always installed along the RPL DODAG.

To:
   Additionally, RPL storing mode is optimized for Point-to-Multipoint
   (P2MP), (..root to leaves and Multipoint-to-Point (MP2P) leaves to root
   operations), whereby routes are always installed along the RPL DODAG.

the part () is worded too poorly for me to parse.  Can you fix this?

   Transversal Peer to Peer (P2P) routes in a RPL network will generally
   suffer from some stretch since routing between 2 peers always happens

What means "stretch" here?

section 2: NSM -- I think this is a new term?
        (it's not in RFC6550 or 7102. I'm all for this term)

section 3: I found the comments about factoring to be too soon.
        Some explanation of mechanism should preceed this part of the
        discussion.  Just let section 3 be about the formats/contents.

I suggest text like this:
  In NSM the TIO option is used in the DAO message to indicate the immediate
  parent of a given path.  The TIO applies to the Target options that
  immedially preceed it, and multiple TIOs may be present to indicate
  multiple routes.

  This specification...














--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-