[Roll] some comments on draft-thubert-dao-projection-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 04 July 2015 13:34 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027BE1ACDFA for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 06:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level:
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mL4aXl0YAD48 for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 06:34:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8060A1ACDEA for <roll@ietf.org>; Sat, 4 Jul 2015 06:34:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9EFD20012 for <roll@ietf.org>; Sat, 4 Jul 2015 09:49:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A3C1163AEC; Sat, 4 Jul 2015 09:34:12 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8890C63AE8 for <roll@ietf.org>; Sat, 4 Jul 2015 09:34:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <E045AECD98228444A58C61C200AE1BD849EF25A0@xmb-rcd-x01.cisco.com>
References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD849EF25A0@xmb-rcd-x01.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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-sha1; protocol="application/pgp-signature"
Date: Sat, 04 Jul 2015 09:34:12 -0400
Message-ID: <10398.1436016852@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/OhfR0bKhAMpI9fZEZP0AKioR1Ko>
Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Jul 2015 13:34:17 -0000

<Chair hat off>

Pascal, thank you for this document.
I especially appreciated your figure 2, the way that you numbered the nodes
with their gross rank as the the tens part.

You write on page 8:
   The root sends the DAO directly to the last node in the segment,
   which is expected to be able to route to the targets on its own.

It would be good to make it clear which direction one counts the "segment"
to know which one is last.  I don't like "segment" here, I think it's
a routing path...  Could you define segment if you think it's the most
natural term to use.
(There are also some articles like "the" missing in places, btw)

Then you write:
   The node strips the last Via Information option which corresponds to
   self, and uses it as source address for the DAO to the predecessor.

I think that what is described, to use the numbering in your example,
is that the root would send a message to 41, with a target=51,
list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31,
with a list of VIAs 11,22,31, etc.

It's the "then" above part that I *think* is a critical part of the protocol,
and is perhaps not clearly spelled out.  I wasn't entirely sure if I
read it correctly.

In the case where nodes have different downstream and upstream addresses
(because, for instance they had different radios), then there might be
some confusion and maybe both hops should be listed.  I recall I posted a
thread asking about that a year or so ago, but I don't recall what the
conclusion was.

But, then in the example on page 9, after sending these Via-DAOs to
45 and 46, it says:
   The root
   may then send a DAO to node 35 indicating targets 55 and 56 a Via
   segment (13, 24, 35) to fully optimize that path.

While the root had initially optimized the 45/46 out the routing
header with the first set of Via-DOAs (do you have a name for these messages?
Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24
in the list as well?

Alternatively, could the root have sent a single Via-DOA with destination
*35* to 24, with the route 13,24?   That would have resulted in a routing
header like:
       ROOT -> 35
since 13 and 24 should be able to reach 35 in a loose source route,
and 35 would know how to reach 55 and 56?

****

in section 3.1, the description of the VIA extension, you write:

Option Length:  Variable, depending on whether or not Parent Address
         is present.

But the only variability I saw in the extension was whether the child
address was 8 bytes or 16 bytes.  It seems that if you are going to
optimize this, you might as well also offer an option for the Child
Address to be 2 bytes (the last two bytes).

**** DAO

I don't fundamentally see a reason why DAO is used.  I guess it has the
right properties, but I think that a new message type could be defined
equally well (as well as a new ACK), even if it just replicates the exact DAO
structure.  It seems that the ACK is mandatory (K=1).

I would prefer that DAOs always flow towards the root, and DIOs away.
It would make analysis of what is going on easier.
These DAOs in some way flow towards a node with root-like storing-like
abilities, so I can see why it was elegant to reuse DAO for this.

**** incremental deployment

Use of a new MOP makes deployment of this a flag day.
I don't think that this is necessary, although some niggling doubt going back
to the mixed storing/non-storing discussion of 2011 remains...

I think that the DAOs that come from nodes that are able to act as Route
Projection nodes could indicate that capability, and furthermore, indicate
the number of routing slots they currently have free.

It would be advantageous perhaps to explicitely number the routing slots.
My initial thought is that would permit the subsequent DAOs to perhaps
include a count of how many times the Projected route was used: once the
DODAG root pushes traffic away from the root with these projected routes,
it can no longer count how much traffic is occuring, so it should get
reports "from the field" so that it can decide whether to keep those routes.

Explicitely numbering the routing slots could be problematic I agree,
but it would allow the DODAG to manage them directly rather than the implicit
process that the VIA option's Path Sequence is doing.

The Path Sequence processing needs an example, btw.


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