[dhcwg] draft-jiang-dhc-stateless-reconfiguration-01

Yusuke DOI <yusuke.doi@toshiba.co.jp> Mon, 17 February 2014 02:16 UTC

Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650291A0319 for <dhcwg@ietfa.amsl.com>; Sun, 16 Feb 2014 18:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.94
X-Spam-Level:
X-Spam-Status: No, score=-4.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BdJrQ5jtn7 for <dhcwg@ietfa.amsl.com>; Sun, 16 Feb 2014 18:16:08 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3B1A0317 for <dhcwg@ietf.org>; Sun, 16 Feb 2014 18:16:07 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s1H2G2vX001705 for <dhcwg@ietf.org>; Mon, 17 Feb 2014 11:16:02 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id s1H2G2DI029576 for dhcwg@ietf.org; Mon, 17 Feb 2014 11:16:02 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id MAA29574; Mon, 17 Feb 2014 11:16:02 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s1H2G14g000739 for <dhcwg@ietf.org>; Mon, 17 Feb 2014 11:16:01 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s1H2G1I7001685; Mon, 17 Feb 2014 11:16:01 +0900 (JST)
Received: from [133.196.16.86] (ncg-dhcp86.isl.rdc.toshiba.co.jp [133.196.16.86]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 6D40B97D71 for <dhcwg@ietf.org>; Mon, 17 Feb 2014 11:16:01 +0900 (JST)
Message-ID: <530170E0.3040004@toshiba.co.jp>
Date: Mon, 17 Feb 2014 11:16:00 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/rWoQJWxpxusynv5k4G43j4ecnoQ
Subject: [dhcwg] draft-jiang-dhc-stateless-reconfiguration-01
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 02:16:14 -0000

Hi,

Let me speak out (again) that I'm interested in the following draft in the context of roll/6lo-ish LLN, in particular, over 802.15.4.

>         Title           : Stateless Reconfiguration in Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
>         Authors         : Sheng Jiang
>                           Bing Liu
> 	Filename        : draft-jiang-dhc-stateless-reconfiguration-01.txt

We have an application of DHCPv6 that may use statelss mode to deliver network configurations to nodes over wireless mesh network (=> draft-doi-roll-mpl-parameter-configuration-04). Stateless mode is preferred on traffic efficiency (periodic renewal traffic is not preferred on LLN). However sometimes we may need to update configured parameters. We definitely need stateless reconfiguration.

>    {Question to WG No.1} There are three potential mechanisms to create
>    relay agent destinations on the DHCPv6 server:

We prefer b) to remove duplicated messages.

>    {Question to WG No.2} There could be two kind of stateless DHCPv6
>    reconfiguration modes as the following, which one is proper?  Or we
>    should support both?

Is there any difficulty to support both modes? I think these two modes should have different use cases. 'Push mode' will fit to our use case because the configuration is network-wide and push-mode (with multicast target -- it can be broadcasted on a link) is much much more efficient than trigger mode in LLN. But some administrator may want to have per-client configuration and that is the nature of DHCP, as described.

Regards,

// Yusuke DOI <yusuke.doi@toshiba.co.jp>