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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sat, 04 July 2015 20:28 UTC

Return-Path: <pthubert@cisco.com>
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 6525C1A005B for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GMgkCmDGHdoE for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 13:28:31 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567D11A0062 for <roll@ietf.org>; Sat, 4 Jul 2015 13:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5156; q=dns/txt; s=iport; t=1436041711; x=1437251311; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nvZ3nWM1V4UadBKlTF+LV1ti1QjBd0tvwhy8XzLe4uw=; b=FvHkGnIEA8bJ/PMwvDYiSDjvKpjJo8JU6qFBao6MNqO1qt4mvZuO7VQR mhamE9VvKxoLHxdb01tgxLT/aZeDTQq5I1RqVW5+1UxtAB9n3RPRho4dq PI1zTRnLJwoxhQ17WnlGSVtq+bg01YV0NGrXobUHOfuKmhzQJ8r6CZ3HI k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlBAAkQZhV/5BdJa1cgxJUYL1KCYFkCoJDgzQCgR04FAEBAQEBAQGBCoQkAQEDAQEBASRHEAsCAQhGJwslAgQTiCcIDcYXAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4RTCDICgxWBFAWMGTiEYIJkAYtngTqHJIwbg10mggkfgVNvgksBAQE
X-IronPort-AV: E=Sophos;i="5.15,407,1432598400"; d="scan'208";a="12649979"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2015 20:28:30 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t64KSUnn005156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Sat, 4 Jul 2015 20:28:30 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.112]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sat, 4 Jul 2015 15:28:29 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt
Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3s
Date: Sat, 4 Jul 2015 20:28:29 +0000
Message-ID: <F2C95F1F-7DF2-497E-AFF5-0711565F400C@cisco.com>
References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD849EF25A0@xmb-rcd-x01.cisco.com>, <10398.1436016852@sandelman.ca>
In-Reply-To: <10398.1436016852@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/yl6YlvVS3eGE8-tUN254kZa-dJU>
Subject: Re: [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 20:28:33 -0000

Fantastic Michael!

I'll answer in the list but many thanks already!

Pascal

> Le 4 juil. 2015 à 15:34, Michael Richardson <mcr+ietf@sandelman.ca> a écrit :
> 
> 
> <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 =-
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll