Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas]

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Thu, 02 April 2015 23:41 UTC

Return-Path: <jch@pps.univ-paris-diderot.fr>
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 9EB381A885C; Thu, 2 Apr 2015 16:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 6OcZdPCGPujD; Thu, 2 Apr 2015 16:41:47 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87ECF1A8855; Thu, 2 Apr 2015 16:41:47 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32Nff9X020767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 01:41:41 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t32Nfff0002820; Fri, 3 Apr 2015 01:41:41 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 127492A0C5D; Fri, 3 Apr 2015 01:41:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id x2lbq997fUqd; Fri, 3 Apr 2015 01:41:39 +0200 (CEST)
Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C10982A0C00; Fri, 3 Apr 2015 01:41:38 +0200 (CEST)
Date: Fri, 03 Apr 2015 01:41:53 +0200
Message-ID: <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD849D983BB@xmb-rcd-x01.cisco.com>
References: <CA+-pDCe1jMFaBJH5Ynss6Kf7mtxoLC8DYjz6N9d0Zu10o0WRuQ@mail.gmail.com> <CAGnRvuqzehpwW11XvhYQXZAjMiOvfexG0ygH4pnp6PyeD_Yq_Q@mail.gmail.com> <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <E045AECD98228444A58C61C200AE1BD849D983BB@xmb-rcd-x01.cisco.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST)
X-Miltered: at korolev with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 551DD3B5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Enveloppe: 551DD3B5.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Score: MSGID : 551DD3B5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 551DD3B5.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/v4506J-hD6G-IEVU41Zc0hdTA_U>
Cc: ROLL WG <roll@ietf.org>, "manet@ietf.org" <manet@ietf.org>
Subject: Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas]
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: <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: Thu, 02 Apr 2015 23:41:55 -0000

Thanks a lot for the lengthy explanation, Pascal, I feel that I understand
RPL somewhat better now.

>> My perhaps mistaken understanding is that RPL uses a more primitive
>> version of DSDV's feasibility condition

> That's all this discussion around that value L

Ah, I see.  Section 8.2.2.4.3.  (I'm not apologising for missing it -- it
is well hidden.)

Yes, that looks like DUAL-feasibility, but weakened so that loops of
diameter DAGMaxRankIncrease or less are allowed, right?  Why the
weakening?  Is that to compensate for the fact that you don't have
a mechanism to resolve blackholes in a timely manner?

> A node is allowed to join any DODAG Version that it has never been a
> prior member of without any restrictions, but if the node has been a
> prior member of the DODAG Version, then it must continue to observe
> the rule that it may not advertise a Rank higher than
> L+DAGMaxRankIncrease at any point in the life of the DODAG Version.

Yeah, that's pretty clear.  The same is true of Babel.

> One interesting difference with Babel is that RPL can route to all nodes
> with a single DODAG to a single root, using MOP 2.

Yes, I've noticed this mechanism before.  I think that's a smart mechanism
(I much prefer it to MOP 1), and I trust you've evaluated its performance
carefully, at least for some OF.  However, that's definitely not something
I'd ever consider adding to Babel -- I have a very strong desire to keep
the base protocol small, and to make sure that all extended variants can
interoperate as long as they implement the base protocol correctly.

You see -- once again, we're aiming at two different application spaces.
You're thinking of sensor networks, where it is reasonable to require that
all nodes in a given network implement MOP 2.  Babel is aimed at home and
hybrid networks (cash-starved networks with some meshy bits), which tend
to grow organically, with routers that never get reflashed, and therefore
contain different variants of the protocol.

> Another interesting difference is that if we have 2 roots, RPL
> partitions the network in 2 DODAGs.

Sorry if I'm being slow, but I don't see how that can be true.  If you have

   R1    R2
   /\
  /  \
 A    B

and there is instability in the network, so that simultaneously A switches
to B as parent, and B switches to R2 while its retraction ("poison") gets
lost, what prevents A from having B as parent while believing it's still in
R1's DODAG?

> Local repair is done by either poisoning or detaching, sections
> 8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

> Or 8.2.2.6.

That's just a variant of the above but advertising DIO instead of
a retraction, right?

> On the side, poisoning is really inheriting from IGRP,

It's been a long time since I looked at IGRP, but I seem to recall that it
avoids the issue I describe above by imposing a silent time after a metric
increase.  This causes temporary blackholes, of course, of up to 3 minutes
if memory serves.

> We voluntarily left out the trigger for a new iteration, because that
> can be largely outside the scope of the routing protocol,

I disagree with that, at least in the space for which Babel is aiming.

> All in all I do not buy the different spaces. RPL was explicitly
> designed for multiple spaces because, by design, we left out of RPL and
> into the OF everything that's specific.

Well, the space Babel aims for requires that implementations from different
vendors interoperate.  That requires putting a provably complete set of
"must implement" mechanisms in the base spec.  I don't believe that RPL
has that property.

> Do I get an invite?

Sure, I'll try to remember to send you a note when I next give a seminar.

-- Juliusz