Re: New Version Notification for draft-hui-6man-rpl-option-00.txt

Jonathan Hui <jhui@archrock.com> Mon, 31 May 2010 04:38 UTC

Return-Path: <jhui@archrock.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21DF3A69A0 for <ipv6@core3.amsl.com>; Sun, 30 May 2010 21:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
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 cBbl1y8wabXV for <ipv6@core3.amsl.com>; Sun, 30 May 2010 21:38:09 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 25BEE3A698F for <ipv6@ietf.org>; Sun, 30 May 2010 21:38:09 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D2223AF94C; Sun, 30 May 2010 21:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP09C5dkcyHI; Sun, 30 May 2010 21:38:02 -0700 (PDT)
Received: from [10.0.1.5] (adsl-71-142-75-219.dsl.pltn13.pacbell.net [71.142.75.219]) by mail.sf.archrock.com (Postfix) with ESMTP id D8172AF942; Sun, 30 May 2010 21:38:01 -0700 (PDT)
Message-Id: <FC1304A3-7AF5-485C-A2B9-964D232E0A04@archrock.com>
From: Jonathan Hui <jhui@archrock.com>
To: Hemant Singh <shemant@cisco.com>
In-Reply-To: <AF742F21C1FCEE4DAB7F4842ABDC511C01B74191@XMB-RCD-114.cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: New Version Notification for draft-hui-6man-rpl-option-00.txt
Date: Sun, 30 May 2010 21:37:54 -0700
References: <5193DD89-79F3-4AB4-A866-81DD9DF3A37B@archrock.com><ADFD1D34-0FC1-41A0-AE9C-7C6FFF6419B4@cisco.com> <B4F66743-F927-41F6-BEBD-A67CC9CD8753@cs.stanford.edu> <AF742F21C1FCEE4DAB7F4842ABDC511C01B74191@XMB-RCD-114.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2010 04:38:18 -0000

Hemant,

Being able to change the option data hop-by-hop is fundamental to  
RPL's ability to verify routing information consistency.  That is why  
Section 2 of the rpl-option draft states that "the RPL option is  
expected to change en-route."

The Router Alert Option as specified today does not satisfy this  
fundamental requirement.  Section 2.1 of RFC 2711 states that "the  
option must not change en route."

--
Jonathan Hui

On May 30, 2010, at 1:46 PM, Hemant Singh (shemant) wrote:

> If RFC 2711 already defines a Router Alert Option to use, why do we  
> need
> a new option in the Hop by Hop option for roll as specified by this
> document?  I suggest we just use a new code value for roll with RFC  
> 2711
> and be done with it.  See section 2.1 of RFC 2711.  Here is a list of
> what IPv6 protocols already use the Router Alert Option.
>
> http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert
> -values.xhtml
>
> RFC 2711 also already lists the security concerns with use of the  
> Router
> Alert Option.  This document is repeating the same security concern.
> Further one should look at
>
> http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-
> 03
>
>
> Hemant
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf  
> Of
> Philip Levis
> Sent: Saturday, May 29, 2010 1:08 PM
> To: JP Vasseur
> Cc: ipv6@ietf.org
> Subject: Re: New Version Notification for
> draft-hui-6man-rpl-option-00.txt
>
>
> On May 17, 2010, at 6:18 AM, JP Vasseur wrote:
>
>> Dear all,
>>
>> This is to re-activate our discussion during the last IETF
>> meetings. Feed-back are very welcome since we would like to move
>> forward as soon as possible, this proposed extension is indeed
>> critical for RPL to move forward.
>>
>> Many Thanks.
>>
>> JP and Jonathan.
>
> I strongly support this draft; it is a make-or-break extension,
> without which RPL will not be an effective protocol. There is
> extensive experimental evidence from many LLN deployments and
> testbeds that the mechanisms it enables (datapath validation) are
> critical.
>
> I think Jonathan has done an excellent job of narrowly defining what
> the option can do: containing it within a RPL domain addresses most
> of the major concerns with hop-by-hop options.
>
> Phil
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------