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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 08 July 2015 17:00 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 E83211A1A5B for <roll@ietfa.amsl.com>; Wed, 8 Jul 2015 10:00:11 -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 LPd9SOOw1Du5 for <roll@ietfa.amsl.com>; Wed, 8 Jul 2015 10:00:10 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF17D1A1A4F for <roll@ietf.org>; Wed, 8 Jul 2015 10:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6878; q=dns/txt; s=iport; t=1436374809; x=1437584409; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uuFLtGPo4P05+rwheEIkORngG9kQKYfmpaOr8xJB7KA=; b=TA0vCihjAN/j1AMcf/H12zTqoQNkvKGmWbOEw9UfbKrFfHXKeNK4qYYp GCH7dgYB7GBfI2m5WHIpH+OKL9t+6egXy36B7Y/i7Rp6l5j7pwAV0HHf6 U1VfgChRl38K6y4bVJGFBuIDL/0SjNFfikeoCiaufMKz8h8FOrg6t1FeI w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DrAwDuVZ1V/5ldJa1cgxKBNAa9SQmEMoM0AoFbOBQBAQEBAQEBgQqEIwEBAQMBJxNEBwQCAQgRBAEBCxQJBzIUCQgCBBMIiB4IzX0BAQEBAQEBAQEBAQEBAQEBAQEBGYtLhFUGMgIEgxGBFAWMI4gAAYt+gTqHJ4whg18mggkfgVNvgUeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="9974851"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2015 17:00:08 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t68H084P028842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Wed, 8 Jul 2015 17:00:08 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.136]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 12:00:08 -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/iC9hJ3R0MyA
Date: Wed, 08 Jul 2015 17:00:08 +0000
Deferred-Delivery: Wed, 8 Jul 2015 16:59:04 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD849F08EFE@xmb-rcd-x01.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: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.22.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/7kIKmw29xExWScUBSbtD8dSEpH0>
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: Wed, 08 Jul 2015 17:00:12 -0000

Hello Michael

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

<PT> That is correct, as shown in fig 2, but I agree we need to clarify


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


<PT> The root indicates the sequence of next hop address. These are the addresses that are available on the interface of the child that connects to the parent. The node uses that address as source of its own DAO, which indicates it on which interface to send the DAO.



> 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?

PT> That is correct, assuming that this is an alternate to 
"
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.
"

PT > Your other points well taken, I'll talk to James and we'll fix the draft.

All the best

Pascal


Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: samedi 4 juillet 2015 15:34
> To: roll@ietf.org
> Subject: [Roll] some comments on draft-thubert-dao-projection-00.txt
> 
> 
> <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>, Sandelman Software
> Works  -= IPv6 IoT consulting =-
> 
>