Re: [Roll] Closure text for ticket #89

"Pascal Thubert (pthubert)" <> Fri, 13 April 2012 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2B1F21F87F8 for <>; Fri, 13 Apr 2012 06:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.164
X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JPmQIGrFiGAd for <>; Fri, 13 Apr 2012 06:54:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A52A821F87F7 for <>; Fri, 13 Apr 2012 06:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3798; q=dns/txt; s=iport; t=1334325259; x=1335534859; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MCmPXlMPkZQsw26yZWpqMwJVgRG+uK1ADbn21oUQsM4=; b=L6IZe0xsq5kakWrckG170E9qPugVv8e6DrXPlaD/+L8TDWYKl1fr4Mq0 JIy/rLulqvrp1GlmOJy3WCCUT4bUd5KiV5THzTGI/h5oApBQAAZk9M6Qh 9W5im1XY2XzIAsIx09352Baz1WkozTFrChHO8rcHRSCqVqtsChxYRq60l o=;
X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="135088027"
Received: from ([]) by with ESMTP; 13 Apr 2012 13:54:18 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3DDsInh000613; Fri, 13 Apr 2012 13:54:18 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 15:54:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Apr 2012 15:53:33 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Roll] Closure text for ticket #89
Thread-Index: Ac0ZetQ9dYenKTPgSKy93R/6yjrDBAAAfaKQ
References: <> <>
From: "Pascal Thubert (pthubert)" <>
To: Mukul Goyal <>, JP Vasseur <>
X-OriginalArrivalTime: 13 Apr 2012 13:54:18.0755 (UTC) FILETIME=[EBDF9530:01CD197C]
Cc: roll <>
Subject: Re: [Roll] Closure text for ticket #89
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2012 13:54:21 -0000

Perfect : )


-----Original Message-----
From: [] On Behalf Of
Mukul Goyal
Sent: vendredi 13 avril 2012 15:39
To: JP Vasseur
Cc: roll
Subject: [Roll] Closure text for ticket #89

#89: Spec is limited to single interface intermediate routers

 The spec does not allow for routers with multiple interfaces. It
expects  that an address is usable downwards and upwards.

Add the following text to the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to
the routers with IPv6 addresses that are reachable in both forward and
backward directions, which it quite typical in usual LLN routers with a
single radio"


 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and
backward directions."
 This is written with the vision that the router has a single interface
and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which
case that clause does not fly.

 All I mean is that the accumulated route MUST NOT have an address that
cannot be accessed in one of the directions. If the address cannot be
accessed in the backward direction, then the DRO would not be able to
travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its
proposed resolution. Nothing wrong with having limitations, yet I think
we must have specific text to indicate that the spec so far is limited
to devices with a single interface. When we make the Standard Track
version, I expect we'll have to go beyond that limitation. The drawback
is for experimental  implementations that may not be interoperable with
the final solution.

 [Mukul3] Could you please explain how does the requirement regarding
addresses to be accessible in both forward and backward directions
limits P2P-RPL to only single interface devices? I think this
requirement means that P2P-RPL cannot be used across link layers. Is
that what you mean? I think allowing operation across link layers would
require P2P-RDO to accumulate additional information (backward address
to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you
have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same
subnet wont be accessible in both forward and backward directions?

I propose the following text to be placed inside the Applicability

"The participation in a P2P-RPL route discovery is currently limited to
the routers with IPv6 addresses that are reachable in both incoming and
outgoing directions, which it quite typical in usual LLN routers with a
single radio"

Can we close this ticket?


I'd prefer to use upward and downward which are the terms that RPL
traditionally uses.... 

Is that OK with you? Otherwise yes, this text addresses my issue.

Should we use forward and backward terms? I already define them in the

Yes, that would be perfect

Roll mailing list