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

Martin Heusse <Martin.Heusse@imag.fr> Tue, 22 May 2012 14:38 UTC

Return-Path: <Martin.Heusse@imag.fr>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E4B21F85C4 for <roll@ietfa.amsl.com>; Tue, 22 May 2012 07:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AtnTC9tInXy for <roll@ietfa.amsl.com>; Tue, 22 May 2012 07:38:59 -0700 (PDT)
Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id AD26121F8539 for <roll@ietf.org>; Tue, 22 May 2012 07:38:58 -0700 (PDT)
Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id q4MEV0IJ004848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <roll@ietf.org>; Tue, 22 May 2012 16:31:00 +0200
Received: from scilly.imag.fr (scilly.imag.fr [129.88.48.164]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q4MEiUs7021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <roll@ietf.org>; 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 <Martin.Heusse@imag.fr>
In-Reply-To: <B665C776-CF85-4EF6-8637-77D8F717D229@cisco.com>
Date: Tue, 22 May 2012 16:40:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C7FEA98-FEED-48B0-9FBA-1E9F7E8EDD11@imag.fr>
References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <B1B81482-0F7E-4BCE-BBA7-B21949E3C16C@cisco.com> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <ACBA7834-F4A1-4D9C-80D6-E76C793A6770@cisco.com> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <BE51553F-67BE-4652-A8E8-9654BF953A96@thomasclausen.org> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> <B665C776-CF85-4EF6-8637-77D8F717D229@cisco.com>
To: roll WG <roll@ietf.org>
X-Mailer: Apple Mail (2.1278)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); 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
X-IMAG-MailScanner-SpamCheck:
X-IMAG-MailScanner-From: martin.heusse@imag.fr
MailScanner-NULL-Check: 1338301863.50381@DaTMXIR0RJBCtm6F6LgqLA
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Tue, 22 May 2012 14:38:59 -0000

Jean-Philippe,

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! 

Martin