Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Martin Heusse <> Tue, 22 May 2012 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62E4B21F85C4 for <>; Tue, 22 May 2012 07:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4AtnTC9tInXy for <>; Tue, 22 May 2012 07:38:59 -0700 (PDT)
Received: from ( [IPv6:2001:660:5301:6::5]) by (Postfix) with ESMTP id AD26121F8539 for <>; Tue, 22 May 2012 07:38:58 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q4MEV0IJ004848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 22 May 2012 16:31:00 +0200
Received: from ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q4MEiUs7021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Tue, 22 May 2012 16:44:30 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Apple Message framework v1278)
From: Martin Heusse <>
In-Reply-To: <>
Date: Tue, 22 May 2012 16:40:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: roll WG <>
X-Mailer: Apple Mail (2.1278)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 ( []); Tue, 22 May 2012 16:31:00 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information
X-MailScanner-ID: q4MEV0IJ004848
X-IMAG-MailScanner: Found to be clean
MailScanner-NULL-Check: 1338301863.50381@DaTMXIR0RJBCtm6F6LgqLA
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
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: Tue, 22 May 2012 14:38:59 -0000


you wrote:

> How often do you think that ISIS LSA should be refreshed ?
> Or OSPF opaque LSA for TE extensions be flooded ?
--> "It depends"?
I am not saying that we would need to mention in the (general) RFC when, or at which rate,
- global repairs should take place or;
- DAO should be sent out on a regular basis…
(Although this could perfectly appear in applicability, isn't it?)

My point was that the DAO mechanisms are not so clearly defined... Which may be fine: then Mukul is right and if you really need to reach everyone, then P2P RPL is there...
Right now, there can be a problem with DAOs
- if they are lost along the way (not unlikely if not using DAO-ACKs **even with L2 ACKs**, still possible otherwise) 
- if a sub-dodag moves... all routes are broken, and we don't really know how to re-establish them (although DTSN could help here, although it's a little vague)
- if an inconsistency is detected on a downward route, you'd have to ask everyone to re-send DAOs (Pascal's DAO requests would have helped of course -- this shows up on the list every now and then).

--> for opaque LSA, the information in the packet does not matter, but the flooding mechanism is robust and well defined. For DAOs, we know how the packet must look like...

> Or BFD packets ? 
> Or PCEP Keepalive when turned on ?
> Very seriously … these questions apply to all protocols … and you cannot expect the specifications to give you
> hard coded values (but default whenever possible); these are topology and application specific, don't you think ?
Yes, I agree!