IETF Logo Mail Archive

Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01

Richard Kelsey <richard.kelsey@ember.com> Fri, 17 April 2009 17:55 UTC

Return-Path: <richard.kelsey@ember.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 56A403A6FA9 for <roll@core3.amsl.com>; Fri, 17 Apr 2009 10:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 VFupYkqNrsVJ for <roll@core3.amsl.com>; Fri, 17 Apr 2009 10:55:29 -0700 (PDT)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6D8063A6E63 for <roll@ietf.org>; Fri, 17 Apr 2009 10:55:29 -0700 (PDT)
Received: from kelsey-ws.hq.ember.com ([192.168.81.55]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 13:57:31 -0400
Received: from kelsey-ws.hq.ember.com (localhost.localdomain [127.0.0.1]) by kelsey-ws.hq.ember.com (8.13.4/8.13.4) with ESMTP id n3HHugEY003064; Fri, 17 Apr 2009 13:56:42 -0400
Received: (from kelsey@localhost) by kelsey-ws.hq.ember.com (8.13.4/8.12.8/Submit) id n3HHuf9n003061; Fri, 17 Apr 2009 13:56:42 -0400
Date: Fri, 17 Apr 2009 13:56:42 -0400
Message-Id: <200904171756.n3HHuf9n003061@kelsey-ws.hq.ember.com>
To: jvasseur@cisco.com
In-reply-to: <DA769514-772B-4FF4-8584-DE24A0AB7436@cisco.com> (message from JP Vasseur on Fri, 17 Apr 2009 10:49:43 +0200)
From: Richard Kelsey <richard.kelsey@ember.com>
References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <DB697165-ECA2-45B8-AD31-F44B85FC8EE6@cs.stanford.edu> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> <DA769514-772B-4FF4-8584-DE24A0AB7436@cisco.com>
X-OriginalArrivalTime: 17 Apr 2009 17:57:32.0216 (UTC) FILETIME=[FB2A0380:01C9BF85]
Cc: roll@ietf.org
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01
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: Fri, 17 Apr 2009 17:55:30 -0000

   From: JP Vasseur <jvasseur@cisco.com>
   Date: Fri, 17 Apr 2009 10:49:43 +0200

   There seems to be a confusion floating around: we do not need to  
   recompute the tree/DAG to find an alternate path.  The backup path MUST  
   be in place before any failure thanks to the use of an alternate  
   parent/sibling in forwarding or alternate parent in a DAG or alternate  
   tree.

Does the requirement for a backup path stem from some
particular reliability or latency requirement?  Whether
having a precomputed backup path performs better or worse
than a local on-demand tree recomputation would seem to
depend on the particular details of the protocols used and
the stability characteristics of the network.  For example,
it isn't at all clear to me how configuring redundant paths
using HYDRO would perform compared to the Collection Tree
Protocol's local recomputation.  It would be interesting to
try them both out on a selection of deployed networks; it
would also be a lot of work.

                               -Richard Kelsey

v2.23.0 | Report a Bug | By Email