Re: [dhcwg] comments on draft-hirotaka-dhc-source-address-selection-opt-01.txt

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Thu, 10 March 2005 06:24 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09512 for <dhcwg-web-archive@ietf.org>; Thu, 10 Mar 2005 01:24:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9H8J-000640-1d for dhcwg-web-archive@ietf.org; Thu, 10 Mar 2005 01:26:55 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9H1D-0001Rv-5c; Thu, 10 Mar 2005 01:19:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9H19-0001R9-9a for dhcwg@megatron.ietf.org; Thu, 10 Mar 2005 01:19:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09227 for <dhcwg@ietf.org>; Thu, 10 Mar 2005 01:19:29 -0500 (EST)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9H3r-0005zy-As for dhcwg@ietf.org; Thu, 10 Mar 2005 01:22:21 -0500
Received: from ocean.jinmei.org (wireless-130-129-133-252.ietf62.ietf.org [130.129.133.252]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 876E315210; Thu, 10 Mar 2005 15:19:22 +0900 (JST)
Date: Thu, 10 Mar 2005 15:19:57 +0900
Message-ID: <y7vd5u8yqcy.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: fujisaki@syce.net
Subject: Re: [dhcwg] comments on draft-hirotaka-dhc-source-address-selection-opt-01.txt
In-Reply-To: <20050310.135742.971160363.fujisaki@syce.net>
References: <y7vzmxcz8rr.wl@ocean.jinmei.org> <20050310.135742.971160363.fujisaki@syce.net>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a

>>>>> On Thu, 10 Mar 2005 13:57:42 +0900 (JST), 
>>>>> <fujisaki@syce.net> said:

>  | Substantial comments (or questions)
>  | 
>  | 1. at least from this document, it's not clear whether we really need
>  |    this kind of generic DHCPv6 option.  In particular, the assumption
>  |    in section 6 that ISP1 doesn't have global connectivity while ISP2
>  |    does seems very artificial.  I cannot understand why we are
>  |    suddenly led to this example.

> We believe that the closed network example is not artificial.  There
> will be some cases that users want to use multiple connections
> simultaneously, such as global connectivity and VPN,  and global
> connectivity and some kind of ASP services (Video streaming, IP Phone
> and maintenance of home appliances). Actually, some implementation
> of IP phone already uses closed network model.

>  |    If this option is useful for a general multihome case, the draft
>  |    should first discuss that case (rather than the odd-looking
>  |    unbalanced example).  But it does not seem to be the case to me (or
>  |    at least it's not clear to me).
>  | 
>  |    What happens if both ISP1 and ISP2 have global IPv6 connectivity?
>  |    Can this option help something in this case?

> CPE router can inform nodes which prefix should be used to a
> destination prefix (in this situation, CPE router will inform
> the nodes which uplink is selected as default).

Aside from whether the half-global, half-closed model is realistic or
artificial, I still think there's an issue of document organization.

Introduction of this document begins with general multihoming issue.
But the document then only provides the half-closed example.  It
really confuses a normal reader who does not have any background of a
commercial ISP in some country:-) Possible natural document
organization is thus either (but not limited to):

- begin with general multihoming issues (as the document currently
  is), explain how the proposed option works in the general case,
  *and then* show it can also (particularly) be useful in one special
  case of the half-closed, half-global model.

- concentrate on the half-closed, half-global model only.  begin with
  an explanation of how this type of special multihoming is realistic,
  and show how the proposed option solves this particular case.

The reality consideration is also helpful in the first approach, but I
believe it can be omitted since it's just one special example of a
general issue and solution.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg