Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 01 July 2009 09:07 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED35E3A6836 for <roll@core3.amsl.com>; Wed, 1 Jul 2009 02:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHxGQbxL5f25 for <roll@core3.amsl.com>; Wed, 1 Jul 2009 02:07:47 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 0490E28C3E3 for <roll@ietf.org>; Wed, 1 Jul 2009 02:07:46 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6197tcV013377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jul 2009 11:07:55 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6197tZt016827; Wed, 1 Jul 2009 11:07:55 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6197swm013090; Wed, 1 Jul 2009 11:07:54 +0200
Message-ID: <4A4B276A.9050107@gmail.com>
Date: Wed, 01 Jul 2009 11:07:54 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <20090628231501.3A1353A69E4@core3.amsl.com><F473346F-0DDC-4395-AD0E-9FBF5886F323@cisco.com> <A876246C13ACAF4AAA554580750C949C652D73@ausyd02.ap.bm.net> <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07B242FF@xmb-ams-337.emea.cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "Goindi, Manhar" <Manhar.Goindi@landisgyr.com>, ROLL WG <roll@ietf.org>
Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt Q2..4
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 01 Jul 2009 09:07:48 -0000

Pascal, as I wrote in private, I doubt the necessity of using the term
DAG and the associated DAG theory.  Picturing a DAG without arrows makes
doubtful sense (figure 1).  A link between siblings would use bidir
arrows, which would make for a 'loop', which we would try to avoid.

Besides, what would an arrow between two nodes mean actually: is it that
a node can send a packet to another node but not the other way around?
Makes little sense to have all edges so unidirectional.

Pascal Thubert (pthubert) a écrit :
[...]
> Q: Can siblings hear each other as it is not evident from Figure 2: 
> Example DAG?
> 
> R: Figure 1 represents connectivity and you can see siblings hearing
>  each other. Figure 2 represents the DAG so it does not include the 
> sibling links.

It should be clear whether or not the siblings can be linked together by
links and direct routes or not.  At some point  in the draft this is
explicitely forbidden (it says traffic from node a to node b deep in the
network must pass through the DAG root) - this is not good.

> Sibling links are bidirectional at the graph level though 
> unidirectional for a given packet.

I don't understand.  Do you mean that all links in the network (the DAG
is the network) are _uni_directional?

> We're missing the term to indicate the DAG+sibling_links.

We should call it a network.  A graph of paths hopefully loop-free, not
necessarily guaranteed.  But not a DAG.

> Gradient is fine when you talk about pointing to the preferred 
> parent, but this is also a term that was overloaded in the past. What
>  else?

A network.  A net.   A set of paths.  A topology and the associated 
paths.  A conceptual picture stemming from the set of routes present in 
each node's routing table.

I don't understand the word gradient in this context, throughout the
document.  Is it a derivative of something?  A differential of something?

Alex